Ep. #64, CDN for npm with Michael Jackson of unpkg

Brian Douglas: Welcome to another installment of JAMstack Radio.

On the line we've got Michael Jackson, how are you doing?

Michael Jackson: Hey, Brian, thanks for having me on the show, man.

Brian: Excellent, yes I brought you here because of unpkg.

So I'm happy to talk about that, but do you want to tell the audience in case they happen not to be familiar with you?

I'd be surprised that they weren't, but feel free to tell us what you do and how you got here.

Michael: Yeah, well, I think just about everybody on the planet is familiar with Michael Jackson, although they might not be familiar with me.

So, sometimes I have to do a little bit of disambiguation.

Yeah, so I'm a software developer. I live in California, kind of in the San Diego area.

I always love to meet up if you're ever, anybody's ever down here.

I've been doing software development since about like 2008, primarily JavaScript.

At the time I started doing software development, I thought JavaScript was huge, but I had no idea how big it was going to get and how it was really going to play such a major part in the future of software, so anyway.

Brian: Excellent. And so 2008 is that beginning of ES5 or ES5 has already been around?

Like I'm trying to understand placement of when JavaScript was--

Michael: You know, I remember back then.

I remember there was a shim from a guy whose name is Dustin Diaz.

That's a name that'll maybe ring some bells for people who've been doing JavaScript for awhile.

It was like a ES5 array methods, shim.

So JavaScript didn't always have filter and map and things like that on arrays, right?

And so I remember, like that was one thing that I would include in all of my projects is like, oh, I can use these fancy new array methods because it was something that, it was just a polyfill really that wasn't available in all the browsers.

But yeah, that was around the time that, that stuff was just kind of coming on the scene prototype was a big library, prototype JS.

Some people listening might remember that one.

And of course, jQuery, I was personally doing a lot of MooTools back in the day.

It's actually funny because I look back and I had a couple of commits on the MooTools repository.

Like when I got involved with MooTools, it was actually called Moo-FX, moo.fx And it was just a little library for doing like, it didn't do AJAX or anything like that.

It was really just for doing little animations and transitions in the page.

And I actually got a couple of commits in there and then moved on to jQuery.

But it's funny, I just, I look back at that time and I'm, I think at the time I, again, I, like, I thought JavaScript is a lot more mainstream than it was.

And I thought like all of the things were.

Brian: Yeah.

Michael: But I was just in a little bubble.

I didn't realize like, most people weren't doing it back then and it since become huge, but.

Brian: Yeah, and now there's no bubble or at least it's a very much larger bubble.

Michael: Oh, it's amazing to me the things that people are doing with JavaScript nowadays.

I don't know if you remember Steve Yegge it, a Googler who wrote a blog post, probably around 2010.

It was called like "The Next Big Language," and he didn't want to name it and say what it was, but he was talking about JavaScript and he was at Google at the time and he saw some of the stuff that Google was doing with JavaScript.

Obviously they built a full documents spreadsheet, editor stuff in the browser with JavaScript and he's like, "oh yeah, you know, "this thing is going to be bigger than C. "Like it's going to be huge."

And I remember thinking at the time, like, "Is he talking about JavaScript?" Because I don't think that it's going to be that big, but it was, you're right, it's huge, it's a global community at this point."

Brian: Yeah, and it's fascinating to see the evolution, because I came in towards the tail end of ES5 years.

So like my JavaScript didn't really get serious, other side of like copy and pasting some snippets, until like 2012 when I started actually building projects.

But prior to that was like, JavaScript was great for doing like the manipulation and like Google Sheets and stuff like that.

But what was interesting around that time too, as well.

And even when I started is that, there wasn't a lot of like talk around build systems and doing stuff outside of the script tags.

I always, I didn't know how to do it, and--

Michael: Absolutely.

Brian: Yeah, so like you built unpkg and you're maintaining it still.

And I'm curious, like what's the story behind that? And like why, why unpkg?

Michael: Yeah, well, I mean, you talked about using script tags and no builds.

I mean, there's still a very, very large percentage of the world population that doesn't have a built.

People just dropping script tags into HTML pages and it's a beautiful thing, it's beautiful.

I think because it's human and that's, the web is kind of messy. The web is, is human.

And so like people are just kind of building things however they can, right.

And, not everybody has their perfect build set up with parcel on the latest Webpack or whatever, as the latest and greatest thing.

And that's another I think bubble that I was in, when I started working on React back in like 2014, 2015, I was like, well, everybody's building apps with, they've got their build step now because we're all using JSX, right.

And we all have, Webpack is doing our build for us. And there were some people who would show up.

So I was working on a project, I still do work on a project called React Router. And I was working on it at that time.

And people would show up in the GitHub repo and they would say, "hey, can we use React Router with a script tag?"

Like I'm not using a build. I don't have a fancy Webpack build. I really just want a script, I'm using React.

I've got a script tag for React. I've got a script tag for React Dumb. I just want a script tag for React Router.

And we were like, oh, huh, all right. So you need a script tag. Okay, so we didn't have it published like on a CDN anywhere.

And so we thought, well, maybe we could just like commit it to our GitHub repo and then they could link to it there.

There was another project out at the time called CDNJS. And CDNJS is actually still going really strong.

Brian: Yeah.

Michael: It's sponsored by Cloudflare.

I think Cloudflare is basically brought the project in house now.

The CDNJS was basically just a, it was a GitHub repo where you would commit the files that you wanted to be on the CDN.

So, jQuery would publish a new version and they would put, that version of jQuery actually in this GitHub repo.

And then that file would be available on the CDN.

Brian: Wow, that is fascinating. Just sorry to interrupt. I had no idea about that.

Because I wouldn't actually use script tags from places that would point to the CDN that JS.

Michael: Yeah.

Brian: But I didn't know how to upload stuff myself to CDNJS.

I was like, ah, just add in here I guess I'll trust it. But I had no idea that it was actually GitHub repo.

Michael: It was just files in a GitHub repo, right?

Brian: Wow.

Michael: Which after a while got a little unwieldy, right. Because--

Brian: I can imagine.

Michael: Yeah, I mean, if you have like, people are releasing, patch versions of their libraries like, I don't know, every couple of days every week or whatever, and that code accumulates.

So I think this was like 2015. I was like, okay, I'm going to go and add React Router to CDNJS.

And so I went to check out the repo and the clone operation took me about 30 minutes.

So I was like, ah, I don't know. Alright, well, clones done, that's fine.

Okay, I'm going to check out a new branch out to put my library in there.

So I checked out a new branch and checking out a new branch in a large repo.

If you've never worked in like a repo that is several gigs, it can actually take a while.

So like checking out just the process of checking out a branch takes, maybe 30, 40 seconds.

And so this repo was like huge and it was kind of unwieldy, but I was like, you know what, whatever, it is what it is.

I'm going to get my code in here. I'm going to commit it. And I'm going to push, and, submit a pull request to CDNJS.

So I did that and then there was like some comments in my PR that was like, oh, well, like I apparently I had done something wrong.

I tried to like do everything right. But they apparently had done something wrong.

So like, you need to go back and fix this and this. And I was like, wait a second.

Like, I'm going to have to go back and do another checkout.

It's going to take another minute and then like fix it and then do another commit.

And that's going to take another and I have to say, I was, I think I was just a little impatient at the time.

And I was like, I bet I could just build a proxy to npm. In the same amount of time as it's going to take me, to like fix this and submit another PR. And so I did.

I remember I was like in an airport one night, I was in, so I've done a lot of traveling for my React training business.

And so I was waiting to get on a plane. I think I was in Boston that night.

And I was like, okay, I got an hour before I hop on the plane.

I wonder if I can like hack together a reverse proxy, because we were already publishing in our npm package.

We were publishing our global builds that you could include in a script tag.

And so what a lot of people were doing is they would npm install, React Router, and then they would grab that file out of node modules.

And they would put that in their script tag, right?

But these people, there were other people who were saying, we just want to CDN is what they said like.

We want it hosted on a CDN we don't want to have to npm install anything.

So I was like, okay, well we already have the files that we're publishing the npm like I'll just build a reverse proxy and then boom.

And now I'll put it behind Cloudflare and then they'll have a CDN or they can get React Router.

So the first version of it, I called it npmcdn.com.

It's a lot of letters but, people who DEV, that they know what that stands for right? npmcdn.com.

And I put it up there and it, like I said, I built it in like an hour and I put up the link and this was almost five years ago.

So this was like November 2015, and I tweeted about it.

And I remember it was so funny that, I did it so quickly because I tweeted about it and I hadn't yet even made like a homepage for it or anything.

So like, it was literally just like, if you went to npmcdn.com, it was just a blank white page.

You had to actually put the package name in the URL in order for it to do anything interesting.

Brian: Yeah.

Michael: Like what website does that?

Just gives you a blank page and then you, like, you have to manually punch something in the address bar for it to do anything cool.

So anyway, so I did that and then somebody, replied on Twitter, they're like, "hey, you should probably like put a, read me up there or something, so like people know uses because like that's not very useful."

And so I did that and I remember being like super stoked because, now we have the CDN problem solved for the people who are using React Router, but then other people started using it as well.

Because other people were doing the same thing we were, they were publishing, UMD or global builds of their libraries to npm.

And so they started, putting it in there, read me like, "hey, just link to unpkg.com/low-or/, React itself recommends, that's how you do if you want to use React in the script tag, you just linked the unpkg.com/React and off you go.

And over the years we've evolved it, you know, so that it supports things like integrity checks so they can, make sure that you're actually loading the code that you think you're supposed to be loading on the CDN so you don't get a sort of man in the middle attack and things like that.

But yeah, it just started with my, sort of impatience and, just a sort of idea that I had to build a little reverse proxy in front of the registry.

Brian: Yeah, that's fascinating too, like the timing wise.

Because I remember maybe it was probably a couple of years later when I actually started using it regularly.

And it was because when I worked at, Netlify the recommended solution for Netlify CMS was unpkg and I'd heard of unpkg, but never used it at that point.

But some other people on the engineering team was like, oh, just use this, we don't need to like, create a bundle and a UMD or whatever to make this work.

One place npm. So I wonder how many now developers love this tool because they don't have to sort of ship their bundled version of their packages other places.

Michael: You're already publishing the npm right?

I mean, that was one of the really nice things about it is, if you're sharing JavaScript nowadays you're publishing to npm.

And so it's something that, fits really well with your existing workflow.

You're already publishing the npm might as well just publish, you're probably publishing a few different builds if you're publishing a JavaScript library nowadays.

So just create one for the browsers and put that in your package and then you automatically have a CDN for it.

Brian: Can we go back and talk about this reverse proxy and like understanding if maybe listeners aren't familiar with what that means and how you sort of approach that?

Michael: Absolutely.

Brian: So you're actually not physically hosting or have a database of a bunch of packages that you're maintaining and one day you're going to unleash them to the deno.land or whatever.

Michael: Correct, yeah, so I don't have a, I don't have a big, S three bucket or something with all of the packages in it.

The way that unpkg is built is it's purely just a reverse proxy.

So reverse proxy is it's kind of a confusing term, but the basic idea is that, on one end you have the client that wants to load the code from npm, and on the other end, you have npm and in the middle sits this reverse proxy.

So you make a request to unpkg and it turns around and makes a request to npm, which I think is the reverse part of it.

It turns around and makes a request to npm grabs the tar ball and then finds the file that you want extracts it and then gives you that file.

And so there are other, reverse proxy services that can even Service Workers themselves in browsers.

If people who are listening to this podcast might be familiar with Service Workers are kind of reverse proxies in that sense, right.

You have a request that's coming in from somewhere and you have the ability to either just respond to it directly or, go and make another fetch to somewhere else and respond with, whatever you got from there.

So, same kind of principle.

Brian: Yeah, so we actually had an entire episode on Service Workers, episode 18.

Michael: Nice.

Brian: So that's the actual episode we talked before we hit record, but Zack Argyle actually came on and talked about how Pinterest leveraged Service Workers and they're sort of revamping of Pinterest is a mobile web version to become a progressive web app.

It was a super fascinating talk that if, especially if when he hit early sort of use case of Service Workers, which now is kind of built into like create React app and et cetera, which is pretty cool.

Michael: Yeah, really interesting technology though like when you think about it, Service Workers are like, they're almost like a little server that lives right there inside the browser, right?

And you can just intercept any fetches that are going on and be like, oh, you requested this, but I'm actually going to serve up this other thing instead.

It's really, really interesting technology.

Brian: Yeah, I wanted to talk about the use case for someone who would want to use unpkg and like leverage script tags, because like, in my mind, like I guess my evolution as a JavaScript engineer, npms all ready existed at the time, I think empower npm.

Like they're basically around the same thing, but npm sort of took over the space.

Why would I not use npm?

As far as just like my development cycle, I can speak on like the benefits of using something unpkg the script tag.

Michael: Yeah, so first of all, when you're using them unpkg, you are using npm, right.

Brian: Yeah.

Michael: It's just built on top of it. It's just like, it's like a different way of consuming it, right?

It's like, giving you some different options.

So, I think JavaScript developers early on, like in the early 2010, if you were doing JavaScript development and you know, somebody said, "Hey, share a JavaScript library with me," how would you do it, right?

So if you were using node, the answer was actually pretty clear. I'll just publish an npm library.

You can npm install my thing. And now in your node program require it off you go.

And, and so the node community had figured out, hey, here's how we're going to share code.

And the front end, JavaScript browser community didn't really have anything like that.

We didn't even have a module loader. I mean, we just barely got a module loader.

Right, so when it came to, how do we share code, we didn't really have an answer to that question.

And I remember, I still remember the first time I, you know, npm installed jQuery.

That was a weird thing for me to do that. Because I was like, wait a minute, what's going on here?

Like, usually like jQuery is in the browser but now it's in my node modules folder or what to do in there.

And it was kind of a weird concept to get used to, but Front-end JavaScript developers were just so starved for a way to share code, that I think it became a very natural outlet to say, well, hey, all the node developers are doing it on npm. Like why don't we just use that? And Front-end developers using npm is really something that npm was not designed for.

It's great as like, they've got a couple of the primitives that we need, right.

They've got a registry, they've got a nice CLI tool.

We can npm install, we can npm publish and we can share code.

But when it comes to building a client side, app, npm actually itself leaves a lot to be desired, right?

Because how am I going to get a file from npm into my client site app?

Well, along came the bundlers, right?

So the bundlers came along in Webpack and Parcel and Rollup and everybody, and they said, "hey, "we'll help you to consume all that stuff "so you npm install that stuff "and now we'll take that stuff "that's in your node modules folder, "and we'll bundle it up so that you "can actually put it in a web app."

Browserify was actually the first one on this train, that I ever heard of anyway, that, that figured out, yeah.

People are sharing code that is meant to run in the browser on npm. We need a way to get it to the browser efficiently.

So Browserify came along and kind of pioneered this idea of take this node code and Browserify it, put it in the browser.

So unpkg is another tool in that same kind of vein, except instead of requiring you to do an npm install step to get the code where a slightly different use case right?

Whereas with unpkg, you use script tags, which is actually kind of cool because you can output script tags with your bundler, right?

So like I have a Rollup plugin that I use with unpkg that essentially will take and import statements.

So let's say you say import React from React.

Basically what this plugin will do is it will say, okay, in the output bundle, what we're going to do is we're going to get React from the unpkg CDN, because browsers nowadays have import statements, right?

Browsers have module loaders and they can actually load code from URLs. But they don't know how to load code from just a bare import.

If you just say import from React, the browser doesn't know exactly where to get that.

But if you say import from https://unpkg.com/React well, now it knows, okay, so here's the host name that I need to go and talk to, to actually get this resource.

So unpkg is really just another tool in the, I feel like it's kind of a suite of tools, the bundlers CDNs, like unpkg that kind of help make using npm to develop browser applications a little more palatable, a little more useful.

Brian: Yeah, and I think one of the best use cases I've had was actually through your React training, which you had mentioned previously, and also the reason why you were in the airport building this is that my first step in learning React, actually it wasn't even from your training because I did the advanced training. It was from Kent C. Dodds.

Michael: Oh, okay.

Brian: His training and his first step is add it like, because the assumption is you've learned JavaScript, you can do a variable, you can make a map work.

So now you're going to learn React.

So here's a HTML page, add a script tag with Reacts and here's going to do the base level of making, not even at the time, actually I think they intro is not even dues.

It's used create class. So not even JSX. So now you imported React using unpkg, then you type, React create class.

And then you get to now create your first element, which is Hello World.

And then that's basically sets a stage up for how you can learn how to use React without all the extra cruft of JSX and npm and even the router.

And I think in training and education, it's like huge.

Michael: Absolutely, it can be daunting. Like if you asked me to go in and set up a Webpack bill, that'd be like, oh boy, alright, here we go.

You know, I mean, it's not that those tools aren't, you know, ergonomic or whatever they are, they're great tools, but it's, it's a lot to bite off if you're just getting into web development right?

It's really helpful I think if you can just say, okay, we're going to introduce one new concept here, which is React instead of, and this was a huge hurdle for a lot of people getting into React, which is why I think they made create React app, big hurdle for people was, okay, not only am I using React, which is, a new component model, a new model for managing state, I've got these lifecycle hooks, like there's a significant amount of learning there.

I also have a build that I have to do because I have to take this JSX looking code and translate that into something that the browser can understand.

So now I've got Webpack and all of a sudden, you're like we were creating intro to React courses, back in 2015 when we first started React training.

And a lot of times the conversation would veer from React related stuff, which we really wanted to talk about because that's what we wanted to spend our time talking about because that's what we thought was the most valuable for people to understand this new paradigm.

And we found ourselves talking about Webpack, so like, wait, so we've got this JSFX code, now, how does that get translated into the browser?

Well, you see, we've got to build. Okay, tell me more about the build.

Okay, well let's open up our Webpack config JS and now we can look through and we can see our loaders and this is all now we're talking about Babel and how Babel does its translation and you know what I'm saying?

Brian: Yeah.

Michael: And Babel presets work. And before you know, it you're off on this tangent, you're not even talking about React anymore, right?

So as a learner, you're like, well, hold on, I thought I was going to go in here and learn about React.

And we ended up talking about all this build stuff.

So it's really nice in a situation like that where you can just say, not that you're being hand-wavy about it, but you're just going to say, okay, we're just going to drop a couple of script tags here.

Okay, now let's get on with talking about the React concepts that we want to talk about instead of, taking a huge tangent to talk about how to build stuff from node modules, for the browser, you know?

Brian: Yeah, and the one thing that came up around that time, I guess when unpkg came out was the term JavaScript fatigue.

Michael: Yes.

Brian: Which is ironic where you come from a world back in 2008 where you're like, I don't think JavaScript that big. And at this point at 2015, JavaScript was huge,

Michael: Yeah.

Brian: But things like Webpack and Browserify and like all these other tools and even the build commands, it added to the craft of like trying to learn how to do JavaScript, like my intro to JavaScript professionally, because they did a lot of tinkering with like things like Ember and jQuery.

But when I started doing it full time was angular.

And just trying to understand what was happening in angular one day, I was just kind of like, I don't know, I'm just going to copy and paste from here, if it works in this page, I won't move too much stuff around and it'll work hopefully.

And that was like my deal of how I would do JavaScript.

Michael: A hundred percent, I mean, I still copy and paste code, like that's how people learn.

That's how people get used to it, right? So if both of our starting points is an HTML file, then that works, right?

But if you have one build configuration, I have one build configuration that ability to like copy and paste or just drop a script tag in, it doesn't quite work the same anymore.

Right, now you have to know, maybe I need a special loader for that library or, or something, right?

So yeah, it can definitely reduce friction, both in learning and also in sharing or, copying and pasting some code, just making it easier for people to get up and running and to use it.

Brian: So I wanted to save some time for what is a, what are you working on with unpkg?

What's like next up from unpkg? Because I think that use case is awesome.

Actually, I was going to save my pick actually. So I mentioned my pick of my use case with unpkg when we get there.

But I'm curious, so what do you have for plans in the future?

Michael: Oh man, I'm glad you asked. So there is actually a lot of pretty exciting stuff coming up.

So back in 2017, I gave a talk at React Rally where I demoed this flag, this module query parameter for unpkg, that basically lets you load ES modules in the browser and ES modules have come a long way since then.

We actually have like good module. I actually had to demo it and like a preview version of Firefox, but ES modules are full time in the browser now and more and more authors are publishing ES modules to npm.

And so I'm actually working on a release right now, which should be released by the time this podcast goes live.

unpkg is going to be to convert any library to ES modules, any library on npm.

So anything that you need to load, even if they just publish common JS.

The one that I think about most of the time is React itself.

Although there are some forks of the React package that publish ESM React itself only publishes common JS and a UMD global builds.

So this will actually let you load React itself right there in a script type equals module tag, which would be great.

So again, any library that's on npm, the module query parameter is going to work for all of them.

I'm also introducing a new bundling feature on to unpkg.

So I'm actually putting the bundler in the server itself, putting the bundler in the CDN.

So traditionally if you're loading ES modules without any kind of a build step, you usually have a pretty big waterfall that goes on, right?

So you'll load module A and module, once the browser gets in parses module A it realizes, okay, you actually need modules B and C and then they have dependencies and so this waterfall kind of plays out.

And so I'm actually introducing a bundler into the CDN itself to optimize that process for you.

So we can preload modules before they're actually. So we can like hoist transitive dependencies, basically all those modules in the module graph, we can hoist them into the entry point.

We can also take an entire library, for example, something like three JS or D three or, or React or any library view that you might be using and bundle that whole thing up into a, into a single file. So you can load it in a single request on the CDN.

So we're working on that as well.

Another really cool feature that I'm working on and then I'm hoping will actually get people pretty excited and should be really interesting actually to this crowd that love developing the JAMstack is so unpkg currently has the ability to serve an HTML file.

So if you can publish an HTML file in your npm package and we will serve that from unpkg.com.

But it doesn't have a lot of the nicer features of, a good HTML server like Netlify or Surge.sh.

They'll do things like rewrites and redirects for you.

So you can serve like a single page application, using something like React Router from a server like that.

So I'm actually, adding support for that to unpkg.com.

So if you wanted to, you could take your Webpack build output, publish a new npm package and serve an entire website, with support for rewrites and redirects loading modules, the entire thing, loading it on a global CDN with over 200 data centers all around the world.

And so I think that'll actually be pretty interesting for people who are interested in, especially people who are like using the static site generators, you know, whether it's Next or Gatsby, maybe you're currently using Netlify, you'd actually be able to go ahead and use unpkg for a similar reason.

Like if you publish to Netlify and they'll give you like a hash right? For that, just that publish. Right, that build.

Brian: Yeah.

Michael: And so you have these like static URLs that will never change.

Brian: They call him a atomic deploys is what they call them in there.

Michael: That's right, atomic deploys.

Right, so you'll push. And I think the atomic deploys are probably based on like a get hash or whatever of the repo at that state.

Well, if you think about it, your npm versions are actually a suitable identifier for an atomic deploy because you can't overwrite them.

You can't delete them or unpublish them. So once you publish a package, that's it, it's immutable.

And so you can actually use the npm version number to do atomic deploys on unpkg.

You want to publish a new version of your site, just publish a new version.

And then we'll also have the ability to alias, to add an alias, so you'll say, okay, I'm publishing the current version of Brian's blog.

The current version is, version one.five.three, and then, you can publish one.six, go and check it out, make sure everything looks okay.

And if it does, go ahead and update the alias so that you're pointing to, the one.six version now.

So it's using this idea of atomic deploys, but also using it with, just using with NPN version numbers.

And the reason I think that's so cool is because it ties into an existing workflow that you're already used to.

Right, you're already npm publishing. And so, you don't really have to install any new like infrastructure or learn a whole lot of new stuff.

You can just, it's kind of the reason why I think unpkg caught on in the first place is because people are already publishing npm.

They're already have that integrated into their workflow.

So now you can publish sites and do atomic deploys and rewrites and redirects and all sorts of cool stuff on a global CDN.

So I'm hoping that'll catch on. I'm hoping people enjoy that, we'll see.

Brian: Yeah, I actually, it was really intriguing because one thing that I've gotten the habit of, so I hosted one of my sites on notify and because I get a different version for every branch and every PR I actually put a link of that into my release notes.

So ever for whatever reason, if I need to go back and be like, Oh, something broke, you know, three versions ago, I can always go back to the release notes and be like, okay, well, this one worked what changed between there?

And I always have like a state that's linkable somewhere, but I could see myself using unpkg to have a build command, or even like a get of action to basically deploy and make sure that that build is pointed to unpkg.

And then that way for ever an eternity, anybody who finds my package somewhere like in use, and they want to see like an older version and see how it looked and worked.

In that sandbox, I can point it directly to unpkg this use unpkg to import it.

But also if you want to see a version of that live three versions ago, there you go.

Michael: Yeah, absolutely.

Brian: because I think the other thing is like, I started putting in my release notes cause I wanted it to be discoverable, but like once I deploy any version to production on Netlify, no one really can find the older versions unless I make it discoverable.

So I think that would be a cool place to have that discoverability.

Michael: Yeah.

Brian: So I'd be curious to see how that sort of unfolds and how it fits in the future of the product.

Michael: Yeah, absolutely, it'd be perfect for something in my opinion.

It's great for, any of those use cases that you have for atomic deploys, you know, deploying static sites.

I think it'd be really, really great for that.

I just think it needs a couple of features that I'm planning on adding really soon here so pretty excited to see how, how that all shakes out.

Another really cool piece of text that I've been using to build out some of the more recent things that I've been working on is with unpkgs Cloudflare Workers.

So I should definitely spend some time talking about Cloudflare because they have been amazing to work with.

They're the main sponsor behind unpkg and I've been using Cloudflare Workers to do some really cool stuff.

So for example, like we currently have a 99.7% cache hit rate on unpkg.com.

Brian: Wow, it's amazing.

Michael: Yeah, it's crazy.

Like almost all of the content that comes from unpkg.com comes straight from a data center that is very, very close to you geographically speaking.

So one of the ways that we've actually been able to achieve that level of caching is through really aggressive cache control headers, obviously there's nothing gets unpublished from unpkg ever so we can be pretty aggressive with the cash control max age, but then we can also achieve even greater levels of caching with Cloudflare Workers.

So Cloudflare Workers have this really cool key value store that lets you store, all sorts of interesting pieces of metadata and things.

So lots of times we can do the resolution, of your request right there in a worker and avoid some of the redirects that were previously doing.

So really, really cool technology.

That's like, it's not quite a replacement for like, full blown node server, if you're using like Lambda or Azure functions or whatever, Google Cloud functions, not quite there yet, but you can do a lot of really cool stuff with Cloudflare Workers.

And so they're, really cool tool to sort of augment the capabilities of your site.

Brian: Yeah and I'm glad you mentioned them too, because once again, we had them on the podcast episode 31 Kenton Varda,

Michael: Okay.

Brian: He's the one that actually created Cloudflare Workers and sort of like kicked off that and that project. Super powerful feature, highly recommend people use that.

Michael: The product itself, I think really is interesting. It's we were talking about Service Workers a little bit earlier.

They basically, and you've probably all your listeners probably know this if they heard that episode, that they built out like a service worker environment.

I mean, they just use the service worker API. For the CloudFlare Workers, which is beautiful, right?

We were talking earlier about how I just I'm kind of an engineering geek.

So like when I see something that like, I feel as like a great decision or a great sort of simple way to do things, I mean they could have invented their own API and said, in order to get a request, it looks like this.

And an order to build a server, it looks like this, but they're just like, you know what?

We've already got a really good, most of these things that people are building in Cloudflare Workers are going to be these little reverse proxies anyway, get a request to figure out what needs to happen.

Maybe make a fetch, maybe consult a cache, something like that, right? Service worker API has all of that stuff. So let's create that.

And we'll let people, instead of running Service Workers in browsers, they're now running these Service Workers in these data centers that are like all over the world.

It's actually really cool. It's I've been having a blast with it.

So I would highly recommend you check that out if you, if you haven't yet.

Brian: Excellent, so yeah. Thanks so much for chatting about unpkg. I think this was super impactful and like, I think the, I was trying to think of a pun, but I kind of flopped that one, but yeah, it was cool to unpack it, It was just a, this conversation. And maybe that I'll stick with that.

Michael: Yeah nice.

Brian: Yeah, with that I wanted to transition us to picks.

So I encourage everybody to go to unpkg.com, check out the landing page.

And this gives some information on how to use the product and stuff like that.

But jam picks, jam picks are things that we're jamming on could be foovie, food, music, movie related.

I said foovie and I said that was food and movie together.

So if you eat while watching movies, which, who doesn't at this point.

Michael: It's pretty much required if I'm sitting there at a movie and I'm not eating something, I'm just like miserable.

Brian: Yeah.

Michael: I'm hating it.

Brian: Exactly, my son is addicted to popcorn.

So it's pretty much a requirement if we watch any long feature films.

And I was just going to mention that popcorn's not my pick.

So my first pick is JAMstack Conf for those who are interested, JAMstack Conf just came off a virtual version.

I think it was supposed to be in London roughly like three months ago.

And they do their regular San Francisco version in the fall. And which will also be remote too as well.

So thanks for all pandemics for making everything remote. But the cool thing about that it'll be accessible to all.

So you don't have to come to San Francisco for it.

I don't know if there's a ticket price, but you should probably check out the website and see that the ticket price.

It should be pretty affordable if not free.

And so definitely check that out because I think everybody who's in the JAMstack will get pretty good insight just from the community.

My second pick, it's what I wanted to talk about unpkg with, which is my BeyBot.

So I have a Twitch Bot because I do some live streaming and this Twitch Bot is called BeyBot because it presents gifts of Beyonce.

And the way I built this and a lot of people don't realize these chat integrations and bots are browser sources.

So you're just shipping a basically HTML page to the Twitch chat.

And then it actually presents itself on the screen as a browser.

So as long as you sort of take away the background, it actually overlays over your face and you can do animation stuff.

Michael: Wow.

Brian: There's a lot of creative people on Twitch who have done a lot of cool things.

There's companies built around this, but I wanted to bring this up because this is my use case for things like unpkg, because when you're starting to use things like OBS and you're powering from your Mac laptop with almost zero course left, streaming to worldwide audiences, you have to make sure that the way you're importing stuff is not coming from an npm server.

And it actually has to come from a CDN, or it has to be local.

So I even have to download all my JavaScript files, put them in a folder and then I can present Beyonce for the crowd.

Or I can just add a script tag, which is got me back into like really loving all the JavaScript I missed, which is have a JavaScript file, have an HTML file, have some CSS and a style tag and then I move on.

And that's how the BeyBot lives. So if you want to, the repo will be linked to the show notes, but it's open source/beybot.

That's the BeyBot and you'll see, there's a Dev. to post to while linked, where I just sort of walk through how I built this with just HTML, CSS and JavaScript.

And it's beautiful. And it makes me want to go back to the past when things were so much simpler where I can just add some JavaScript where I want to.

Michael: Yeah, that's really cool actually, there's something that like I just love about that too. Just the simplicity of it. It's not having to build, it's really nice.

Brian: Yeah.

Michael: So you're pretty into Beyonce, huh?

Brian: I am a Bay fanatic, and I think you all should, maybe that should be a pick but "Black is King" came out on Disney Plus.

Michael: Yeah.

Brian: Definitely watched that and everything else she's done.

Michael: I saw that, I've been listening to that soundtrack. Do you want to do your last pick?

Brian: Oh, my last pick is basically Fiverr, which is not much of a pick, but the way I've approached using Fiverr is I've had some needs from some animations and some like light graphic design work.

And the way I've been doing this is to make it super cheap for myself.

I find the tutorial on YouTube. I was like, what I would do, if I wanted to spend six hours learning how to do it.

And I just give that to the Fiverr person. And then they return it back in like less than a day.

So it's been an amazing sort of Fiverr hack, highly recommend just go find a tutorial that you don't want to learn, hand it to the Fiverr person who already knows how to do it.

And there's like, oh, I can do this.

Michael: Oh man, I should do that, like with Kubernetes, I'll be like, hey, could you help me get this? because I've tried like at least 10 different tutorials and I just can't get it.

Brian: Whereas, I wonder if anybody's on their teaching rust. That's one thing I want.

Michael: That would be amazing. Just be like, I know what I want. I just don't know how to do it. If I give you this book.

Brian: Yeah, yeah, yeah.

Michael: Like, look at chapter six and then build this for me.

Brian: That would be amazing, oh man.

It really is like, that's one of the most powerful things I know, is to get help from the person when you need it.

Michael: Yeah.

Brian: It is so hard to put a price on that, right? And if somebody could like really figure out how to, somehow make that easier.

Like I think probably the best thing I know for that right now is YouTube.

Michael: Yeah.

Brian: Like my children are, they're learning card, magic tricks.

My boys are practicing card magic tricks. One of my children the other day used a YouTube video to figure out, to help him solve the Rubik's Cube.

One of my girls is using YouTube to learn how to do Rainbow Loom and how to do crocheting and knitting, which I just learned this week or actually two different things.

One of my other children, my five-year-old uses YouTube.

There's a channel, what's it called? Something like Drawing With Kids or Art With Kids or something.

Michael: I think my son also watches something very similar.

Brian: It is an amazing channel.

Michael: It is a man and his daughter usually.

Brian: Yes, yeah, we watch this one.

And they sit together and they draw and he's like, "okay, we're going to draw the eyes."

And then she draws the eyes. "Okay, now we're going to draw the nose." And then she draws the nose.

And my five-year-old I walked in on her. I'm like, what are you doing?

She's like, "Oh, you know, I'm just drawing this haunted house "with these bats and these ghosts."

And like all this detailed scene and she's five and I'm like, YouTube is amazing.

Michael: It really is.

Brian: Maybe that'll be my number one pick. I'm sure you've all heard of it.

But it never ceases to blow my mind. Kid need public school, when you got YouTube.

Michael: YouTube is amazing. Okay, my picks are, well, I got to talk about TypeScript. I know it's kind of a divisive topic.

Brian: Oh, very much so.

Michael: Oh my gosh. It's so I feel like sometimes like I'm just barely learning JavaScript and then all of a sudden this thing comes along TypeScript and I have to figure this out as well.

So I've been doing TypeScript for about, probably about like five months now.

And I really feel like I'm starting to click with it.

Finally, it's been a hike for me to get here.

Most of my problems with TypeScript stemmed from the fact that I also was trying to learn VS Code at the exact same time, because I heard that, oh, that's, if you're using TypeScript, then you also want to be using VS Codes.

So not only was I, it's kind of like our previous conversation, right, about learning React.

And you also have to learn Webpack at the same time. I was trying to learn TypeScript.

And I was like, oh, I got to learn VS Code at the same time.

So it was kind of a hurdle for me, but anyway, I got it figured out, I got some kind of good stuff installed.

I'm actually using VIM these days. So this'll be like my, the second half of my first pick is coc.nvim.

It is a VIM plugin that gives you IntelliSense in VIM using the exact same language server that VS Code uses.

And there is all sorts of really cool stuff.

So, IntelliSense, but it also, browsing in line documentation and auto-complete all that great stuff right there in your editor, in VIM.

So it's really, really cool. Definitely check out coc.nvim, if you're a VIM user.

And it has helped me to make peace with TypeScript.

So I am actually kind of geeking out over TypeScript now because like in this I guess for me is just kind of like a plea to people who are struggling with it, to like, just give it a bit of time, give yourself some love and some time and be patient with yourself and you'll figure it out, because there is some great stuff there and it's going to help you write some good code.

So just, tough it out, you'll get there. We all have the learning curve.

We all struggle with the learning curve.

I feel like, this learning curve for me having been in the industry now for like, I guess over 10 years, I don't know.

I guess as I get older, I'm like, I should already know how to write code.

Well, here I am back like learning the basics of this new language.

And so it kind of slows me down for awhile, which is a little bit frustrating.

And I think that might be a lot of people's frustration with it is like it's slowing them down a little bit, but once you get, like, once you really get into the sweet spot and it's like, giving you, I mean, there are still some words on it, no doubt.

But once you get into the sweet spot and it's really giving you like really helpful messages where you might have, you'll probably find yourself writing code that you're like, wow, I didn't even realize that was broken before.

And like, it's actually quite good now. So really nice stuff.

So my last pick will probably be Remix. So Remix is this new project that I'm working on with my longtime business partner, Ryan Florence, and we are super stoked about this.

And I'm pretty sure the JAMstack crowd is going to love this.

I don't really mean to be disrespectful at all about any of the other frameworks that are out there, but Ryan and I have not, we've kind of been sitting here for awhile now, like looking around, serving the ecosystem, we built React Router five years ago, then maintaining that project ever since, it's been going well, but I'm looking around and I'm surveying the ecosystem.

And I do not see a project that really speaks to the way that I want to write websites and the capabilities that I think React presents, especially when we're talking about, the future of React, some of the things that are, that they've been working on now for the past couple of years, suspense, I just, I look out there and I just don't see it.

So we earlier this year, our training business kind of stalled a little bit, by the way, the training business is still going strong.

So if you want React training, give us a call at Reacttraining.com, shoot us an email.

We'll be happy to help you out there, but we figured, wow, that's kind of in a little bit of a low, we're going to work on this thing that we have wanted to see for years now.

And it's a straight up framework from, everything that you might expect.

I think it's in a lot of ways, it's like, it's just a lot of like old kind of tried and true ideas, just applied to this great modern web development stack that we have.

And so, it's using React. I wrote our own custom development server using Rollup.

We use it Rollup a lot in there, which is really cool. So the bundling is all using Rollup.

You could watch a couple of the videos if you visit remix.run, we've got a couple of posts up there that are kind of showing people kind of where our heads are at what we're thinking about, but, the ideas of being able to build a hybrid site that is completely server rendered, but also lets you do client side navigation and transitions.

It's actually kind of tricky to do. It's kind of like a Holy Grail, so to speak of web development, right?

Brian: Yeah.

Michael: You want the server vendor page so you can cash it.

So you can for SEO, all of that kind of stuff. And traditionally that means that you kind of go that all that way or you decide for some reason, none of that's important.

And so you have a completely client rendered app, but it's hard to have a really nice hybrid that just loads the pieces of the app that actually need to be loaded.

So that's what we're working on. If you're interested in a new framework, that's really based on just a lot of really old proven technologies, go ahead and check out remix.run.

We are hoping to be launching that before the holidays hit.

So we're going to be cranking on that this next month, September and October.

Brian: Excellent, yeah, looking forward to it.

And I feel like the React ecosystem has evolved so much now that we've got all these flavors and frameworks.

The irony of a React constantly are the community saying React is a library.

Now what everybody's wanted is the opinions. And having the opinions to be able to get something up and running really quickly.

And I think that's what, that's my goal right now, is this, can I ship something really quickly?

And I think the test of that is things like tailwinds.

Like I think now I don't have to think about CSS anymore. Like never again.

Michael: Yes, please let me stop thinking about that. Yeah, exactly.

Brian: Yeah, so if I can stop thinking about like, structure of React code and how to handle server rendering and routing and how to set it up, maybe your command, if it's not remix run is not the command that'd be a missed opportunity.

Michael: Oh a hundred percent, hundred percent.

You know it, hat's exactly what it is. Yeah, absolutely. That would be huge missed opportunity.

Brian: Yeah, yeah, for sure. If I can just Remix run and have a project up and running and then swap some images out and get some data in there and then walk away.

Michael: Yeah, so it's going to be completely based on React Router, V6, which is totally open source project.

Brian: Okay.

Michael: Yeah, one of the coolest ideas I think behind it is we're matching routes with data loaders, right? Server-side data loader.

So let's say, you're building out your page, you're building out your site.

Oh, you know, I realized I actually need some data here. You go, pop open a new file.

And this file is actually going to run on your server somewhere.

So let's see you can put, secrets there, you can put database credentials there.

If you need to go talk to a database, if you need to go and talk to some, third party API or whatever, put your API tokens there, create your loader that runs on the server and then create your file.

That is your component, right? Your React component. That is your Route component that actually needs that data.

Now, your job is done now, because you've linked up the file to its data source.

So now when somebody requests that page, if they land on that page, that file is actually going to be rendered on the server.

And that data is going to be fetched on the server.

And so it's going to be in the page right there ahead of time, or if they're browsing around the site and they navigate to that page, using like a React Router link, like a client side link, then we're going to fetch that data from the server dynamically, at runtime.

So it's almost like you're building out your app declaratively, like you're saying here's a component, here's a route, here's some data that, that route needs.

I don't have to decide as the developer how to stitch them together anymore and how to get that like to the client in the most efficient way possible.

I can just sort of declare these things and then it's going to sort of be stitched together in the most efficient way, depending on where the user landed and how they got to that page.

So then that's just one sort of thing that we're doing for you, but stuff like that, that I'm really excited about that I just don't ever want to have to think about that kind of stuff again, like I just, I know how I want it to be done and I just want it to be done like that.

And once I'll build Remix, then I'll just build everything with that. And then I don't have to think about it.

Brian: Excellent. Yeah, well I'm looking forward to learning more about that, again, it was great to unpackage this and learn about unpkg.

Michael: Yeah man.

Brian: Which I think that landed this time.

Michael: Totally. Yeah, thank you so much for having me on the show.

Brian: Awesome, we appreciate it. And listeners keep spreading the jam.