Supper Club × WASM, Fastly Edge, and Polyfill.io with Jake Champion

Welcome to Cintax. Today, we've got an awesome show for you today. We have Jake Champion on Who works at Fastly, which is a I'm not gonna say new, but it is a edge compute platform.

We'll talk about what that is in just a second. As well as, he is the author maintainer, we'll we'll let him explain it, behind polyfill. Io.

Excited to have him on to talk about both of those things as well as I think there's there's quite a bit of overlap, between the 2. Hey, Jake. Thanks so much for coming on.

Thank you for having me on. This is gonna be fun.

Yeah. Oh, definitely. It was, so Jake and I had a little call, just before about about a month ago, just to talk about what was going on, it kind of all of this Happened when I was working on a talk about alternative JavaScript runtimes, which is we have Node and then we have Deno.

And then some people know that Cloudflare Workers is its own thing. And then I like, once I started pulling that thread, I realized that, like, wow, there's actually Lots of different run times out there, and I didn't even know about this one, which turns out It's a very popular huge one out there. It's called Fastly.

I had seen the logo pop up a few times but never looked into it properly. And then As I was going back and forth with I think it was Jake on Twitter about, like, how it works, and it's it runs on Spidermonkey and all this kind of cool stuff. I was like, this is we gotta do a show on that. This is so cool. So, you wanna give us a quick rundown of of who you are, what you do, whatnot before we get into it? Yeah. Okay.

I'm Jake Champion.

I work for Fastly as a staff software engineer mainly on the computer edge JavaScript SDK and accompanying runtime, but I work on I also help out on the other SDKs and any sort of computer edge related aspects of the platform.

I also help maintain The polyfill. Io open source, free to use CDN that serves polyfills to browsers, but in a Performant way. So you can, like you make a request saying, I need to fetch polyfill, and then we go, wow. You've just you're the latest is Chrome. You don't need to fetch polyfill, so we send you back nothing.

Or your IE 10, and then we say, oh, you need fetch, but you also need promise and you need all these other ones that fetch users internally, so we send you all of those. So then Developers don't need to think about it. They just say, my website uses these features. I put the script tag into polyford io. I know The browser that I support will now have those features.

And that's running on Fastly's computer edge network and also sponsored by Fastly so I don't Have to pay for the infrastructure costs. I know. Firstly firstly have a Fast Forward program that sponsors projects, across the whole, like, tech ecosystem.

And Polyphoto is one of those. That's really cool because I was I was, like, wondering. Sometimes I see these websites Like, poly fillet o and unpackage and all that. And I was like, that has got to cost a pretty penny to host this thing. Like you I think you'd, like, rattled off some traffic numbers that you're getting in my mouth.

What were those?

So, Polly said, I get Just over a 1,000,000,000 requests today,

which is a a good amount of requests. No kidding. No kidding. That It's unreal. And, like, not even just requests, but you're you're literally serving up JavaScript, for all of them. And I guess it depends. Like, it could be as As little as probably nothing. Right? And as as large as quite a bit for older browsers?

Yeah. The largest one is, like, More than 25 megabytes if you're requesting, like, all of the internationalization APIs and your browser doesn't doesn't have those at all. Have to serve all of those, languages and datasets as well.

And it can get quite big. How long has polyfil,

dot io been been around? Oh,

so it's been,

more than a decade, I think now. Yeah. I remember when this was first announced because it seemed kind of like, there there was a a time when there would be things dropped like this that were always seen as, like, kind of joke projects. So like, Oh, here's a service that fixes all your CSS. Just drop in drop in the script. But I remember seeing polyfill dot I o being announced And my boss's reaction was, that is an April fools joke or it's too good to be true because it just does all that for you. Right? So I remember when this first came out. So it's it's amazing that y'all have been hitting probably a substantial amount of traffic Like this for so long now. Yeah. And from the beginning, it was,

sponsored for by Fastly as well. It was originally a project that Oh, so Fastly's been around. Yeah. Fastly's been around for 12 years now.

But their computer edge network, their platform is newer than the CDN offering that they have as well. Do you know Jonathan Neal? He's quite a prolific overseas.

Yeah. So they originally built polyfill.

Io, and then it got Handed over to, Andrew Betts, who you may know. And they're the person that turned it into a, like, CDN and got the sponsorship from Fastly.

And then I took it from Andrew when he left Financial Times to join Fastly, and then I left Central times and joined Fastly.

But I took Polycom. Io with me.

So let's talk about Fastly. Can you explain what it is, and specifically, the Fastly ComputeEdge, because that's kinda what we're interested in here. Yeah. So the Fastly computer edge,

platform is a platform that runs web assembly applications, on Fastly's edge, and Fastly's Edge is 99 pops around the world. So we've, so any application that can compile to WebAssembly and specifically WebAssembly, system interface, the WASI, subset.

It can run on Fastly's platform.

Fastly provide SDKs for certain like, official SDKs for some languages like Rust, Go, and JavaScript, And we can run those on our platform, but any other language can that can support WASI and WebAssembly can run there as well. So there's community SDKs for, like, Swift and Zig, and there was one

for Ruby and another one for Haskell. And so they they could just if This web if it's WebAssembly, it can run on Fastly's computer edge platform. That's what kinda blew my mind with all of this because you think, oh, it's another JavaScript At runtime, they probably slap Node. Js on the box. And then when somebody hits a URL, they spin up Node. Js instance. And it's not that at all. So they have, like, A the way that it was explained to me, and I'll let you explain a little bit more, is that they take your application And they take SpiderMonkey, which is the the JavaScript engine inside of, Firefox, And they compile both of those to WASM, and then they run it, as assembly code. And that's why it is It's so fast. And it it kinda just like I couldn't guess through my head. I was like, but isn't the browser where you run WebAssembly? Like, how can you compile the thing that runs WebAssembly to WebAssembly itself?

And I think that's where Wazee comes in. Right? So we have a WebAssembly runtime called WASM time, and that you can deploy to servers or wherever you like or run it on your machine or I can embed it in a browser. So the the WASM time is the runtime that we use that run executes all of the WebAssembly applications.

For the JavaScript SDK, We do there was work done by my team before I joined, to make SpiderMonkey able to be compiled to WebAssembly.

And so the JavaScript SDK for Fastly is SpiderMonkey compiled to WebAssembly and then runs your JavaScript code inside of this SpiderMonkey WebAssembly runtime.

So we don't compile your JavaScript to WebAssembly. We take your JavaScript as As it as it is, you it's sourced. You just run that within the SpiderMonkey that we've compiled to WebAssembly, and we add our own extra, APIs into the, JavaScript runtime because SpiderMonkey on its own is just like ECMA 262, and So it doesn't have, like, fetch request response streams.

You need the whole the web? So we yeah. You need those ourselves, yeah, and add those to it. Yes. Because we're trying to The winter CG, compliant as well.

And why Why do that instead of just running Node. Js on a server? What's the benefit of doing all those Jumping through hoops and and creating an entirely new runtime server runtime.

WebAssembly is, there's lots of talks, by our CTO on this, actually. So we could we could point to those. But, basically, WebAssembly is like a really secure sandbox, that you can run your code in, And so you get good security guarantees, if you can compile your code to a WebAssembly. So if you're a platform where you're running Customer's code, which is untrusted code, it's really useful if your platform is, like, inherently secure based on the just from the language that it supports because WebAssembly itself is a very minimal and secure secure language. It simplifies the security, that we have to put into place for running your code.

It's you can also make it be really fast to spin up WebAssembly applications as well. So, it takes us 50 microseconds to spin up a customer's WebAssembly application.

There's no, like, cold boot or, like, cold start or hot start or warming up. None of this. It's just always It's always the same, and we don't reuse, instances either, which is something that you'll see on, like, The other platforms are like Lambda. Like, you see that your instance sticks around, and you can, like, restate across it. That's not something that We have yet. Who knows if we offer it in the future? But, the reason, like, that's that was a thing the other ones did because it it takes them a while to boot up, whereas it takes us 5th as I said, 50 microseconds, so this is pretty much instant.

By using WebAssembly, it also means that we support any languages that can compile to WebAssembly. Whereas if we were using, like, VA or Node. Js, then JavaScript is the language, and then you, they have like a WebAssembly API, but you're still having to spin up A whole JavaScript run time to then run your WebAssembly in. So it's like a bit it's a lot more work to be to be doing.

Whereas Mhmm. If we just put WebAssembly on its own. You can write your application in Rust or c plus plus or c or Zig or Anything else that can harm parter to WebAssembly.

What type of stuff are people running on this? Because we get this question a lot where we talk about edge, we talk about serverless, we talk about distributing your, your actual compute tasks To as close to the user as possible.

And then we often hear from people being like, I'm just running, like, 1 render server in Ohio And everything is fine for me. So, like Mhmm. Like, who are the customers of Fastly where they need this type of speed and or what are the types of things that is is good for this?

So I can talk about what I use it for, and then I can also talk about what's, like, general good use cases.

So, like, as I mentioned, Polyfil is completely on computer edge. There's no back ends to it. There's no, like, infrastructure that I maintain or have to scale up or scale down. So you can run, like, a big application like Polyfil. Io where it's doing lots of computation and, like, dynamic JavaScript generation at the edge And do all of that in in computer ash, that you can also have like, what we what I see being it being used for is, authentication at the edge, personalization at the edge, or serving if you have, like, static content, You could have that within the the computer edge platform and just serve it from all of our our pops, never have to go to your your origin.

And there's quite a few exam we have, like, the developer portal, which lists Slows of different use cases and examples as well. So you're like this, like, blocking bad traffic or, doing Automatic failover. If you have, like, multiple origins around the world or just like in different data centers, You can write a computer edge application that redirects your traffic, but if one of your origins is unhealthy or,

Stopped responding. What one other thing I think is is kinda neat with Edge is a lot of IoT stuff that must go to the cloud is really helped by using edge functions because if you think about turning a light on and off or or doing something simple like that, the there At 200 milliseconds, latency is unacceptable when turning a light on because you are used to literally the speed of light when you're turning a, a light switch on, like, it's literally just flipping electrons from one to another. And now, with IoT stuff, it has to, like, Go and check what the status is. Are you allowed to do this type of thing? There's all this, like, compute that needs to happen before the relay can even Switch from on to off, and often that compute needs to happen unless you have some sort of elaborate local setup. A lot of that just happens in the cloud. Right? And especially, like, you get into a lot of these, like, Amazon based,

Tuya devices. A lot of them have to go all the way to China And come back before they they can do that type of thing. Right? And it could be slow. Did you see there was a Twitter thread just the other day that was, like, I traced where this message from my Tuya bulb went all over the world, and it was like a nightmare. It was Very depressing. Yeah. Yeah. So,

I I think a lot of those tweets are people are scared of China.

Oh, yeah. But this was this was like this was like, here's all of the stops it's making. Yeah. Exactly. And when in reality, it should Try to just go from your phone to your bulb, right, like, if it can.

So I think that's that's a kind of a interesting use case for These ComputeEdge I didn't even think about the the Polyfill IO as well. Right? Because you need to be able to figure out What pieces of JavaScript to serve to your user as quickly as possible,

and that's a great use case for it. Yeah. We there's lots of IoT that runs on on Fastly's CDN as well.

So what you've mentioned is, like, exactly true.

But, yeah, Polycom is like it does the what's now frowned upon user agent sniffing To figure out what browser you are then.

Oh, yeah. Mhmm. Yeah. Username.

Them to, like yeah. Your your crime 110 or something. And so you have these features. Yeah. You mentioned a while ago being winter CG compliant. Do Client, do you want to give the audience a rundown of both what winter CG is and what it takes to be winter CG compliant at a high level?

Yeah. It's it's the web interoperability, runtime community group. It aims to create it's a long name.

One of the proposals is called the minimum common runtime API, and that's trying to Define a common subset of API functionality across different JavaScript runtimes, such as Deno, Vercel, Kyle Flow workers, Alibaba, Lacon, and Fastly Computer Edge, and some others that I probably can't remember.

And it's so that the intention is to make it simpler for engineers to write JavaScript that will work across the different runtimes.

So, like, they would all have a console implementation so that you can do console dot log, and it works when you wherever you deploy it or, using request or response constructors.

Those, part of the minimum run time proposal as well.

Yeah. It's basically to try and make it so that you can run your code

on any of these run times, and it should work with this Common substance. Nice. I'll I'll link that up in the show notes, the proposal that people can check it out. I'm curious about what you think

About, node APIs making their way into a lot of these platforms. Because, like, on one hand, we are trying to build as much as we can On these standard APIs. Like, anytime I build I always give this example. Anytime I build a server, I don't reach for express anymore. I reach for Hano JS, which is built on The request response fetch API, it's beautiful because it works literally everywhere, and it doesn't matter where you're gonna deploy. And anytime they reach for a package, I try to figure out, is it Worker ready is is what I call it. Right? Like, will it run-in on all these different platforms? And then on the flip side, sometimes you're like, I just want Node APIs. Like, maybe the standard is is Node APIs. What what are your thoughts on Node APIs starting to Eek their way into their endino. Cloudflare Workers are starting to put a bunch of them in there.

So there's a subset of them that I think Might make sense, to to have in these runtimes. And then there's there's the other ones where it makes less sense. So, like, the file system, you know, the APIs.

If you don't have a file assistant, then it's maybe not 1 you you want to be implementing.

Like, we don't provide a file system. So, but, like, path is one that I see lots of people wanting to use, you know, not just in, like, server or edge Run times, but also, like, in the in the browser, that they just want to be able to, like, join things together and pretend it's a path and normalize it.

And so I do think some of them make Like, the functionality that they that they are offering makes sense. Yeah. But perhaps it's a good time to try and put that into I create a new version of it that's within the, like, ECMA 262 or in the web, that I care, what w g And, like, we've had many years of using the node ones. Maybe we maybe we've figured out some issues with them and could offer a a nicer to use API.

I think Yeah. We saw that with we saw that with the, Sync local storage API that node has is now we're getting a sync context.

We saw that with streams.

So they we now have a standard web Stream. And so far that node has implemented it, and then they have a bunch of things. So, like, I think that is the way forward is that, okay, we see these things. It also gives us a chance to fix things we don't like about the node APIs and create a much standard one. And and web streams is amazing because now I can use a web stream in the browser And send it from the server, and I can literally just cancel it because they're standard APIs, and you just call it cancel method, and it's It's so beautiful. Yeah. The same thing happened with the crypto as well. So Node. Js implements the web crypto API. So if you want to use

Cryptography functions in the browser, the edge, or within Node or Deno. It's the same web crypto API that's within all of them as well, which is so so good.

And Node. Js has, like, tried to do even more crypto stuff. And I I've seen, One of the core committees has, like, made a proposal to to the web web crypto, specification to try and add even more functionality into it, which that's perfect because then if it does land, it will be in browsers and everyone else for everyone to use. Can you explain what WASI is and how that relates to WASM? WebAssembly is a, like, Small self contained assembly like language, which doesn't give you much Functionality gives you, like, logic, and memory.

It doesn't give you IO or any other kind of, like, system like interfaces.

And WASI is a way of introducing, like, IO or any host functionality of, like, getting the time Or opening a file or creating a socket, these types of, like, System in inter interfaces is what is what WASI is is making available to WebAssembly, run times.

So, like, WebAssembly on its own, if you've only got, like, reading it for, like, a web browser, it's like you Pass out their data. It can do some computation on it and give you back the bit of data, but it can't do, like, network requests or or anything like that. And Wazee lets you be able to do that extra part. So is is Wazee something that could, like I could run that on my computer locally? Like if I had a like a WASM application,

it doesn't necessarily have to run-in the browser.

I can run I could run it on anything that is Has a Wazee runtime?

Yes. Exactly that. And so, like, for example, Fastly's computer edge platform, you know, that's on our infrastructure, but we also offer, like a local sort of implementation of it as well, which uses the same, WASM time runtime.

And so you can run your your application on your local machine, which is useful for local development.

And, Yeah. You can write your own applications just for using WASI to run on your machine as well. It doesn't have to be, using Fastly's computer edge SDK.

Node. Js also supports the WASI, addition to WebAssembly.

So you could write, applications and then use them in Node. Js as well. Oh, that's cool. And

how large is that type of thing? Because I often see these things. I'm like, wouldn't that be cool to throw that on A microcontroller.

But you can't like, I've taken the entire Node. Js runtime and, like, compiled it, And it's like 50 megs or something like that. Right? You can't put that on a on a microcontroller.

The Wazee, that doesn't make it any smaller, does it? It it depends on, I guess, What

you're compiling to Wazee.

So there's the QuickJS, JavaScript runtime, Which is very small, and you can compile that to WASI.

But there's like, Spidermonkey, when we compile that to WASI, I think it's about 20 5 megabytes.

I need to check that, but that's what I think. Well, it's it's honestly quite amazing that that can fit in 25 megs, though. Like, people talk about how big JavaScript is. But you literally get the probably the most powerful dynamic runtime ever For 25 megs.

Yeah. If you were using, you know, a different language that doesn't need, like, a an interpreter, then like Rust, Then your wazee binary that you get from compiling is much small. Let's take a wider view about,

WebAssembly. Since Y'all do so much web assembly stuff. We don't get to talk to that many folks who do that much web assembly concerning it. It feels very, very specialized at this point still.

So do you wanna give, like, a really basic overview of What is what what is WebAssembly particularly well suited for? And, like, who should be interested in

Learning more about diving into WebAssembly. My my opinion is it's suited to everything.

Nice.

Nice.

And we just need to get more languages to support the compiling down to WebAssembly so that the end engineer Doesn't need to worry that they're write but they're writing in a JavaScript or Rust or whatever other language, and they just view it as another target that they, can can compile 2.

So it's it's not something that they need to know anything specifically about. That's my my my view on it. Like, you don't usually think about, any other kind of architectures that you're targeting when you're you just use your compiler and you say, I want to target ARM, And then it compiles to arm. Mhmm. And I I think WebAssembly is Yeah. I would like it to go into that direction so users don't They don't have to know about it. They can target it. And if they want to learn the specifics about it for some, like, advanced optimizations that they want to do, they can then look into to using it. But, yeah, I would hope that it becomes transparent and just gives you a secure, artifact that you can then,

run. Exactly.

I I think for for everyone listening, like, if you're still not sure what WASM is, The the answer to that is you can literally run any language in the browser, meaning that, like, if you're building something And you're but you you think, oh, we want this to run-in the browser, so we have to build it in JavaScript or we have to run a server that runs this language, then we have to send HTTP requests back and forth between the browser and the server to communicate with it. So the idea with WASM is that you can compile any language. So, like, maybe you have, like, a weird barcode scanner app That's written in c plus plus Right? And you want to be able to, like, integrate that into your app and, like, ah, shoot. Like, now we have to reimplement the whole thing or, like, You have some detection, a tree counter AI thing where you take a picture and it counts how many trees are in a photo, but that's written in COBOL. Right? You can compile that language down to WASM and then run it in the WASM. It's it's not as easy as I'm I'm saying. I'm sure it's it's Incredibly difficult, but, that's the whole idea is that you can run it. And then Wazee takes it even 1 step further in that you don't just have to run That compiled WASM in the browser, you can literally run it anywhere WASI runs.

Yeah. And then you also get your Is that right? That's exactly correct. Yeah. And you can also then, with Wazee, like, request to read a file in the file system.

And if the When someone ran your program, if they gave you access to that part of the VAR system, you will have access to to it. And if they didn't, then You don't. So it's it's secure on that way. And Oh, yeah. Barcode scanner running on a web page is is really good. But I also thought Sigma is c plus plus that compiles to WebAssembly. The whole application is WebAssembly.

It's massive. Yeah. It's massive. Yeah. And, I mean, it's one of the best performing apps in that. I mean, you would never even be able to tell it was running on web tech at all.

So, I mean, that goes to show you how powerful Yeah. I think they have their own, like, font engine that they that they implemented as well. So, like, They can have the same point rendering across all of the different browsers because it's their own engine that's compiled to a WebAssembly that they're running in them all.

Wild stuff. Wild, yeah, wild project. Often people say, oh, Figma's running on WebTech, and it's like, it kinda isn't.

You know? Like, it is, but it isn't. Like, if you you can run it in the browser, but it's not it's like, most of the, like, Brains and beef behind it is running in WASM, and then the view layer is running in in JavaScript. And we we talked to the guys from Google Docs as well. And and that's how they run a lot of the Google Docs, stuff because they need Google Docs.

Like, if you add 2 cells together in Google Docs and run like a a payment time value money calculation on the on the results of that, that needs to run on your your phone. It needs to run on a Chromebook. It needs to run-in the web browser. It needs to run on Android and iOS, and Probably maybe a cash register. You know? Like, it has to run everywhere. But, like, are you really gonna reimplement Time value money calculation that was written in Java 15 years ago. And are you gonna reimplement that in JavaScript? And The answer to that is no. They I'm pretty sure they said they use WASM. They compile it from Java into, something that oh, no. I think they compile it straight into JavaScript, But it's it's the same idea is that you don't have to rewrite it for multiple,

targets. Yeah. And Docker, I think, is also now, working on supporting running WebAssembly in, alongside their containers that they support as well. Do you think that might be the

The new container?

That's what their CTO of Docker said, I believe. Yeah. Really? Yeah.

Yeah. I think there's a tweet by them a while ago where they were said, like, if this existed before we worked on Docker, this is what we would have been using from The beginning. Wow. And they could do that because WASI

extends what WASM can do by giving you Full access to things that Docker might need, like you said, as a file system. It all makes sense. I'm so glad that we're having those conversation because it's like, yeah, Wazee runs locally, but I guess, yeah, there there were limitations of the browser, and Wazee extends those APIs

So you can have access to everything. Yeah. It it gives you it gives you, whatever the host wants to offer to you. So if your host offers you, like, like, yeah, file system access, then you can use that. Or if it offers you access to a key value store, then you could use that. And whatever it doesn't offer you, you you can't use. So if I don't offer you a file system, your WebAssembly program, even if it was trying to read from a file system, it couldn't.

Like, it's and that's, like, the capability, like, based security that's within in WASI and the upcoming Component model that's being introduced to it as well. Wow.

Is there anything that, like, Wasm is not good for, specifically in the browser? I know you said Good for everything.

But, like, I've heard I've heard that, like, if you have to go back between the JavaScript Wasm bridge

too many times, That could be a bit of a bottleneck. Is that true? That's true with WASM on its own. Yes. Because it can only like, you you can give it a bit of data and it can operate on it.

So it doesn't know how to it doesn't know about the outside world.

I would presume if, When or if browser supported Wazee, they could offer functions to that they could give to the WebAssembly, application for it to then modify parts of the DOM.

I don't see why that wouldn't be out of the the realm of possibility. It's just not what they have yet, because I don't think any browsers implement

Wazee. That's kind of similar to, like, like web workers, where web workers are its own environment. Right? It's not server. It's not Browser, it's its own environment. Right? It doesn't have the DOM.

And I'm pretty sure There's a party town created a whole bunch of APIs that allowed you to sort of work with the the dom. I'm using air quotes here, so that you don't have to keep going back and forth.

Yeah. And you have the, what's the project made by Surma? Worker abstraction as well. I can't remember the name of that one.

Comm link.

Comm link? Yeah. That enables you to, like, write a function in your JavaScript and then have it Run as a web worker, and you're like it's sort of, like, transparent to you that it's in a web worker. Oh, that's nice.

So you you don't have to, like, worry about necessarily where it's running. You just wrap it in a comlink.wrap, And you just have full access to it. That's really nice. It's it's that's sort of like the, what are we talking about? Where Remote procedural RPC.

RPC, remote procedural call. You just call a function, but it's really running on the server. Yeah. It's similar to All of the stuffing that makes it transparent is so nice. Yeah. I posted a link from a a smashing mag post from Surma about web workers, including talking about Commlink in the show notes. So you wanna dive in more? That was, I think, the first time that I saw a, like,

What I thought was a really good use case for proxies in JavaScript, because I never really, like, saw a good use case for it before. And that was like, Yes. I can just pretend I'm writing a normal function, and then it's somehow running in a worker, and I don't even I'm not even aware of it. That's cool.

Yeah. Oh, that's cool. So a proxy is the ability to sort of intercept The calling of functions or accessing getters or setters on an object, and you sort of, like, step in between and go, oh, yoink. I'm actually you it looks like you're trying to access a a property.

But in reality, I'm running a A a proxy. And when you can grab that and run your own code, and do the output. So I guess in the actual proxy resolver there, they then run the web worker and Return the values of that.

That's genius. Yeah. I reckon it's something like that. It's, I guess, very similar to HTTP proxy in Intercepts requests Yeah. Does whatever it wants. Mhmm. Can send it back to an origin or return a new response.

I love tech like that because We the same thing happened with tag template literals. When tag template literals came out in ES 6, we had, like, a bunch of, like, examples of how to use it and whatnot, and Everyone's just like, okay. But, like, like, what are we gonna use this for? And sometimes it takes. Now there's all kinds of use cases for tag template literals out there. You've DOM purifying, tagging CSS, converting, MySQL, sanitization, all kinds of interesting Use his wedding, which is Yes. Sometimes they just have to, like, sit on the tack until a really good use case comes around and people go, ah,

I see. Yeah. I think my favorite tag template one is, there's this group of libraries called Worker Tools, and the website is worker.tools.

They make JavaScript libraries that work across, you know, the different worker runtimes.

And they have a HTML, like, Templating 1, which is the streaming template rendering and can work with, like, promises and, you know, readable streams and anything, like, generators, async functions.

That's my favorite one. Like, just use tag templates there, writing my my HTML templates, and then it's I get a streaming response back. It's not, like, buffering it to compile the whole template, Streaming it through and pauses whenever there's, like That's yes. To resolve. Yeah. Yeah.

So I combine that with Hano, and that's, like, my my ideal setup.

I am a big fan of worker tools. I included this in my talk as well. I would love to actually have, the dev behind this on it because he's put out First of all, he polyfilled the entire Cloudflare HTML Rewriter API, which is a really cool API for, like, intercepting, and streaming requests on in.

But there's all kinds of promises, JSON fetch, Key value stores, all kinds of interesting things.

So if you were building a a web service that had A front end, I guess, like a back end, like APIs. It hits hits URLs, things like that.

What would your Stack b. So far, my personal projects, because that's the only other ones I have except for my work one, is,

yeah,

Computer Edge using JavaScript, using Hohono for the, like, writing the route handling and the middleware logic, And using the worker tools, HTML template library. And then when I need storage, I use I try and do everything using Fastly's compute platform. So I use, like, their KV store And the config store that they have, which is like a way of having, configuration Variables on your service similar to environment variables, that you have on the other, run times.

Yeah. I try and do as much as I can then, avoid deploying to anything else.

Also means that I get to benefit from Using the product that I help build, which helps find out if, I can improve the documentation or the API and, like, make it friendlier to use. So I always try and Build a project using whatever thing I'm working on. Yeah. I think that's always a a big key to,

shipping good products because you'll find everything.

You know, you'll find all the the edges.

Yeah. So I've made, like, a hacker news client That runs on Computer Edge, my own website.

The documentation for the JavaScript SDK for Computer Edge, That's Docasaurus as it's, like, website generator. Mhmm. And that all runs on ComputerEdge as well.

Yeah. The one that I've been working on but I haven't finished or published yet is for personal personal uses, like a CMS for Pricing of content on just all within computer edge and not using any other services.

One thing I really wanna make is, I have all these, like, demos that I use Vite for. It's the best because you have an HTML, and you can use a script tag to a TypeScript file. You can use Link tag to a CSS file that has, like, unsupported browser stuff. And I love using Vite locally because you can just Visit the URL and it it sort of builds it on demand. And then with with Vite, you have to, like, you have to bundle them all. Right? And I have I have this, like, folder that's full of hundreds and hundreds of demos that I use for my TikToks and Twitter and and everything like that. And I went down the rabbit hole of trying to run v dev mode in production. So whenever somebody hits a URL, it just Compiled it on demand, and I actually got it to work pretty well.

And I I was thinking, like, it would be really cool to, like, go even a step further and try to get I don't know if Vite runs on things that aren't Node. Js, but to get that to run on, like, Fastly Compute at Edge because then I wouldn't even need to have a build step.

I could just have the whole thing run on request. It's so fast. Yeah. And and, like, Moe, you could probably throw the The output into a key value store and cache it or or maybe even use CDN to cache the output of it at some point. But I I think that would be such a killer tool. Other people don't seem to, like, have the same problem as me where I just have lots of demos. But for the new syntax website, we're we're kinda talking about that as well. A demo engine. Yeah? So I think I've never used feed, but I presume it assumes there's a file system

where it's gonna read the content from. Yes.

So you'd have to, like, be able to change that part to read from here, like, provide a function to it instead where you can then control from a file system or a KB store.

Yeah. That'd be really cool.

It runs in memory. If you run Vee programmatically, It will run-in memory, and you can get the output of it. And and I even went I even inlined all of the CSS, JavaScript and images to base 64.

So the output was just a single file.

So, like, if it can run-in memory without a file system because I I have it Running.

But, I I know that people are really trying to get Veet to work with Dino.

So I bet

Once that's out or maybe it maybe it already does, I bet then we'll be able to build something like that. We should try it when that happens. Yeah. That would be really cool. Yeah. And, we introduced the we have a cache API so that you can then put stuff into the CDN cache as well. Oh, sweet. There's 1 thing we haven't well, there's 2 things. One of them, I don't know about we should talk about or not, but the other one, we I think we should because it's very different.

That it's a very like, one thing makes The Fastly JavaScript SDK runtime different from all the others, which we haven't mentioned here. And I think we should talk about it because I think it's It's really cool, and that is, with the like, when you boot up a JavaScript runtime, it has to, Like, create all of the the realm of your JavaScript and create the globals, and then it has to pass your JavaScript's source code, Turn it into a syntax tree, and then it can start interpreting it and then optimizing it, etcetera.

And that all of that takes a lot of time.

And when Fastly were working on the JavaScript SDK originally, he thought, like, the amount of time that that takes It's, a bit too long. And so they were working on a way to see if you could do that all of that ahead of time.

There's a talk by my colleague Nick Nick Fitzgerald on this tool that they ended up inventing called Weiser.

And what it does is it Runs the top level of a web assembly program, runs the top level instructions, and then generates a new web assembly program with, the end state from running those top level instructions.

What this means for JavaScript is it ends up running your top level scope of your JavaScript application.

And when we're compiling your program to WebAssembly, So the the top level of your application has already executed, and the runtime has already, like, initialized.

And Mhmm.

That's very different from every other JavaScript runtime. And it was actually a research project originally by Facebook, called Prepack, if you remember

Prepack. So far, everyone I've mentioned this to, they don't remember it, so this is great if you do. I only remember it because I didn't remember it when we talked about this the first time, and I went and researched it. I remember the name, but I never used it. So my my cursory,

yeah, knowledge of it. Yeah. I don't think it ever left the research phase, but it was like The the same problem sort of exists for websites where when you visit the, like, Like, any website multiple times, you're having to redownload the same JavaScript file while you've got it cached, but you're then still having to, like, Repass it and evaluate the the program. And, like, that top level scope doesn't usually change between each time you evaluate it. Mhmm. And so Facebook were thinking, well, let's preevaluate that and then pack that up into a new JavaScript file that we ship. That's why it's called prepack.

And the tool that my, colleagues made called Wiser does that, but for WebAssembly.

So Any language that can pass to WebAssembly can then use this to run their top level and then create a new program based on that. And it's It means that you can do, like, lots of computation in the top level scope of your JavaScript program if you wanted to. And all of that's done when you compile your program before you even, Like, deployed it anywhere? There's a similar project for specifically for JavaScript.

It's a Babel plug in by Kent c Dodds called, like, Babel Macros.

Oh, yeah. Mhmm. Mhmm. So it's exact like, it's similar to that, except it's on your whole program rather than on specific, like, macros that you've included. And it doesn't require, like, a paper or anything. I just thought of an example in my own code base that I'll give the listeners an idea. So

With my courses, I have, I don't know, probably 6 courses that are paid.