Ep. #8, Isomorphic Rendering in the JAMstack

Brian Douglas: So welcome to another installment of JAMstack Radio. Here we've got Eli.

Eli Williamson: Hey, how's it going guys?

Brian: And then we've got also as our guest today, Phil Hawksworth.

Phil Hawksworth: Hello. Nice pronunciation.

Brian: Yeah, pretty good. The English pronunciation I'm pretty good with. Other cultures, last names are kind of hard.

So Phil, I have you on the podcast because you have a very interesting topic out there, but also, blog posts about isomorphic rendering on the JAM. So, before we get into that, can you just tell the listeners who you are? Who's Phil?

Phil: Of course. So I'm Phil. Sounds like I'm in an AA meeting as I say that. So I work as a technology director at an agency based in London called R/GA. R/GA, we're actually from New York. That's where our head office is. But I'm in the London office, so there's like three hundred or so of us there. I'm Head Director so my background is in web development.

We're frontend developer by trade, but it's been a while, I'll be honest, since I've been allowed to release code out into the wild.

So now I tend to work with the development team who build things. But I do lots of kinds of technical architectures and working with clients to figure out what we should build and how, and to brief that kind of thing. But,

I'm a tinkerer, I like to make things. And that's the only way to stay relevant and keep my finger on the pulse.

So even though I'm not building things for real, I build things for myself and I build things so that I can understand, how we should be trying to make things in the future.

Brian: So R/GA Agency, builds websites for other people.

Phil: We do, yeah. I think I'd probably be in trouble from our marketing folk for saying we're an agency. We've stopped calling ourselves an agency now. We're now calling ourselves a company, which could mean anything, our kind of line is that we build products, services, platforms, communications for clients to grow their business. But really you can see why I say we're an agency.

Brian: I was going to say, McDonald's is a company.

Phil: Yeah there are lots of companies out there. But yeah so we tend to work with big global clients. We work for Nike who is one of our longest-running clients.

So we do a lot of global work for Nike. Google, Beats by Dre. We do a lot for Beats by Dre. And, that kind of company. Unilever is another one I work on quite a lot. So it's really broad, it's all kinds of different types of engagement. But yeah we'll do things from building that communications to actually building the product itself.

So NIKEiD is the kind of canonical example we talk about, because that's something where we came up with some of the concepts and then we helped their actual industrial design, and then also through to the building out the platform, and then communicating it. So you know, soup to nuts, as I gather you say over here.

Brian: Yeah. Soup to nuts. Yeah, keep on with the English accent.

Phil: This is real though, by the way, this isn't something I've affected for the podcast.

Brian: Yeah we didn't mention one announcement that, Phil is actually from Minnesota.

Phil: I don't know if my accent might slip at some point.

Brian: You don't say. Cool. So then your work from R/GA and architectures, isomorphic rendering, that's a mouthful.

Phil:I felt like a bit of a clown when I used that expression on my blogpost about it. But you know, I've heard that Isomorphic Javascript costs a lot.

And people are talking about that a lot. The thing that I've been making a bit of proof of concepts has come about because, I've been a bit frustrated with some sites that I've seen that I felt have been a bit overengineered. But doing something that I think is very sensible, being able to proggressively enhance a website or a webpage which is already a viable landing point, that's been "rendered on the server", which for my money, just means the server output HTML.

Brian: Yeah.

Phil: You know, that's what that means. But then also adding clients and rendering on top of that. So you often see one or the other. You often see empty body tags being, pushed down the wire, and then everything being rendered in Javascript on the front-end. And I don't really care for that. I think there are plenty of places where that's absolutely the right thing to do. But for a website, which is about communicating content, I'm very keen for the content to get down the wire and into the eyeballs as fast as possible.

So this kind of thing I've been talking about a little bit, and blogged about, really was an attempt to what I felt was a very simple way of using the same kind of templating on the server but then also pumping those templates down the wire as Javascript so that you could then enhance the page with client side rendering on top of what was already a viable page in the first place.

Brian: Yeah, and what's beautiful about this, and Eli I brought you on because you have a not only of you have agency experience, but you're actually a designer who also knows how to code.

So you can manipulate the page at a very high level. Get really awesome stuff done without touching the server.

I think it's what Phil is talking about. That you can get a lot of work done on the front-side style.

Eli: Could you tell us a little bit more about differences between server side and client side?

Phil: In terms of the considerations?

Eli: Yeah

Phil: Well absolutely. I mean first things first, you know. When you're in a server-side environment, you're in a contained, known environment right? You've got complete control over that. And so, things can happen a much more predictable way, you know you don't have to cater quite so many edge cases, because you're working in a contained, known environment.

It was Douglas Crockford that talked about the web being the most hostile software engineering environment in the world. And a lot of that I think is down to the fact that we don't know where our code is going to run, when we're talking about the client side.

And it's not just how the design works, but how you know, if we're starting to add behaviors into the client, those could be interpreted different ways by different Javascript engines, rendering engines. You know, rendering engines are different. And we don't know what the devices are that we're going to be serving this to. We've got a pretty good idea, but we don't know what devices are under the Christmas tree, as the expression I've heard a few times.

We don't know what's coming at the end of the year, so building things that can work everywhere when it comes to client side rendering is tough. Which is why I'm very keen for that to be treated as a progressive enhancement, rather than you know, it's all or nothing. Either this massive blob of Javascript will execute and work and you'll get what you want or it will break because Javascript isn't quite as fault-tolerant as HTML. Browsers are great at rendering HTML method. They don't understand something, they skip over it and things can continue to work.

That's why I'm very keen on building something that is delivered as HTML which is viable so it's rendered in a known, contained environment on the server side. And then that's a viable, deployable thing. And then you can enhance it with Javascript. If the devices support it. And that was another kind of principle that I was keen to explore with this little experiment. Building something even if the Javascript failed, was still completely viable.

So, all of the internal links which still work because it's just the web you know, it just links, but then every internal link once Javascript is there is hijacked, so it just pulls the bit of data that it needs and then uses the same templates that you've used in the server to render that. So, the big distinction is a long, rambling answer to a short question, is

It's a known entity on the server, but it's the wild west when you get into the client side.

Eli: Yeah, and client side is kind of another way of saying browser.

Phil: And I guess browsers can come in all shapes and sizes. I mean, it might be a watch, it might be on the dashboard of your car, it could be in all kinds of places.

Brian: Yeah, it might be in that listening device on your kitchen corner called Alexa.

Sorry for all the listeners listening on your speakers, but Alexa turn off.

They don't actually have an actual browser on the echo as of yet, but I can see that progressing into something. It's all things on every single device. You have to account for so many different use cases, like for Netlify, we actually just looked at our records to see how much mobile use we have, to see whether or not it's something that we actually care about. At this point in our life as a startup, and we found that our mobile numbers for Netlify are very low.

Which is the lowest I've ever seen for any company I worked for. Because most people, not going into blog, but going into app.netlify.com and maintaining your actual site on our dashboard. Most people view it in the dashboard. That's basically the way we present it to them. So I think that's mainly the reason why most people do that. But then we still are stuck with whether or not certain things we're doing work in Safari, as supposed to work in Edge, as supposed to work in the IE7. If it's IE7 we say "sorry out of luck". But we'll just move on. And even Safari is different from Chrome. And it's painful at sometimes.

Phil: Yeah, absolutely, and users like an admin tool you know, the kind of thing you're talking about, on Netlify, where there's a fairly contained audience for that right? There are people who are maintaining a site. They're your customers your consumers, and they've gone there to perform an activity. That's a slightly narrower audience than you can see was in the output right? So you can set some constraints there and say well this is a reasonable, browser matrix for that. But I have to say, I've been in and used it on a mobile device just to prove that I could as well.

And just to say well you know what, I can deploy my site now just from my phone when I'm on the train, because that just makes me feel smoke about how powerful that is and how flexible it can be. So, thanks for making it work.

Brian: So going back to this buzz-word term, isomorphic rendering. Is it more the separation between what we talked about the client side and the server side, but what is isomorphic about? The handshake between the API and the front-end.

Phil: Yeah so I don't think really this is a very new idea. It's not a very new concept.

You know, this idea of same templating being done on the server and on the client, you know, there have been people talking about doing that for a while. But the thing that I've been experimenting here with is driving this from a static site generator and then making sure that I present the data that was used server side as an API that the client could consume. And that's just being done as a bunch of static assets as well.

The path for any one of my urls in the client has a corresponding API path which is just a JSON file. So there's no querying that's done because all of those things are static views if you like.

But I quite like the fact that you can take you know, a blob of data that was used server side and then carve that up into a bunch of JSON files, and then present that as static assets, that can then be queried.

So, I try to kind of normalize the API in that way. So that you can use it from anywhere, so it's just building on that static model.

Brian: Cool.

Phil: But I don't think I answered your question or even came close to it did I?

Brian: Well you sort of answered it when you mentioned JSON. So, you have your data presented as JSON to be able to talk to your frontend.

Phil: Yes.

Brian: And there's no need to actually am I correct? Running a server for your JSON?

Phil: No, absolutely. It's just a bunch of files. And in this particular example, I'm actually using another third party for the content management of this. So, I'm using Contentful, which I know has come up on these discussions.

I'm a big fan of Contentful. And so, behind the scenes, you know, my build mechanics, those are making a query to Contentful, and they're getting back a JSON response. And then I'm massaging that into the shape I want and stashing that locally as a bunch of files, which is really nice because it means that, you know, you can have a local build that actually doesn't depend on Contentful at all.

You know, because once it stashes them, it just holds them there. Actually even commits them to the repo, so I've got those bits of content versions as well. So if Contentful did go away I'd still have a viable build that works. But it also means then that I've got the data in exactly the shape that I want and then, I can update that and what have you, but I can present that as a bunch of files.

Eli: I found that with dynamic content like that, it can be kind of hard to manage. Do you have a certain workflow that works really well for you?

Phil: Yeah so, I guess the key word there is dynamic, and what you mean by dynamic. Before I kind of put this example together, I've been trotting out a talk that I've done quite a few times about static side structures and saying well you know, this can be much more dynamic than you think. And so I had this mouthy isomorphic rendering, it was a mouthful, dynamic static side strategies. Pretty hard.

Eli: It's a tongue twister.

Phil: It was idiotic to name a talk that so you had to introduce it to hundreds of people and always sounds stupid but also it really doesn't mean very much, but yeah the point of that was that static side could feel much more dynamic than maybe people think by having a very low friction content management workflow. And so when you're talking about dynamic content, really for me it becomes dynamic when it becomes easy to manage and update. When you drop the friction level for building out the site and updating the content.

Then it can feel very dynamic and very kind of responsive. And so that's why I particularly like this model where all of the content authoring administration, all that UI that's managed by Contentful, who do a really nice job of creating a usable, admin interface for that. The real people, not developers like us, genuine people, who just get to manage content, you know, they could do that in a way that makes sense, and then whenever they save that content, you know, that files a webhook that triggers a build and pulls in the content and off you go.

So in that way, content can feel very dynamic, it's fresh and it's updating all the time. And I've actually found that that has made this model actually produce sites that feel way fresher and way more dynamic than frankly much bigger, more expensive, more complicated CMSs have provided in my experience.

I'm in danger of taking the lid off another thing that I've ranted about and been damaged by in the past, but I think anyone who's done a lot of work on large enterprise-level CMSs has probably kind of had some sleepless nights and has some stories to tell, because they often are so complex. Because they can do everything for everybody, that it's impossible for anyone to do anything with them, because you know, it's just a lot to learn and they're very complex.

And so I've seen the dynamism of the content generated by some of these platforms actually being way lower than you know, this simple architecture I put together that actually is pretty resilient and you know, on first glance, might feel it's just a static site. Actually it feels much more dynamic, so the stitching together of a few good tools that are very good as a specific thing I think ends up producing a site that can feel really dynamic.

Brian: Cool. So I get this on Twitter, couple times. I actually answered this last night, and people want to hear more implementation details on how others are using JAMstack, and I think you're a good use case because you're not only talking about it, but can you talk more about your site and how you have your setup with this workflow and the JAMstack?

Phil: Sure.

Brian: You mentioned Contentful already, so can you explain a little more how that setup is working for you?

Phil: Yeah, absolutely. So, since playing with this, I've started to build out a few more sites this way. My blog site moved over from Hunter, Netlify a little while ago, but ultimately it's still exactly the same shape. But this kind of an example site is the subject of the blog post I've written. It's probably the one that feels the most dynamic and has the workflow that I think is the most interesting. But yeah, it's a very very simple set of templating and Gulp tasks to automate to build.

And I use Nunjucks as the templating language just purely because I like the syntax and I really like the fact that it has template inheritance and helpers in a few bits and pieces like that. It has a client, a Javascript client. But you know, lots of others could be used in the same way and Jade is one that I'm starting to come around to. I don't know. Mentioning Jade, so maybe there's going to be a few holy wars when that unleashes. I don't know.

Eli: I'd be on your side.

Phil: Okay, well.

Brian: I know Eli's a fan.

Eli: I do like Jade.

Phil: Okay, well I was dead against it for a long time, because I was always like wow, "I don't know about having another level of preprocessing in front of this stuff". I've actually really come around to it because of how well structured it is, how clean the syntax is, and I think you get some lovely utilities. So, anyway, that's by the by. I've built other sites that have used that as well. The architecture that I've gotten, the approach that I've got really is a bunch of MPM modules and some gulp.

It just means that it's very very easy for me to stand the development environment up. You know, I clone my repo, I run NPM Install, I have everything I need at that point. Then I have a task that gets the content, and stashes it locally.

Brian: You're getting the content from Contentful at this point?

Phil: Exactly. So that's kind of my production build if you like. But I also have a local build task, which does pretty much everything else, but just doesn't bother to go off to the third party to get the content. So whenever I'm developing, I'm just using that. I'm developing against cash content, the build is super quick, and it means that I can test everything locally and stage it all. But then when I'm ready to deploy it, then, now that I'm on Netlify, then I just push it to get and that triggers the build on Netlify.

And the build on Netlify is just the other command. It's the production build. So it does everything that my local build does, but before it does that, it goes to get the content from Netlify, so it just does that API request.

Eli: In conversation, it really sounds like a Holy Grail of sorts for building a lot of these things. Can you tell us a little bit about some use cases where you've used it in the wild on some of these big brands, like Nike or Unilever?

Phil: So, as it happens, that's next for me. Right, so I've done lots of places where we've used this model for prototypes and proof of concepts. The next challenge really is convincing large companies that this is a model that can work. Google do serve a lot of sites statically. They have their own workflow and infrastructure and static site generators that they use. They've already bought into the fact that a static site is ample for plenty of use cases. But for some of the other brands that you mentioned, I've yet to get this architecture out into the wild for anything into production, if I'm completely honest.

That said, I can't mention the name of the brand I've been working on recently, but I've been doing a bit of a side-by-side comparison of something that I built which is sitting on top of the CMS, that has some performance issues frankly. Because it comes along with a lot of enterprise workflows and architectures, versus the same exact functionality, content, behavior, and everything of a site that was being built with this model. And the performance of one versus the other is pretty dramatic when you compare the two.

And so that's been used as a way to actually, say this is the kind of infrastructure we need in the enterprise, but it's a big organization to try and shift the mindset off and they've invested lots in the particular workflow. So I'm not sure where that's going to go at the moment, but I wish I had more examples where I could say "yeah, well I've proved out this concept and everyone's ready to go".

But yeah that's what I'm trying to do at the moment actually, is trying to convince people that it's really viable to give them what they need. And that's kind of one of the purposes of why I'm shopping this talk around right now.

Brian: Yeah, it would be interesting to see a comparison once you get out of embargo stages.

Phil: Yeah, I'd love to be able to because the other thing that was really eye-opening in doing this little proof of concept is that one of them took many many months to work on, and the other one took two weeks. Granted we have the benefit of having, one side became the design reference for the other, and we knew what the behaviors were. So it's not a like for like comparison, but building out a site in a couple weeks to a level that you'd be happy to say well this outperformed what we built before is pretty staggering, really.

That is one of the powers of static sites and having complete control over the frontend code in the hands of the frontend developers, whose craft is making things go fast, and tuning it and working on performance and all of those kinds of things. So, it's been a very interesting tool for making a point. I'm really desperate to try and get some more of these things out into world because I think some of the larger organizations are still a bit reticent about you know, can we do everything we need with the static side?

Eli:

It's no mystery that static is the future.

But I think one of the big things is going to be trying to in terms of being an advocate for this approach, I'd love to hear more about some of the staggering differences in performance. So, do you happen to have any of those performance increase numbers? I hate to put you on the spot.

Phil: No that's fine. And, once we're done here, I'll show you some things that'll make your eyes water.

But off the top of my head, I've built this out sorry, we've built this out and tested it over a few different network conditions, because a lot of the bottleneck were large assets, delivered slowly over the network, blocking rendering and those kinds of things. So, and the starting point was not a good performing site as well, so it's worth pointing that out, but we are talking about under good network conditions, bringing like a four and a half second load time down to less than one and a half.

Rendering complete content over less favorable conditions. So I did a 2G connection, which you know, sounds dramatic, but 60 percent of the world is browsing on a 2G connection at best. And that was about a ten to twelve second render for this model that I'm talking about, which has got some very big assets in it, versus over a minute for the other one.

And ten seconds is not good. But once it gets to a minute, it doesn't matter how beautiful your site is, because nobody's there to see it. Right, so we put those two things together, put them side by side, it's really dramatic. Of course it's not just the size of the asset coming down the wire, it's like the number of requests. How those requests are packaged up. What's blocking the rendering, which is again why I really like this model of delivering HTML that doesn't need Javascript to render.

You know, get Javascript out of the way, get a full rendered page there so the user can style the reading content. And then behind the scenes, you're loading in the Javascript. So, switching from one to the other definitely had a dramatic impact and some of them so much so that it was hard to keep thinking about things to talk about while you're waiting for one of them to render, while the other one, you kind of finished looking at. So, yes, it was a pretty powerful demonstration.

Brian: Really, this has a lot of great applications on mobile for users that use a lot of mobile traffic on their sites and stuff like that.

Phil: Absolutely.

Brian: It would be really advantageous.

Phil: Absolutely. I mean I think optimizing performances is just good everywhere, right? But yeah, you got to be thinking about the mobile user. And it's not just about the fact that their connection might not be solid, very often, mobile users are sitting at home, they're on their wifi. That's not always the thing.

The devices have different ways of rendering the Javascript and different levels of power, and those kinds of things. So, yeah there's a lot to think about there, but optimizing performance just is good everywhere right? It's just a win across the board. But yeah, the mobile context was another one that is very interesting to demonstrate the two side by side.

Eli: Yeah, I mean you're talking just on wifi from what you're saying is almost 400 percent faster, and then on mobile, when you're using 2G or something like that,

Phil: I think it was 12 seconds versus 62 seconds.

Eli: So that's 600 almost 700 percent larger or quicker. So that is staggering.

Phil: Yeah, and I should say you know, this comparison we're talking about here, this is a platform that I think is suboptimal already that we're comparing against. But that's kind of that's one of the reasons why I'm very cautious about naming the company. Yeah, so I think

As soon as you start to give the power to the frontend developer, to control what happens in the frontend, they can really tune the performance and deliver stuff in the browser.

I used to kind of make jokes about how when I used to be a Javascript developer foremost is my kind of discipline, I'd talk occasionally about having conversations with people and saying "yeah, what do you do? Well, I'm a software engineer. Oh, what do you write code in? Javascript". And they'd just start laughing at you and say that's not a real thing. Because you know, everyone sneered at the frontend and thought Javascript wasn't a real thing, but times have changed a little bit you know, and I think we now recognize the frontend development is a really difficult craft.

You know, it's brutal. And doing it well is important. And it's a huge aspect of user experience and all of those things. It definitely used to be seen I think as well it's the output of the clever stuff in the backend.

Most of the things that we've seen which are crappy experiences along the way, have probably because the output hasn't been built by frontend developers.

HTML's easy, right? Anyone can do that. And style it up. And off it goes. But you know, we know now that it's a real craft. So you need to give people building this access to the tools and the control to tune it properly. Otherwise, bad things happen.

Eli: Absolutely.

Brian: Very cool. So you mentioned your talk a couple times. Are you giving this talk anywhere else in the wild that people can see in the future?

Phil: Well, it just so happened Brian. Okay, so we do have one this evening. The JAMstack meet up here in San Francisco.

Brian: Yup, looking forward to that.

Phil: And really I haven't got this planned as a talk I'm going to be giving anywhere else, but I'll be honest, I'm a tart. I'll go and talk anywhere given an opportunity. So if I get a chance to trot this out again, I certainly will. And the static site talk that I mentioned earlier on is one that has evolved over actually two or three years now from just starting out and saying I think you can go further and then starting to bring in different tools and different approaches as they've matured. I kind of thought that I'd retired it, but it seems to keep on evolving.

So I wouldn't be at all surprised if this morphs into something else. And then it gets into the wild again. But, certainly there are videos around, I think of some of the versions of this. But this particular one I'm doing at the JAMstack meet up I think it's probably the first time it's been out in the public in this way, so other than what's on my blog.

Brian: Cool, so hopefully we'll share that recording. And it sounds like, you mentioned it's two or three years old, that talk about static that you've been giving, it seems like it's even more evolving too because I mentioned on the way over here about GraphQL, which is a new way of manipulating your data into your frontend. So that's a whole new thing that Facebook's doing.

And they have this whole serverless architecture too as well, where not only can you talk to AWS and Lambda and Ager, and all those other things, but now you have a framework built around this to instead of now getting your backend team to help you out with this, now you're just writing like scripts to build out your entire architecture for your entire backend.

Phil: I'm really excited by Serverless I have to say. Because one of the things that I tried to squeeze into this talk was you know, where are the limitations? Because

Static sites are not good for everything. There are use cases that sadly we cannot satisfy.

But there are lots of places where it is bang on. And then what are the features that we miss? What are the features that maybe we could solve? It turns out there's quite a lot more that you could do than you might initially think.

So, I've had examples of search, and form submissions and those kind of things that are totally viable. You know, I have a really nice search implementation on my own site. It's a progressive enhancement. It's a page with a search form on it that if you've got no Javascript, it just goes to Google and it adds the site parameter of searching on my blog, and you get results. So that's nice. But then with progressive enhancement, the behavior is as you click on the search button, it doesn't take you to that page, it just gives you a text box.

And while it displays that, it also goes off to the server and gets the static file which is just a blob of JSON, which is you know, an index of all of the content across the site. And then just does some string matching. So, as you type, you get instant results. So it feels really snappy. And search is a complex thing. And this is a simple search solution.

But there's lots of examples like that where you can be a little creative and just start to add some of the features that you might think you might not be able to do with a static architecture. And Serverless is somewhere that I think you know, that opened things up way wider now because now you can just start handing off particular tasks to a real infrastructure in the background that can be dynamic. So you kind of get the best of both, which I really like.

Brian: Yeah. It's awesome. We're really looking forward to JAMstack's involvement in the ecosystem, how it's going to start expanding, and it's more and more awesomeness.

Phil: I'm really worried that I'll start to sound like a massive Netlify fanboy, but at this point I don't care. That ship has sailed. But things like the ability to control the url structure with the redirects configuration, that you have on Netlify, it's just so trivially easy, and powerful. The passing things through to some of these other services is kind of invisible and seamless. It just opens up the opportunities to so many things. I'm pretty excited.

Brian: It's about to get easier too. Our CTO's actually doing a talk alongside your talk tonight about how he rewrote that whole structure in Elm.

Eli: Oh nice.

Brian: So, more on that later. But, I'm going to go ahead and transition this lesson to picks now since we've had a quite a big robust conversation on isomorphic rendering.

Phil: I wish you'd say that without rolling your eyes as you're saying it. I know, I know you're judging me for using that buzz word but that's fine.

Brian: But keep the robot voice. Cool and then so picks. Basically, anything that we're jamming on anything that's keeping us going as far as developing, anything we're excited about. And since you are our guest Phil, we'll let you go first.

Phil: So are we talking about tools?

Brian: All of the above.

Phil: All of the above. Okay, well I mean I've already mentioned a couple of the things that I love in Contentful and Netlify. So I'm going to leave those aside, and serverless as well. But I know that in this section you kind of talk about other things that you're enjoying as well, like down to TV. I've just finished watching "The Night Of". Did you guys watch that?

Eli: Yeah.

Brian: Yeah, it was a pick a couple weeks ago.

Phil: Oh it was? Oh I didn't know.

Brian: No worries, that's your pick. You own that one.

Phil: I really gobbled that up. I thought it was amazing.

Eli: Don't ruin anything.

Phil: I wouldn't say a word, but all I'd say is the there's been lots of good TV recently, but this is the first program that's made me think "Is this better than the wire? I don't know. Could it be?" So yeah, I just thought this was staggeringly good. And then when it comes to music, I'm not very good at staying up to date. I've never sounded more like an Englishman than just then. I don't know what's in the hit parade. But I find myself listening to quite a diverse range of things.

I listen to a lot of Foo Fighters and that kind of gets my energy levels up, but it's not very good to write code to. So, things like John Hopkins and Kiasmos are both kind of a little bit more ambient and kind of electronic wallpaper I kind of like to think of them as. But I'm kind of enjoying those things at the moment.

Eli: Electronic wallpaper. That's such an eloquent way of putting things.

Phil: That's actually the name of my Spotify playlist that has all of those things.

Eli: I like it. Yeah so I guess what I've been jamming on lately while we're talking music, I've been really loving Bluegrass.

Phil: As a genre?

Eli: As a genre, but specifically this band called Iron Horse. And they take do covers of indie bands essentially, well they do other covers, but basically they take each album and tribute to either band or for example, classic rock in general. But they have an album on Modest Mouse, and it is awesome. They have another album on the Shins, and such a sucker for the Shins, that I can't help but love it.

And on the tech side of things, maybe just because it's fresh in my mind, but I've been really enjoying lunar.js We just redid our search on Netlify.com and it was extremely enjoyable taking something that a lot of people think stat sites can't have much search on it, and integrating it on the server side. It's just incredibly helpful and I liked using that with some gulp tasks to make it work. So, stay tuned to the blog. We'll be sharing a little about that soon.

Phil: Oh yeah, I want to hear about that.

You just reminded me. I forgot the most important thing. I brought you some jam. I brought you some jam. Now, this should be a sign of my dedication to spreading the jam. And again, I feel awkward as an Englishman trying to sound cool saying spread the jam. But keep in mind that I traveled here from London, and I very rarely check a bag in. I checked my luggage in so that I could bring you jam.

Brian: That's some dedication.

Eli: I'm honored.

Phil: I have three jams for you. I have here a Wilkinson Sons' strawberry conserve, from Tiptree in Essex, so that's a little beauty there you go.

Brian: Wow, that is a mouthful.

Phil: I also have another one from Tiptree, apricot jam for you. And then finally, I have McKay's seedless bramble preserve. Do you guys know what brambles are?

Brian: No, but I'm sure you'll explain it.

Phil: He says, rolling his eyes. Brambles are what we call blackberries in England. So this is a Scottish jam for you. So, this English and Scottish jam brought over in my luggage that I had to check but that's fine.

Brian: Wow. We've quite the collection at the office right now.

We've no bread though.

Phil: Do you just sit here eating it with spoons out of the jar?

Brian: At this point, yes. So make a note, office manager, please order bread. And peanut butter.

Brian: Cool, so my picks, yeah I have just completely baffled on this amazing jam selection product, picks, so actually I have a music pick which is Dustin Kinsrue, which I'm not picking him, he does a cover of the Wrecking Ball, which is Miley Cyrus's song. I listen to that maybe once, at least every weekend, and I just bring it off and I'm like wow this is amazing.

So Dustin Kinsrue, I guess he was the lead singer for the band Thrice. I'm not picking them either, because I'm not really familiar with their music, but this song is amazing. Look it up on Spotify. I guess that's our choice of music playing.

Eli: I've got this mental image of Brian swinging in on this wrecking ball in his house for like a Risky Business-esque thing.

Eli: Why did you do that to us now? Now I can't see anything else.

Brian: Well it's more indie than that so. So maybe not like Risky Business, maybe like I don't know, like Harm- rim glasses.

Phil: No but it's the image of you riding in naked on a wrecking ball that I'm struggling with now. But I'm sure you'd style it out.

Brian: There, this is the west coast. Actually, this is the bay area. Everything goes. Yeah, everything goes. Cool, and then my pick is actually Westworld. I happen to be the first to talk about Westworld on the podcast. Please watch it, it's amazing.

Phil: It's so good.

Brian: I guess our it's either going to be a Kanye pick, or an HBO pick for me. And this HBO series is amazing. So check it out. It's about like six episodes in at this point, I'll probably be wrapping up soon. I'm not sure how long it's going to be.

Eli: I hope not, it's amazing.

Brian: Yeah, it's basically not to give away too much, but it's like well Battlestar Galactica meets West. Super, super, intriguing stuff. So check it out. Cool, so that's all we got for the JAMstack Radio, so thanks again Phil for coming on.

Eli: Thanks for having me.

Phil: Hey Eli, thanks for coming on too to help with the conversation.

Eli: It's always a pleasure.