JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

234

234 JSJ JAMStack with Brian Douglas and Matt Christensen


1:00 Intro to guests Brian Douglas and Matt Christensen

2:20 Definition of JAMStack

8:12 JAMStack and confusion over nomenclature

12:56 JAMStack and security, reliability and performance

17:05 Example of traffic spike for company Sphero

18:26 Meaning of hyperdynamic

20:35 Future and limits of JAMStack technology

26:01 Controlling data and APIs versus using third parties

28:10 Netlify.com and JAMStack

31:16 APIs, JavaScript framework and libraries recommended to start building on JAMStack

35:13 Resources and examples of JAMStack: netlify.com, Netlify blog, JAMStack radio, JAMStack SF Meetup

QUOTES:

“I think in the next couple of years we’re going to see the limits being pushed a lot for what you can do with this.” – Matt

“Today we’re starting to see really interesting, really large projects getting built with this approach.” – Matt

“If you can farm 100% of your backend off to third parties, I feel like that really limits a lot of the interesting things you can do as a developer.” – Brian

PICKS:

Early History of Smalltalk (Jamison)

React Rally 2016 videos (Jamison)

FiveStack.computer (Jamison)

Falsehoods programmers believe about time (Aimee)

Nodevember conference (Aimee)

48 Days Podcast (Charles)

Fall of Hades by Richard Paul Evans (Charles)

Jon Benjamin Jazz (Brian)

RailsConf 2016 (Brian)

React Native (Brian)

Book of Ye Podcast (Brian)

Aurora by Kim Stanley Robinson (Matt)

Sequoia Capital website

Sphero website

Isomorphic rendering on the Jam Stack by Phil Hawksworth

SPONSORS:

Front End Masters

Hired.com

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

Charles: Hey everybody and welcome to Episode 234 of the JavaScript Jabber Show. This week on our panel we have Jamison Dance.

Jamison: Hello friends.

Charles: Aimee Knight.

Aimee: Hello, from Nashville at last.

Charles: I’m Charles Max Wood from Devchat.tv. This week, we have two guests. We have Brian Douglas.

Brian: Hi.

Charles: We have Matt Christensen.

Matt: Hey there.

Charles: Do the two of you want to introduce yourselves really quickly?

Brian: Yeah. Matt you go first.

Matt: Okay, sure. My name is Matt Billman. I’m the founder of Netlify where we are building a modern platform for the kind of episode sites we’re trying to talk about today called JAMStack sites. Netlify is basically a platform for deploying, building, and maintaining modern websites.

Before Netlify I’ve been doing several projects. I was a founder of Webpop. I spent seven years in Spain where I was the CTO of Domestika and build tens of thousands of websites.

Brian: I’ll introduce myself. I’m Brian Douglas. I’m here in the Bay Area, specifically Oakland. I do frontend for Netlify but I’m also a developer advocate, meaning that I just do some more talking and meet up talks. I’m also the host of JAMStack Radio, which is another podcast. A top in this base.

Charles: Awesome. We did bring you on to talk about JAMStack. I think we talked on Google Hangouts or something for a few minutes, I don’t remember. But I think we talked and then we would wind up the call. You explained to me a little bit of what JAMStack is. Do you want to give us that thumbnail picture of what JAMStack is and what it’s about? Because I thought it was an interesting take on building applications.

Matt: For sure, I can start with that. JAMStack stands for JavaScript, APIs and Markup. Essentially, it’s a way of naming this new stack that has emerged during the last five years. At first just around things like modern built tools like Gulp and Grunt in a silly but also static site generators like Jekyll, and Middleman, and Hugo, and so on. Also around the whole work flow, it centered around Git that has sort of become a thing for frontend developers during the rise of GitHub.

Five years ago when you talk to a new frontend developer, they would probably be FTPing into a server and working directly on code and things like that. Today, pretty much any frontend developer has some work flow where they use Git as servers in control but also as their mechanism for deploying, and pushing, and pulling, collaborating, and use built tools to compile and watch both usage pipelines but also to a larger degree the built of the actual Markup.

In the same period we’ve seen browsers, we’ve seen Internet Explorer 6 die first of all. In which means that today browsers are much more than just document viewers. They really like an operating system where JavaScript running in the browser can talk to all kind of APIs and where a lot of the functionality that we normally had to do in big one sites or apps on the server can be pushed to JavaScript in the browser today.

These things has come together to form a new Stack where you can say that the Stack has moved up a lever. Before it was all things like the LAMP Stack that was all about the operating system, the specific web server you would use, and the programming link which you would use, the database you would use. Today, it’s more about actually pushing out Markup that uses JavaScript to talk to APIs.

The name itself came about after we had been working a while in this space, in the area of what we would talk about static deployment, static hosting. Always found whenever we talk with anybody in this base that it was like a really weird term for what it was we were doing and what it was this whole new way of building sites was about.

I remember talking to Thomas Reynolds who built the Middleman, the Stack site generator. He told us how an instrument they had gone from having essentially in a team of mostly backenders to a team with around 35 developers where two of them did backend and all the risk were essentially working on the frontend. Building large production sites with static built tools that would push out Markdown that then would hook up some JavaScript and do a lot of work in the client.

Feeling that holding those kind of sites, static sites, was really weird because this was like, as you said, the latest sites you worked on was probably like a 100,000 of lines of Ruby code. With the whole developer team working on it and doing all kinds of interesting shit like job board in the browser, real time in visualizations of data, and so on.

All builts was this approach where you don’t have them moving backend and where you pretty build out a lot of Markup. It talked to a lot of different APIs using JavaScript to tie it all together. As we talk to more and more people, this term started to form around the JAMStack as a new Stack for both websites and apps.

Charles: Yeah. I think it’s interesting to me just in the sense of having grown up on Ruby on Rails, that being a large backend system. To be able to look at the system and go, okay… Essentially, I move all of the stuff that I have in Rails to the frontend and then I take advantage of APIs and provides some Markup to my system. Yeah, I use JavaScript to manipulate the rest of it.

My persistence layer, a lot of my business logic and some of the other concerns that I would have handled on the backend are now either handled via APIs and completely handled in JavaScript.

Brian: One good use case of it is like whenever you build a blog per se I guess, every time I went to go and build a blog, first thing I pull into the comments is discuss. Discuss is the API that I just point to drop in a little bit of JavaScript. I have come into my blog. There’s no need to build out the entire Rails or Node backend to have comments in your blog when you get to sign up the discuss service and then drop in the Script. That’s basically what JAMStack is all about.

Jamison: I’m a little confused about what this actually means. Because to me, it sounds like you’re saying instead of talking about you have a backend server and frontend, you have frontend and then you have an API, the API is your backend server. It sounds like you’ve given a name to a thing we’ve been doing for a while. I’m confused how it’s done.

Brad: Yeah. We’ve had this conversation over and over every time I write a blog post about JAMStack. We’re basically adding a name to something we’ve already been doing, which is correct. I think about two years ago when I first go on JavaScript, I got really hard on Amber. One of the terms that I picked up really quickly was the term separation and concerns.

Once I actually work my frontend framework which was Amber, I was building like a Rails API. That always separate between the two repositories. That way, I always had an idea of like I can always host my Rails API on Heroku. But then the question was where do I put my frontend code.

At the time, Devchat was pretty popular so I was actually a pretty active Devchat user before they were merged in the Firebase. I think that’s what we do at Netlify. We take that frontend portion of your app when it’s separate in the two different repositories. We use that and we call that JAMStack. Does that clear it up a little bit?

Jamison: I guess I’m still confused.

Matt: You made a really good point that this is definitively something that people have been doing for a long time. It’s not like the JAMStack is some new piece of technology or something like that. It’s more a way of the problem where you run into was it we were talking to people, both in the area where people were building sites around static site generators and in the area where people were starting to build single page apps in a way that it’s actually fairly recent that people started for example to really separate their Rails app and their single page app and say instead of having my single page app inside my Rails app and just do things the old way but with more JavaScript, they really started to build self-standing applications in the old repository that would talk to APIs but not be part of the API as such.

On the other hand, in the static site generation community, we’ve just seen hundreds of new static site generators come out. We’ve also seen people build more and more business projects with them like large publications, a sites with a thousands of pages, and interactive filaments and so on.

When we were talking to people, we could see that was actually the same thing happening but there was not a good nomenclature around actually talking about it as the same thing.

I remember Devchat started talking about static apps for example which is like, I have really weird name because you don’t want an app to be static. By definition, it’s something dynamic. When we talk about static sites, we keep running into the same issue as well at people actually building sites with a set of tools that built the Markup up fronts and push it at somewhere but that are not static in any normal sense of the word, they’re actually hyperdynamic.

That’s why between a lot of these people, this term nomenclature I’m talking about the JAMStack instead sort of started rolling out.

Charles: To the question of we’ve been talking to a backend for years. What this does is this eliminates one layer that you have to understand because essentially instead of coming up with the system written in Rails, or Express, or Phoenix, or something else. Building out those APIs that it talks to, you’re talking advantage of APIs that already exist.  The exact was given of having Firebase as sort of your backend or you could use something like Parse which is an open source system that you can sync data through or something like that.

All you have to do is have that system out on the internet somewhere. You don’t have to customize it, you don’t have to work on it, you don’t have to do anything else with it. All you have to know is JavaScript, how to build your business logic, what kind of Markup do you need, how you talk to that API to persist or retrieve any data you need.

Aimee: I’m Googling around here and I just came across some slides. It looks like the three main points so far that I’ve looked at are security, reliability, and performance. Can you talk about those three and why JAMStack is better if you’re concerned with those things?

Matt: Yeah, for sure.

Aimee: I mean, who’s not concerned with those things.

Matt: Most people are. I guess this is also why we’re starting to see so much going on in this area. Security, reliability and performance are all things that have become a larger and larger issue for the traditional way of building especially websites especially when you talk about things like WordPress and Drupal and so on, where you have this traditional monolithic approach where you have something like constant driven site but every time someone visits that site you actually interact with a running program that has to build up that site and send it back to you.

That way of working has meant that the web has scaled. Some of you might still know the term of being slashdotted which is like the old term for getting on a social news network and then traffic crashes your server. Slashdot, the amount of traffic that would send years ago was just miniscule compared to what modern social networks can send in terms of traffic.

That also means that just to run a normal site that might someday get a traffic spike, you have to implement layers and layers of caching. It makes publication difficult, it makes maintenance difficult, and introduce a lot of complexity. That complexity in itself introduces a lot of security holes. I saw in Netcraft last year I think it showed that around 70% of full work per sites are vulnerable to known exploits.

Drupal had this famous, Drupal couple apps a while ago whether was a security exploit that the core team announce that if you hadn’t updated after they announce the update within seven hours, you should consider your whole server hacked and rebuild everything. That affected millions of millions of sites.

Of course, if you can take an approach where you try to minimize any interaction with the running program during the visits to a site, you make their surface area for security exploits much, much smaller. If you can pre-build as much of your site upfront and decouple the build process from the actual process of running or hosting the site, then you eliminate almost all normal security issues.

You’ll probably still have some parts of your site where you need something that you can’t rebuild upfront for all the dynamic elements. Again, if you can isolate that into much smaller special purpose APIs, then you can delegate a lot of the maintenance and hosting to the one that runs those APIs. Even if you run them yourself, you still have a much smaller surface area around those APIs that are way easier to reason about. That does a lot for security but it also does a lot for performance because the more you prebuild upfront, the more you can take and distribute directly on a content delivery network. You can serve those files directly from the place where you visit yours at.

That also again for reliability just makes it way easier to scale. The more you can just push out to a content delivery network, the less you’ll have to ever worry about scaling for traffic spikes and the like.

I can mention a quick story around this, on Netlify was a company called Sphero that built the toy version of the BB-8 Droid from the new Star Wars Movies. It’s a pretty nice thing if you ever want to start a company, just make sure you get your toy into the largest movie franchise in the world and then start selling it. They somehow managed to do that but then up to the premiere of the new Star Wars Movies, they had to prepare for the worldwide launch of that and the traffic that would come with it.

They did that by essentially building out their whole site with the build tools which splits out all the cold pages. They were using Angular to do all the dynamics stuff at client-side. All the basics would already be pre-built and loaded upfront. They just put it on Netlify a week before the premiere of the new Star Wars Movies. I think we serve more than six terabytes of traffic for them in a pretty short time span.

Aimee: I want to backup and ask maybe a more basic question. Excuse me if this is a little bit of an ignorant question. On these slides, and you also said earlier hyperdynamic, that seems a little bit buzz wordy to me. Can you explain exactly what you mean by that?

Matt: Yeah. Basically when I say hyperdynamic I mean what do we think about of dynamic. There’s two things. One is that the content of the site refreshes, that it’s not just a static landing page that’s sitting around and not doing anything. Things like having a news publication or magazine where the content is alive. There’s just also all the parts of interaction, stuff like being able to do search on the side or comments, or filtering, or all these functionalities that we think about as dynamic.

What we’re seeing is a lot of these sites that are built with the static tools because they are actually pushing out markup that then lets JavaScript take away a lot of stuff, they become much more dynamic than the WordPress site. The Rails applications, we were all building three years ago because they really live in the browsers as applications and are able to respond very fast.

That’s what I mean with hyperdynamic that we’ve gone from these sites that were dynamic by running a program on the server every time we visited to going to sites that are even more dynamic by running a program in your browser every time it was visited.

Aimee: Okay, that really helps. Because you know, I’ve heard static, I’ve heard dynamic, it’s pretty clear the difference but hyperdynamics wasn’t 100% clear. That’s more clear now. Thank you.

Matt: Awesome.

Charles: My question is how far can you take this? This seems like for a blog or something like that where the data structure isn’t that complicated, you probably have a few data types like authors, posts, and maybe comments. How far can you take this? Could you build a full on CRM on something like this? Or could you go into building out some complicated financial or medical software with this?

Matt: I would say as always with any technology, it depends. A lot of the things you’ll see around single page apps will mean that you will build the actual application as a little bit of Markup and then a lot of JavaScript. That’s of course something that can scale to building just about any kind of app.

An example would be our own web UI. That’s like the web UI for Netlify that handles deploying websites and configuring as a sale, or setting up DNS or anything of that. All of that is a single page app in React that lives on Netlify and just talks to Netlify’s public rest API.

That approach on the one end is something that’s very much just becoming the way of building web applications more and more. There’s the other end which is latch content driven sites. There, I probably wouldn’t try to build something where the content, where you have maybe hundreds of thousands of pieces of content and they update fairly often.

We are starting to see projects with thousands of pieces of content. We’re working with a large publication in the space of frontend development that I would be looking to migrate them. Therefore, publishing engine, and ecommerce store, and the job board, and everything from a traditional approach where they had some of it in WordPress and some of it in Shopify to building out all the core content with the static side generator called Hugo. That’s interesting because it’s capable of building a lot of content really fast. Doing things like ecommerce and jobs, and comments, and so on by using a JavaScript to talk to some small very special purpose open source APIs.

I think in the next couple of years we’re going to see the limits being pushed a lot for what you can do with this. We are already seeing it. If you check out a site like for example Sequoia Capital’s website, we’ve been involved in that source around Netlify. That’s surprisingly a large site for DC Company. It’s at least 15,000 separate HTML pages all built out statically. They do things like real time search in the browser. They have a job board where all of the content is built out upfront but then with JavaScript they can enable superfast flying site, filtering, and location based filtering, and so on.

These are definitely the kind of projects that shows that we have maybe when  the only things people would built with these kind of tools where their own developer blog. While today we’re starting to see really interesting, really large projects getting built with this approach.

The interesting thing is that the larger the project, typically the more important these characteristics of performance, and security, and reliability becomes. That’s why even though this in some cases means pushing the limits a bit and figuring out how to do this with the JAMStack approach, that’s why we’re seeing agencies and companies going through that to get the advantage of side step. Pretty much response instantly and always stay up.

Brian: To go to Chuck’s point, it seems like this is building these static only sites that talk to APIs that you don’t control or build is still I feel like the apps that I use are useful because of data that lives in essential server. Controlling that data, controlling that API is really important. If you can farm 100% of your backend off to third parties, I feel like that really limits a lot of the interesting things you can do as a developer. You can certainly skip a lot of busy work. If you’re building an app that doesn’t really need a backend, that just showing web pages, that’s fine too.

Matt: I agree with that. I think it’s important that we have more and more open API ecosystem where we can use existing APIs. I think most people doing this will also build some of the APIs themselves. Not all of them but typically as you say you will have data that is really important to you. That’s part of the reason why your app exists. That data will probably also write at one to expose through an API than just threw some pick monolithic web app because you will probably also want to use that data from your mobile apps or for other uses.

I think you’re spot on in terms of it’s also an important part of it to have that you can do everything just with off the shelf API. I think one thing we are interested in seeing is also beginning to create a bit of an ecosystem for open source APIs where some of those might also be run as management services but where you also have the option of fronting them yourself or at that thing yourself for tailoring to your own use case.

Jamison: Another point to add to. netlify.com is actually a JAMStack site itself?

Matt: Yeah.

Brian: The whole backend API, it’s not a third party API. It’s API that we built. It actually has a Rails API that’s just rendering Json. The actual React app for consuming that Json. Presenting the data and we have through HTP we’re able to actually, I’m not sure what that means. We consume the API, we do that through that in the Redux. We handle with just as any other React app that would be handled isomorphically or universally, whatever the popular term is.

Another example, when I first moved to the Bay Area I had this issue where I ride the BART to the train system. I built this app because the very first week I started my job in San Francisco, there was the Bay Series, the baseball game. The baseball games between Oakland and San Francisco basically clogs up all public transportation. My idea was to build an app to tell me when not to ride the BART, or when not to ride public transportation, or when do I get home earlier.

I built that to a Rails API read as Json. I originally built it to some Amber app. Where I was just running that Json to Amber. Up and I say using the JAMStack approach we have the separate repo, you have your API which is what I built. I built it by scraping ESPN data. I was able to switch that to React app, I was enable to switch that frontend also to React Native app. I think that’s as far as I went.

I’m about to now look into doing it as a purely static site that presents the data, gives me notifications when not to ride the BART.

Just to go back to your question Jamison that the API itself, yes, it’s something I built. I guess only using off the shelf party API is more the ideal way but when you want to be your third party API, be able to do that as well.

Matt: Yeah, I think that’s a pretty good explanation. Also just to keep in mind that this is basically to create some nomenclature around and architecture for building sites. APIs are mainly plural because you often end up with the Stack talking to a bunch of different APIs. Some of them are your own, some of them come from other places.

Even in the Netlify app, we both from the web app, we talk in large of course to our own rest API but we also talk a lot to GitHub’s API, to GitLab’s API, to Bitbucket’s API. Whenever you configure project through any of those and so on. It’s sort of something that’s just snuck in and all of us. That was definitively just not something you could actually do in the browser a few years ago. It’s come together with pros origin request to come together with the death of i6 and 8. It’s really interesting how it’s becoming the natural way for working for a lot of developers.

Jamison: Yeah, it makes sense.

Charles: Are there specific APIs that you recommend people get started with, start building on JAMStack? Are there certain JavaScript frameworks or are there libraries that make it easy to keep going as well?

Brian: Serverless is a framework that talks to Lambda. I want to recommend start with this but I just want to bring up the point that you can actually have Lambda functions as your backend. This could get pretty complicated but there are some people who have done it. I know Kevin Old to seize on the React Native he host that podcast with Nader. He actually had a whole talk on this at the, I think that React Rally I think, maybe, last week.

Charles: Just to clarify when you say Lambda function you’re talking about Amazon’s cloud service.

Brian: Yeah, function as a service. Some people have built some pretty complicated CRM tooling where you just populate Dynamode DB deep tables. This is this giant key value store where you just add new records to your giant JavaScript objects. Which is really interesting but it seems kind of scary. I’m only just now getting in a Mongo. I’m not really as for my non-SQL databases. There’s also on that point like Rethinkdb has horizon. That’s pretty new where you could just you’re back in the servers.

Firebase is also another good starter kit as a database as a service. There’s one app that comes to mind. Iheanyi, he’s part of the JavaScript Air panel. He actually built this entire site which is the Facebook Page Unliker. It’s one of the first things I saw him built and got me excited about Amber. He wanted to try to build an Amber app with no backend, that just talks directly to the Facebook API.

Sites that have just a Json API, this is a mail pool. You could also do stuff like that. To answer your question originally on the roundabout way to get to this is I think any sort of rest API that’s available to you like Twitter or Facebook you just want to play with and try it out. How I recommend that? I do a bit of mentoring to a coach school called Block. I have one of my students actually building, we have started with a Rails app that talked to the Twitter jam. He basically just rebuilt twitter using Rails. We switch over to using React on the frontend. As a learning exercise, he took out the Rails and then put Node as a backend, and then express API.

The opportunity is basically unless you could try. I would recommend anything that is serving Json currently for you.

Matt: For generally getting started with sites that use this approach, we actually haven’t really announced this yet but we recently built a little boilerplate called Victor Hugo for building epic websites which is just for combining Hugo as a static site generator to output all your Markup with web pack to build all your JavaScript and Gulp to handle the general acid pipeline. That’s the other end of it where we just build our own website with this boilerplate a new version of it. We have some people building some pretty cool projects with it now.

Aimee: Is JAMStack open source or close source? Because I’m trying to find it on GitHub and I haven’t been able to find it.

Matt: The website itself should be open.

Jamison: To be clear it’s not a framework, it’s not code, it is giving a name to this existing idea of building your frontend to consume third party APIs basically.

Matt: Yup.

Brian: Correct.

Charles: If people want to check Netlify or see other examples of JAMStack in action or their other resources, where should they go? What should they do in order to figure out what you guys are talking about?

Brian: Check out netlify.com. We do have a blog that we actively contribute to, at least more two to three times a week. There’s also JAMStack Radio which is the podcast that I started very recently, which we go to some of these details. We also talk not only to people who are doing JAMStack but also skeptics. We have some people from Airbnb on one episode that’s not out yet. I think from there you should be pretty good, good to go. We’re pretty active in Gitter as well. If you’re a Gitter person, check this out, Netlify.

Matt: If you’re in the Bay Area, we also run a meetup that used to be called SF Static Web Tech and now it’s called the SF JAMStack Meetup.

Charles: Very good.

Brian: Sorry, just want to add to just be clear. Netlify is not the only place we can host about JAMStack as websites, there’s surge, Firebase hosting also can do it, and those couple other ones too out there that I highly recommend checking out as well and comparing.

Charles: Alright. Let’s go and do some picks. Jamison, do you have some picks for us?

Jamison: I sure do. I’ll just start talking and then I’ll figure out how many picks I do when I stop talking. The first pick is called the Early History of Smalltalk. It’s a write up by Allan Kay on the origins of small talk. It’s an awesome look into some history of computing things that are pretty cool. There’s been a lot of work before all of us started programming. A lot of people had a lot of great ideas. It’s fun to see some of those ideas that have existed long before they became popular and even some that’s haven’t quite count on yet.

My next pick is, I think Brian already mentioned it, but React Rally 2016 videos are out now. They’re up on YouTube. You can watch things like Kevin Old’s Serverless talk. There’s also 19 other talks. As an organizer, I basically got to see two minutes of every talk so I’m excited to go through and watch them all now to see what the conference I organized was like.

My last pick is going to be self-serving. I run a software consulting company called Fivestack. If you got to fivestack.computer, you can see all five lines of HTML that I’ve written for a website. We build great software products. We’re looking for a couple more clients. If you’re interested in that, just talk to me through the email address that’s on that website. Those are my picks.

Charles: Alright. Aimee, what are your picks?

Aimee: Okay. This is a pretty good blog post. It’s a little bit older but somehow I stumbled upon it. I thought it was really, really good. It’s called Falsehoods Programmers Believe. There’s the main blog post but then if you click on the links, there’s one falsehoods programmers believe about time zones. They’ll give you a couple but if you click on the main header, they’ll link you to another article. It’s just a ton of stuff. Especially, we work in the community where I think it’s good that a lot of conversation about questioning, things that you take for granted.

One of the falsehoods programmers believe about names, about time, things like that. Especially if you are a frontend developer I feel like, I guess it goes too for backend but especially for frontend, you’re working on and accepting user input and things like that. There’s a lot of things that you might take for granted just based on your past experiences that you’re not considering for other people. I’ll put a link for this article in the show notes because I thought it was pretty good.

My second pick is going to be Nodevember. I know there’s a lot of talk on Twitter about it. It’s a great conference. Especially like I said, I actually moved to the area just because I love the JavaScript community here. Great place from your move. I think you should come out and attend Nodevember. That’s it for me.

Charles: Alright. I’ve got a couple of picks here. Last week was crazy for me. If you are following the Twitter verse and you know what I’m talking about. If not then, not so much but it was that and the fact that I had to drive my dad to the hospital a couple of times. I had Angular Remote Conf. Anyway, it was just an insane week. I was super exhausted, frustrated, and a little bit angry. Anyway, my escape is a mixture of audiobooks and podcasts.

Anyway, I don’t know why but it just turned out that I was a couple weeks behind on the 48 Days podcast by Dan Miller, who actually lives in Nashville. It was exactly what I needed to hear, it was funny. I’m going to pick the show just because it was just one of those things where for whatever reason he was talking about some of the things that I need to know.

My other escape lately has been the Fall of Hades by Richard Paul Evans. It is the sixth I think book in the Michael Vey Series. I’ve really enjoyed the books. It’s nice because I can just sit and listen. They’re young adults so the plot structure and things like that aren’t as complicated as some other things that you find that are more adult genre fiction, or adult level fiction. Anyway, it’s really easy to listen to, really easy to follow. I can relax my brain a little bit while I listen to a fun story about kids who have powers, electricity powers.

Brian: So relatable.

Charles: I know, right. Those are my picks. Brian, what are your picks?

Brian: Alright. I’m actually a big fan of the podcast and actually listen to almost all of the Devchat podcasts. I know there’s sometimes some non so serious picks. I have my first not so serious pick is actually Jon Benjamin, I’m not sure if he’s a comedian but he hired a jazz band to play piano with him. It’s a band backing him on piano. He actually doesn’t know how to play piano so he plays with the Jazz band but then when it comes to his part it’s absolutely horrid. When he actually starts playing it’s a very bad piano. I recommend everybody watch that because it will definitely brighten up your day. Knowing that some guy is playing piano with a very amazing jazz band.

My other pick is RailsConf 2016. There was Stella Cotton, she spoke and she worked at Indiegogo. They got to a D-Bus attack. It was a giant monolithic Rails app. They didn’t know what to do so they have switching, I guess the resolution, I’ll give you the spoiler. They switched their actual entry point to the main indiegogo.com to a static site. For individual pages they also switched to static pages as well to prevent any sort of slashdotting. For example, I forgot which campaign actually did it for them but some campaign that basically blew up Indiegogo, because everybody was actually trying to view the site.

My other pick is React Native. Some people have been skeptics and have tried it a year ago. It’s come along a long way in only a short year. I recommend if you haven’t tried it, try it again.

Finally, my final pick is Kanye West. I am unapologetic for Kanye West. He came from nobody to producing beats from JZ. Now, he is kind of gone a little pass the line but there’s a podcast called Book of the A. I highly recommend listening to it. A bunch of guys who are big fans of Kanye West. They’ve been fans for a while and they talk about the good and bad about Kanye West. If you’re very interested into it, which I’m sure you are, check out the Book of the A podcast.

Charles: I just find the idea of podcast about celebrities fascinating.

Brian: This one is, you’ll be hooked. I promise.

Charles: Okay. Matt, what are your picks?

Matt: When I relax I like to relax by reading science fiction. Whether it’s sometimes really bad science fiction and sometimes really good science fiction. One really good author I’m enjoying a lot is Kim Stanley Robinson. His newest book is called Aurora. It’s really good. It’s a little depressing. It talks about this generation starship that’s been sent on an expedition to one of the nearest starts and has already been underway for hundreds of years. Generations of people growing up on the ship, about the generation that actually arrives to the star and what actually happens then and so on. It’s really fascinating.

His Mars Trilogy is pretty amazing as well. Talking about the colonization of Mars and expansion of human kind to the whole universe. I recommend that.

Charles: Alright, cool. Aimee asked a question I just want to put out there because I think it’s interesting. Do you have examples, you talked about a few but what are the other examples you wanted to give us?

Matt: I think the Indiegogo that just talked about sounds really, really interesting. Our own app of course is a typical example that’s a lot of those bounty sources has an open source app. That’s also pretty interesting.

This Sequoia Capital website is a really interesting example of a content driven site. Just because it’s like a lodge, a multiregional site with a ton of content talking to content full and eLogic job. Job API that the years to follow the job boards and everything.

sphero.com is a pretty fun example as well of. Often mean .com sites with ecommerce and so on that sounds pretty cool.

Aimee: Yeah. If you can add those to the show notes. I was really trying to look for some code examples because I felt like that would help explain things.

Matt: Phil Hawksworth also has a really good post about his site of how just building an isomorphic JAMStack site. Just see if I can dig up the link for that. That’s really interesting post about how he uses in a way JavaScript based server site rendering to pretty build all the Markup but the hydrated once you load the post. Just for a site called Comedy in the Crown that he’s working on. That post has a lot of good examples and explanations.

Charles: Alright. We’ll go ahead and wrap up with that. Hopefully folks will go check out those examples. We’ll catch everyone next week.

Brian: See you.

Aimee: Bye.

Matt: Bye.

Charles: Bye.

 

x