02:30 - Jeff Escalante Introduction

03:15 - Roots

05:20 - Static Sites vs Dynamic Sites

13:47 - Plugins 

15:48 - Multipass Compile Functionality

20:27 - Roots vs Other Static Site Generators

22:31 - Netlify

26:22 - HTTPS

Picks

ECMAScript 6 — New Features: Overview & Comparison (Aimee)
Jacob Kaplan-Moss: Keynote at Pycon 2015 (Aimee)
Dr. Who (AJ)
Power Rangers (AJ)
Marvel Digital Comics Unlimited (Joe)
GoFundMe (Joe)
Netlify (Jeff)
accord (Jeff)
Contentful (Jeff) 

Special Guest: Jeff Escalante.

 

Pseudo-Chuck, you are no real Chuck.

You have been judged and found lacking.

Aww.

Hello everybody and welcome to take two of episode 158 of the JavaScript Jabber. Today on our panel we have Aimee Knight.

Hello.

AJ O’Neal.

Yo, yo, yo, coming at you live from beautiful, sunny, not tornado-y, not snowstorm-y Provo.

And I’m Joe Eames. I’ll be your host. And today on our show we have a special guest, Jeff Escalante.

Hey there.

Hey Jeff, could you give us a brief introduction?

So hi, I am Jeff as previously mentioned. I am currently in Sao Paolo, Brazil. I am in the middle of a year-long trip that I am taking while sort of working on a limited basis for my company. My company that I’m working for is called Carrot Creative. And we’re owned by Vice Media. Vice, as in the website, the YouTube channel, the ones that do crazy documentaries and dangerous recording situations. And I’m currently traveling for a year and sort of trying to figure a life out step by step.

But luckily I have a pretty good internet connection here. And I was able to make this call.

Awesome. So, we’re here to talk about Roots. Could you tell us about Roots and your involvement with it and what it is?

Yes. So, Roots is a static site generator that I work on at Carrot. And it is the product of a problem that we’re trying to solve as an agency rather than a product company. So, a little bit of brief background where the need for Roots came from. A lot of open source out there that you’ll find these days is usually generously maintained and backed by large companies that make products such as Facebook, Google, Twitter. There are a bunch of them and they all make really wonderful things that are currently used by many people, which is just fantastic because open source is just fantastic. However, Carrot Creative is an agency. Rather than working on one single product that we maintain every time, we work on many small products that we make for many different companies. And we cycle through them relatively quickly.

And so, the set of problems that we face in order to become more efficient are very different from problems faced by larger product companies. And so, that’s really where the need to Roots came out from. And the core of it is that rather than setting up our configuration and the way that we build our sites one time and then go into that and maintaining it over time, we have to constantly be building up new sites from scratch. And based on this problem, in order to become more efficient we need to essentially figure out how we can find sets of patterns between all of the different websites that we build for all the different companies that we build. And then once we can find patterns between those, we simply try to pull them out and abstract them and figure out how to solve them. And so, Roots is a really good tool that helps us out with that. And it does it using static sites which I’m sure we’ll discuss more in a few minutes.

What is a static site versus whatever the alternative is? And what are the advantages?

So, static sites are something that we are big fans of over at Carrot. And we really enjoy working with static sites. The alternative is usually a site that you would go to the site and a server would compile the page potentially based on who you are and then serve up the response. And we like to call those dynamic sites. Whether or not that’s the technically correct term, we’re not sure. [Chuckles] But that’s usually…

So, the sites that do needless work for no reason. [Fake coughs] WordPress [fake coughs] WordPress. [Chuckles]

Yes, yes, you could say that. Tried to be unbiased but can’t deny that I sort of agree with that for almost every situation. We like to kindly refer to those as dynamic sites. And the reason that we like static sites so much, there are a lot of them and they’re all really great reasons. First of all, static sites are really fast. They are served much quicker because they’re all the way down to the metal. It’s just a flat text file that just has to be served immediately without any contemplation on anything else to the user right away. So, static sites are very, very, very fast.

The other thing is that they’re cheap to host. When you’re just serving straight files and not having to do any sort of complex logic, it’s less taxing on the computer that’s serving the site and therefore it costs less to host. Usually static sites [inaudible] are in the range of pennies for month, which to a company that makes websites for its main business is basically nothing. Right now I have a DigitalOcean box that’s $5 a month, their cheapest one. And I’m hosting 20 or more sites on that with no problem, which is just great.

Wow.

Another good reason is that static sites make it very easy to scale. Scale is a problem that’s usually discussed by large product companies that scale over time. I see many posts from products like Twitter and Facebook and Pinterest [inaudible] how they handle their complex scaling problems. Well, for us in the agency world, scaling’s an entirely different challenge. It’s never a slow, gain users over time. And that’s never really a sustained [gauge] in users. It’s usually that we’ll make some sort of site, perhaps some kind of promotion for a company. And the company will throw a marketing budget behind that in order to promote it. And suddenly, 10,000 or more users will be on the site within less than five minutes. And then a couple of hours later, we’ll be back down to 1,000. And by the next day, the promotion’s over and there’ll just be zero and the site will be shut down.

And so, that kind of challenge is something that we’ve faced a number of times throughout our company history. And it’s a very, very different type of scale. And it’s also very nerve-wracking because you either completely failed [chuckles] or you were successful. The site crashed or it didn’t crash. You can’t really have a temporary outage and then apologize to your users and have them continue using it, because it really is only a limited time. And people are not going to come back because they have [any accounts] in that particular situation. They just won’t go to the site and that will be a loss for the company. And it will cost a lot of money. For us, static sites give a lot of extra security because it’s just less complicated. It’s just a straight up file being served. You can use Nginx to serve it. It’s extraordinarily fast. It handles scale very well. It’s not something you really have to think about or consider deeply.

And so, static sites are really good, at least for us as an agency, for handling flash scaling problems where users are very, very rapidly spiking up and increasing, which are the most common scaling problems. For us and I’m sure that anyone else who’s experienced scale has also had similar issues at a time. For example, if your post went on Hacker News you would get lots and lots of users in a short period of time followed by very few users.

So, I’m interested in understanding more and talking more about how the limitations of static sites versus your typical dynamic sites. I assume that most people listening who haven’t done much with static sites are thinking, “Well, a static site can’t really do what I might need it to do,” just like a typical web application. “I’ve got to have something that’s your traditional dynamic site with a Node backend or something.”

Yeah, because you want to know, is the user logged in, what data do you present that’s userspecific, and make sure that that data’s SEO or whatever.

Yeah. So, could you talk to that?

Yeah, yeah definitely. So, this fits smoothly into the backstory of Roots itself which was that Roots started out as a side project that I would work on if I ever had some downtime in between client projects. And it grew out of that to become a use tool for us at Carrot. And it’s now something that I work on fulltime. And we have a couple of other staff members that work on it with a decent amount of their time, because it’s just been extraordinarily useful to us for getting our work done more efficiently. And we started out working on this a couple of years ago when Ruby on Rails was just absolutely dominant within the web world. And almost every web shop was a Rails shop. And if not, they were looking to hire Rails developers. We were a Rails shop at that time. But we did a bunch of smaller sites as well, just small promotions or a microsite or a splash page or something like that. We had a decent flow of those incoming that we just had to knock out.

And so, that was where Roots came out of, was just being able to really quickly knock out those little sites without having to pour too much time into them. And so, at the time it was definitely useful to us. And over the course of us using it more and more we started falling more in love with static sites for all the reasons that we’ve just discussed previously. At some point there was a major change in the way that most people would start to build web apps. And Node came out during that time and it started becoming more stable. And more people started using Node and building tools that were made with Node. And on top of that tools like Backbone started to emerge and introduced the concept of client-side MVCs where you could use JavaScript on the client-side that would just interact with a simple API as the backend rather than having a monolithic frontend and backend rolled into one like Rails did.

So, this is a concept that we started exploring a little bit. And it was super interesting to us. We really liked that way of building sites. And on top of that, it also made static sites even more useful to us because with that kind of outflow you just build a regular static site as the whole frontend. And then separate from that you would build a simple API that you could use in your backend. And JavaScript would be the glue between the two. And so, when this happened there was a lot more usage for static sites for us. On top of that, static sites became an essential part of how we would build dynamic-ish sites where you would be able to login and do all the functionality that we were talking about earlier that usually you would require a dynamic site in order to do. And so, this chain of innovations in the way that apps were built in JavaScript allowed a simple static site to be paired up with a simple backend and make a really wonderful, dynamic, whole-featured application.

So, it sounds like you can get the best of both worlds doing it that way. You can get all of your performance and SEO benefits of having a static site. And when a user logs in you don’t need any SEO anyway, because it’s their content that’s specific to them. So, you can present them with something immediately, have their session in a cookie or local storage or something, and then start building the API that they need to interact with as a single-page application.

Yeah. There’s a bunch of benefits to it. That’s definitely one of them. Another great benefit is that it breaks down [inaudible] or at least it breaks down the product to be more a Unix philosophy type thing where the backend logic is self-contained but it doesn’t also mix itself up with the frontend magic. It’s just the backend logic and the API [inaudible]. Very straightforward, very simple, very self-contained. And one developer could work on that alone in any language they preferred. The frontend is completely separate. And it’s just the API endpoints that form the communication between the two.

So, not only is it a little bit more modularized and offers you more flexibility in the way that you build it, but also you can still use static sites. You still got really great performance. When you’re using JavaScript interaction as you guys probably know, you can make assumptions like automatically assuming that something succeeds instead of waiting to check if it succeeds. And then instead, just notifying them if there’s an error which is unlikely. So, it appears as if the page is responding instantly just like Gmail or any other single-page app that you see these days.

So, what is the process if someone were to want to build plugins for Roots? Do you have anything like that? Or is it just internal right now?

We do. It’s rather complicated at the moment. And it’s complicated because we wanted people to be able to do a lot with plugins. And so, in order to build a plugin you have to understand a lot about how Roots works internally. It’s not really so much like an API where you don’t really know about how the system works internally and it just exposes these certain things to you that you can use. Because when we do that, we have to basically just predict what people are going to build and then give them these endpoints to build it. And at that point, we might as well just build it ourselves, because we already know how to do it. We’re already writing the code which will expose these pieces. So, it doesn’t work like that because it’s a different kind of deal. It’s not like using Roots, do this. That’s what you use Roots for by default. You use it to make something.

If you’re doing plugins you have to really dig into it. But you can do plugins. Roots has a relatively complex internal pipeline because it can do really complex compiles. For example, it could take a file with three extensions, two of which are compiled into two different languages, and one of which is statically compiled. And it could compile the first into the second, detect that the second is not a language that you have support for, and pass it on. And then to the third one it would run another compile and then output it with the correct extension based on the one that you wanted to target. We call this multi-pass compiles where it can run each specific file through multiple compiles for different languages. And on top of that, since it’s built with Node it’s running everything in parallel. So, it’s doing everything at the same time. It’s not really stepping through things piece by piece. And so, that can get really complex to understand and make sure it’s working correctly.

So, explain that multi-pass compile to me. Because I’m curious to why that would be necessary.

What is the utility there? Give me a use case.

Yeah, sure. So, we built that functionality with a very specific use case in mind originally. And since then we haven’t really used that. But then we have found other use cases for it. So, I’ll talk about both of those. We like to use compiled languages for everything. So, we use CoffeeScript, Jade, and Stylus as our defaults. These are all JavaScript-based languages. And Roots is written in Node. So, that’s why these particular ones are used. But we really like the advantages of using these languages because they just make life much easier and everything go much faster, because you have to type less. And they’re just more powerful than basic HTML and CSS. So, what we wanted was originally to be able to add another layer on top of those languages that would give us bases where we could slot in and out content based on a content management system.

So, you would have for example something like EJS which is the same as ERB for anyone that’s familiar with Ruby as a templating system that is not sensitive to whitespace, not sensitive to anything else. It just looks for tags and does replacements. And then sit that on top of another language, like Jade or if you’re more familiar with Ruby, it’s like [inaudible] Haml. And sit that on top of that language. So, that would be two compilation steps into each other. And so, this was the use case for which we originally built this system. We ended up not using it for that after experimenting with it for a while because we preferred piping in the information as locals, just in the default language which is Jade. And let me know if this is way too [inaudible]…

So, by local…

JEFF: context or confusing.

By locals you mean individual components? Like I’ve got one main Jade file and then I could import a Markdown file or import an ERB file or import something else that’s going to come into that content?

Well sort of. Not exactly. In Jade you have the ability to process JavaScript variables since Jade is processed by JavaScript. So, you can make a JavaScript object available to Jade and then you could iterate through that object and output the pieces of it. And so, the way that basically our content management within Roots, which we might talk about a little bit later, works right now is that it will go fetch the content we need, format it out as JavaScript structures, and then make those variables available to Jade. And then you can just iterate through them in Jade, like just do a for loop through your blogpost rather than having two languages stacked on top of each other.

But there are use cases for having stacked languages. And we recently found one in our experiments with React. We’ve been messing around with React a little bit just because it’s been a topic of interest in development. We wanted to check it out. And we like the idea of React Native bridging the gap between writing code to the web and writing native code. We vastly prefer writing code to the web. So, if we could write code that works for the web and also have that work natively, we would love to do that. And that seems to be the area that React Native is handling.

So, we’re investigating React. We want to make this available in a number of circumstances. Like I mentioned earlier we enjoy using CoffeeScript. And so, React has their own preprocessor called JSX which basically is just writing a weird version of HTML into your JavaScript directly. I’m not sure how we feel about that. It’s a separate topic. [Chuckles] But in order to use Coffee with that, that’s stacking two processors on top of each other. So, you’d have to compile out of JSX into Coffee and then you’d have to compile Coffee down to JavaScript that’s already been processed for JSX. So, that’s a multistep right there. And without the multi-pass compiles you aren’t really able to handle that. And so, for a little gap in between, multi-pass compiles weren’t handling any real world use cases for us. But I was confident that we would run into a situation where we need it.

And writing our architecture in that way is such a huge difference between assuming there’s always only one pass per file and the ability to make multiple passes per file. It’s probably getting into too many details. But the changes you have to make to your internal architecture to handle the difference between those two situations are absolutely massive. And so, for a while it’s sort of a better safe than sorry kind of deal. And now I’m really not regretting it because I think as more compiled languages start coming up we’re going to start seeing more situations like this where it ends up being useful. And it’s not a feature that any other static generator has.

I’m also curious about comparing it to other popular static site generators like Ghost.

Yeah, so I would say that most static site generators you find right now specifically service blogs. And for both Ghost and Jekyll, the ones that were mentioned, those do both specifically service blogs. And so, if you want to make something other than a blog, you run into some issues. And it’s like WordPress. WordPress is, I’m sorry, this is [inaudible] but I’ll make sure I’ll connect it. WordPress is a content management system centered around blogs. So, if you want to make a site using WordPress that’s not a blog, you have to hack. You have to use PHP or you have to purchase some code through somebody else that has it.

And then your server gets rooted and everybody’s angry because they all got [served viruses]. [Chuckles]

Yeah, yes, exactly. The overall point of it which I’m sure that everybody is on board with is that you just don’t want to have to hack things into behaving the way that you want to, because it’s always going to come back to bite you just like technical debt. It sort of is technical debt, because now you’re just like, “Oh, I could make this work. But it’s not really what it was intended for. Well, let’s just see if we can get by with it.” You can’t. Eventually it will do you in. And so, while you could make a blog with Roots that’s not really its only intention or its main intention. We use it for a bunch of different kinds of websites. Any kind of content that you need in there, arranged in any way you want with any sort of metadata is totally fine.

And so, for that reason I don’t really like comparing it to static site generators that are targeted specifically towards blogs, because they’re different products. If you want to specifically make a blog, one of those might actually be a better product for you. Because it’s targeted very specifically towards blogs. So, you better believe that it’s going to have the tools in there [chuckles] for you to make a blog. On the other hand, if you’re not making a traditional blog chances are that it won’t be as good of a tool for you because you might have to hack it out. Roots is just a slightly more flexible option in that way that it’s not as tightly focused on one use case.

So, something that you talked about the first time we did this when it didn’t get recorded…

Was it Nets? Netible or Netly or something like that?

Oh, yes. Netlify, yes.

Netlify.

So, if I recall correctly the question I was asked the first time was, what’s a cool example of how you could push the limits of static sites? And one thing that we have done so far which we were really proud of and we think is really cool is that we have essentially made it so that you can use WordPress as a backend for a static site frontend that live updates. And so, how it works is that for the user you’d essentially have your developer make a Roots site. You’d make a WordPress site. They would take the URL and load that into Roots alongside a plugin that does WordPress integration. And it would produce all of your WordPress data as data that’s available to any of your frontend templates. And you could essentially just set it up so that you have a blog that’s been created as a static site, which is very cool. Because we feel like almost all blogs should be static sites.

Now, what’s more interesting is that, like I was talking about before we have this really cool service called Netlify. And these are guys that we have been working with for a very long time. And they are super interested in static site hosting and trying to push the borders of what you could do with static sites but through the hosting, which is an absolutely essential part of how to do it. I would highly recommend checking out Netlify if you are into static sites. And there will be a link to that surely in the notes. But essentially you can use web hooks for this. So, what we do is put in a small plugin into WordPress so that you can make web hooks available. And then through the plugin and through Netlify it would sync your static site whenever you made an update to your backend.

So, if you went in and edited one of your posts, it would notify Netlify. Netlify would go and grab the source of your site and recompile it and then deploy your new optimized site out fresh. So, you would make an update, you go back to the site a minute later, and you refresh it and your update is live but it still is served up as static. So, it’s basically a static site with a whole new functional backend, which is something that I don’t think has been produced before and we’re super excited about the possibilities that come with something like this. Netlify in a separate note does a bunch of really cool things.

First of all, let’s just mention they have support for web hooks which is really great and enables a bunch of core functionality that you can jump on. Second of all they do a lot of really good optimization. So, they will optimize your assets if they haven’t already been optimized. And they will put them all on CDNs, content delivery networks, in order to make your site load super-fast. And third of all, it’s very intelligent. So, it’s not just a file dump. It will hold onto the source files of your site and it will recompile your site when it needs to or when you want to trigger it by any kind of trigger that you want to give it to it. The example said earlier was when WordPress changes it updates. You could have any sort of trigger go and update your site. And it will notify you by email if something went wrong when it was compiling, which is super neat.

So, it’s like an extensible GitHub Pages.

Yeah. And on top of that, they have a feature where you can hook it up to write to GitHub. And whenever you push to your GitHub repository, it just recompiles your site and deploys it. Now, this is referred to as continuous deployment, a very, very cool strategy. And it makes it so that you could even have an open source documentation website or whatever it is. And as soon as you accept a pull request to that site into master, it just goes live automatically. That’s it.

Now that is fancy. I like that.

Really, really cool. We really, really like this capability. It’s just less time wasted. It just works the way that you want it to. You can choose the branch. You can choose your rules. And just let it deploy for you.

How’s the HTTPS support, because that’s my one gripe with GitHub Pages.

Yeah.

Is I don’t want to serve anything insecurely right now.

It’s very good. In fact the founders of the service are big proponents of HTTPS. If you’re interested in this I definitely recommend having them on the show. We’ve spent a lot of time talking to one of the developers behind it. He’s an absolutely great guy and we work closely together. Just because we try to push the limits of what you can generate with static sites and he tries to push the limits with how you can host them. So, it’s a very good partnership. And I’m sure he could speak better to it. But I know that he has a couple of articles that he’s written up and blogposts about the advantages of HTTPS. And if I’m not mistaken he recommends using HTTPS for all static sites, whether they have secure content or not. And there’s a big list of reasons that he recommends it for. And I will find a link to that for sure and send it through to you guys.

Yeah, I can attest too, with research I’ve done recently. Because I’m working on a home cloud system. And it is just absolutely inexcusable to use HTTP. If anybody out there is using HTTP you need to switch. And I cannot explain to you in 30 seconds why. But there are so many vulnerabilities on the web. And just leaking user content, it’s just, it’s bad. It’s really bad in ways that you just can’t possibly understand until you research it.

No question. If you’re logging into anything, you have to be using it. But what’s crazy is that he even recommends using it just for no users, no login, just a regular, just the content…

Oh, I think so, too.

Static site. It appears as if you should be using it for everything. And I’m guilty of certainly having some sites that don’t. So, I got to get my own act together here, too.

Well, just as a side note, Let’s Encrypt is launching soon. And they’re going to have a Node, Python, and Go plugin that you just add into your stack and it’ll automatically regenerate certificates on the fly. So, you can have it on dynamic servers, even.

Very nice. I’ll have to check that out. Can you get a free certificate from these guys?

Yeah. Let’s Encrypt is a partnership between Mozilla and some European certificate authority.

Oh, yeah.

And so, as soon as they flip the switch, there’s already code in the repositories that you can download and test out. Some of it, it’s got a couple of bugs that needs to be fixed.

Yeah, yeah, yeah.

But at some point during the summer, I’m guessing August or earlier, they’re going to flip the switch. And then instead of issuing you fake certificates it’s going to issue real certificates. They’re just vetting the security process and everything right now to make sure that there’s no insecure process where you could attack and get a certificate for a site that you don’t own automatically.

Yeah, this is the real deal. This is great. I’m really excited for this.

Me, too.

There’s one super sketchy certificate authority that you can go through all these really questionable steps and their really crappy website in order to get a free certificate.

That sounds like every certificate authority I’ve ever used. [Chuckles]

Yeah, but most of them are very expensive, too. There’s one site where you can get free ones.

[Inaudible] SSL?

On other ones, you have to pay $200. Yeah, I think that’s the one.

No, here…

But this looks like it’ll be much, much better. And automated helps.

So, here’s the thing. If you go with name.com, they buy in bulk. So, you can get a certificate from name.com for just $10. The ones that are $200 are EV certificates.

Yeah.

And so, there are two types. There’s reseller EVs and then there’s first-party EVs. So, the firstparty EVs are from Norton and Thawte. I guess those are actually the same company. But they’re on that tier. And those are the ones that you pay $1,000 for. The reseller certificates are the ones you pay $200 to $500 for. I think GeoTrust is one of the middle tier ones. And the only difference in the certificate is if you’re paying $200 they’re going to call you up and ask you for your driver’s license and some form of government ID kind of thing to verify your identity. If you’re paying $1,000 they’ll probably actually run a background check on you or something. And in terms of the certificate there’s no difference in the encryption. The only thing is whether the EV bit is flipped on the certificate. And the only thing that that does is determine whether it shows a green lock or a green bar with the business name in it.

That’s crazy. What I’m thinking about is if you want to use HTTPS for any site, we’re talking about your small personal blog, we’re talking about the website you made for your neighbor who has a small bakery or something, you’re not paying $200 for an SSL certificate for that. So, that’s why people are using HTTP, you know?

Yeah, well name.com…

This would change that up.

Yeah. Name.com makes it affordable. And then LetsEncrypt.org is making it absolutely free. And I’m really looking forward to that, because we cannot have a pure web without Let’s Encrypt, because we cannot…

Yeah, because [inaudible]. This looks great.

Yeah. That’s one of the big things with the home cloud system I’m working on, is all of these peers, they have to be encrypted. And I can’t just fake certificates and create a whole, what was that thing that Lenovo had? I forget what it was. Sometime this year or late last year, Lenovo as part of their advertising partnership allowed one of their third-party applications that’s preinstalled to tamper with the SSL certificates on the machine and create a huge exploit in every single Lenovo that was sold during that time period.

Oh no. [Chuckles] No.

You don’t want to be fudging certificates by manually creating your own authority and shipping that on devices with hacked code into the SSL layer, because it will bite you in the butt. And it will bit hard.

Yeah. And I’ve tried to do that on a number of occasions just because I was like, “This site is just not worth paying hundreds of dollars for a certificate.” [Laughs] And it never went well. So, this is great. I’m excited for this.

Alright. Well, let’s move onto picks then. Aimee, you want to go first?

Sure, I’ll go first. The first one I have is a cool site. It has ES 5 code and then shows you the ES 6 equivalent. So, I thought that was kind of neat to go look at what the two looked like in comparison.

And the second one, I saw this tweeted all over this weekend. It was the keynote from PyCon. And I just thought that it was really good. It just talks about community and how we compare ourselves to each other and that sort of thing. So, I thought it was really good. Those are my two picks for this week.

Awesome. AJ?

I’m going to pick Doctor Who. I’m not a Doctor Who fan. It’s just like Power Rangers for adults. And I can’t help but put it on and let it play through.

[Laughs] That’s an awesome comparison.

It’s not even Power Rangers for adults. It’s like Power Rangers for the same type of people that watch Power Rangers. But somehow I’m morally okay with watching it whereas I’ve put Power Rangers behind me.

And I also want to pick Power Rangers. Because hey, it’s the only show that I watched as a kid where they’ve gone through 30 different types. Because there was Power Rangers and then there was Turbo Rangers, Thunder Rangers, Zeo Rangers, Ninja Rangers, Save the Forest Rangers, Time Rangers, Universe Rangers. I don’t know what they’re up to now, but that takes skill to rebrand 20 to 30 times since I used to watch it.

So, I’ll pick that, too.

We weren’t allowed to watch Power Rangers in my house because whenever we did my little brother would run around with a big stick and try to beat everyone up. So unfortunately, I don’t have much experience with it. But it sounds pretty good.

If you watch Doctor Who, it’s slightly better acting and slightly better visual effects.

[Chuckles] Alright.

Alright. I’ll go next. I’ve got two picks. The first one is something I just barely heard of and I can’t believe this is the first time I’ve heard of this. Marvel has a service called Marvel Unlimited which basically gives you access to 15,000 different comic books for a monthly subscription price of $10, which is obviously crazy. That’s so awesome. Myself, I’m not necessarily a huge comic book fan. I just haven’t read them very much. But I do like to read the occasional one. But it also includes something like 500 different Star Wars comics. And will include all the new Star Wars comics that are going to be coming out soon as part of the new sort of reset of the Star Wars universe going along with the new movies. So, I’m excited for that. I think that was really cool that you could pay a subscription, get access to all those comics.

And then my other pick is going to be in general, GoFundMe. I recently got involved for the very first time with a GoFundMe campaign for a niece of mine who’s special needs with some intellectual challenges. And she’s competing in this Miss Amazing thing and she wants to go to the nationals. So, we’re trying to raise some money from friends and family to send her off to this national competition in California. But I was just really impressed with GoFundMe, how well they worked, how nice and easy it is to take a really great cause, put something together, and invite people to give to what you consider to be a really great cause. So, that would be my second pick.

Jeff, you want to go with your picks?

I must say that I must not have done enough research when figuring out these picks. Because all of my picks are related to what I was talking about. [Chuckles] My first one was Netlify which we already discussed for a little bit. It’s a really nice host for static sites. We use it for quite a number of things and it’s been super useful. I definitely recommend checking it out. We’ve already hashed out its capabilities, but I certainly would recommend checking it out

Here’s some self-promotion for my second one, because I’m shameless. We have open sourced the particular engine that does just the compilation in Roots by itself. It can be used for many other purposes. It’s basically a wrapper over a large number of compiled languages that normalizes all of their options so that you can pass in a consistent options object. And it’ll also normalize source map output. So, it’s been very useful in Roots. But a lot of other people have found it useful in any other things that they were working on that compile from one language to another. And so, I hope that it will be helpful to somebody if they end up checking it out.

Okay, third one is a site called Contentful. And it is something that we have also found to be very useful when managing content. It is essentially a CMS that rather than locking into a very specific way of building the frontend with their templating language it simply exposes an API. So, it manages the content. It is very user-friendly for any non-developers to use and update things. You can create your own structure of what the content is and what fields it has, not only for blogs once again. It exposes a really nice, clean API for you to use as a developer and integrate into any site that you want, across any platform, on native, on mobile, desktop, whatever you need. It centralizes your content. Very useful and as a side bonus there is a plugin that will integrate it with Roots, so you can make your output static as well.

Awesome. Love it. Alright, well thanks for being on the show, Jeff. We really enjoyed our time with you. It was a great episode, very interesting. And thanks everybody for listening in. We will see you all next week.