The new wave of JavaScript: A Taxonomy of Runtimes and their Web-interoperability

Hi, this is the new wave of JavaScript.

There are a lot of ways to run JavaScript.

The obvious way is in your web browser.

There's Safari Chrome, Firefox, or the other trendy browser you're using that is just secretly chrome.

There's also node, and node runs JavaScript outside of the browser, directly on your computer or server.

But, now there's some more runtimes coming out, and it's starting to get a bit wild.

If you're thinking about node alternatives, there's two big competitors.

Deno and BUN.

But, then if you're looking to run your code on a server, You might be looking at options like Vercel, or Cloudflare, or Fastly, which run their own custom JavaScript runtimes.

They aren't Node, they're not Bun, and they're not Deno.

That's a lot going on, and this is just the stuff that's relatively popular.

This leaves me with some questions, like What are they all for?

How are they different?

How does this impact me?

And, more importantly, how did we get here?

And I'm going to talk about the eras of JavaScript runtimes.

I definitely planned this to align with the keynote, and didn't last minute do a find replace.

Era 1 is the browser.

In 1995, Brendan Eich created JavaScript.

This has made many people very angry, and has been widely regarded as a bad idea.

Famously, he built the first prototype in 10 days, as a mashup of Scheme and Java.

Leadership wanted it to look like Java, to be developer friendly, but he wanted it to look like Scheme, sorry, to work like Scheme, because that was more powerful.

He originally called it Mocha, but then later named the runtime SpiderMonkey.

That one's important.

JavaScript was really popular, so Microsoft copied it, as Jscript, in their 1996 release of Internet Explorer 3.

Now, Internet Explorer, at this point, is not very popular.

No one's using it.

It's 90 percent Netscape.

Internet Explorer, Microsoft, that's the newcomer.

They called their JavaScript engine Chakra, and this would be the first competitor to SpiderMonkey.

In late 1996, Netscape took JavaScript to ECMA International, the ECMA doesn't stand for anything anymore, to get standardized.

The first edition, ECMA 262, was adopted in 1997 as ECMAScript, a name that nobody liked, but wouldn't get anyone sued.

By Sun.

In 1997, Opera adds JavaScript support.

I'm sure it's really neat, but it's irrelevant to this talk, sorry.

In 1998, Netscape surprisingly open sources all of its browser code.

All of it.

Including SpiderMonkey.

And hands it over to a new organization called Mozilla.

This is to be the open source innovation hub of Netscape, while Netscape is the commercialization frontier.

Then, in 1998, Microsoft releases Windows 98.

It has Internet Explorer built in by default.

Can I see if this sound works?

We've got, yeah.

Microsoft does deals with all the major players to lock Netscape out from PCs.

Netscape gets absolutely annihilated, just destroyed.

This later becomes the subject of the famous United States vs.

Microsoft antitrust case, which is a great Wikipedia black hole if you've got some time.

Now we're at the start of Era 2, competition.

By the beginning of the 2000s, Microsoft is in total control of web browsers.

They have the best and most popular browser.

Over 90 percent market share.

They don't need to do much with it, or with JavaScript.

Most novel interactive apps in this time were made with Flash and written in ActionScript, which is actually a dialect of ECMAScript.

It was secretly JavaScript, but they were written in Flash.

The first competition for the browser space would emerge in 2003, with Apple forking KDE browsers, KHTML, and KJS engines as WebKit and JavaScript Core, respectively.

KDE, for anyone who doesn't recognize the name, is a Linux distribution.

So this fork would become the basis for the Safari browser used exclusively by trendy graphic designers on iMacs running Mac OS X Panther.

In 2004, a real contender appeared.

Mozilla released Firefox, a stripped down and sped up version of their now aging Netscape codebase.

It focused only on web browsing and doing it well.

SpiderMonkey came back from the dead and Firefox started taking serious bites out of Microsoft's market share.

This was the era when I installed Firefox.

I remember being really excited about it.

It was so cool.

Then, in 2007, Apple releases the iPhone.

You might have heard of it, the iPhone exclusively runs Safari and has no support for Flash.

This is a huge turning point for browsers and for JavaScript.

Over the next few years, Safari would dominate the mobile browser space, and without Flash, web developers had to use JavaScript to make innovative new web apps.

Not long after this, another JavaScript engine came onto the scene.

In 2008, Google releases Chrome, using the WebKit rendering engine and a whole new JavaScript engine built from the ground up.

It's called V8, and it's really damn fast.

It's the engine behind Chrome's claims of speed, and more importantly, isolation.

With V8, no single tab could take down your whole browser, which was a real issue at the time.

My Firefox would crash all the time from some bad behaved tab, and so I installed Chrome, 2008.

At this point, we have four major browsers, all competing for market share.

All with their own JavaScript engines, and all spending money on them.

This is genuinely a really cool time for web innovation, and for JavaScript runtimes getting extremely fast and lean.

JavaScript today is really fast because of all the stuff that happened back then.

And now we get to Era 3, the server.

In 2009, Ryan Dahl releases Node.

Js.

It's a C++ program that utilizes V8 to run JavaScript.

Put simply, it runs JavaScript directly on your computer instead of inside a web browser.

And it's powered by the same very fast engine that powers Chrome.

One year later, in 2010, Isaac Z.

Schleuter releases NPM, a package manager for Node.

These two forces become a huge accelerator for innovation in the JavaScript ecosystem and in web development at large.

For front end developers, the combination of Node and NPM slowly becomes a core part of the way we do our work every day.

I type NPM every day.

NPM becomes the way we distribute libraries, Node becomes the way we run bundlers, and the way we test our code.

In the new full stack world of server rendering, we even use Node to render our components.

But there are some weird friction points between Node and browsers.

The JavaScript you write for the browser often doesn't work in Node.

And the JavaScript you write in Node doesn't tend to run in the browser.

People start to write JavaScript that is isomorphic, meaning that it will run in both places.

But if you want to use any of the useful features of the web, it won't work in Node.

And if you want to use any of the useful features of Node, it won't work in the web.

And you end up eliminating the option of distributing to the other if you do that.

At some point in 2016, Microsoft releases ChakraCore, an open source JavaScript engine.

They also release a project that enables Node to run on Chakra instead of V8.

Nobody notices this.

I had no idea that this happened until I started doing research for this talk.

If you, want to use Chakra for something, it's out there.

That brings us to Era 4, serverless.

In 2017, Cloudflare announces Workers, a serverless product based on V8.

Workers makes innovative use of the V8 isolation system to run short lived, low latency functions.

It's a functions as a service provider that lets users run code anywhere in the world on Cloudflare's edge CDN network.

What's really interesting is that it isn't Node.

It's JavaScript on servers, but without any of the Node APIs.

Instead, in a kind of weird stroke of genius, genuinely I don't know how they got this idea, they chose to adopt Service Worker API.

That's a web standard, and they add fetch, so it's a service worker on the server instead of in your browser.

That's really cool.

In 2018, Ryan Dahl does a talk at JSConfEU titled, 10 Things I Regret About Node.

Js.

Can you guess what some of them are?

In this talk, he highlights a big list of things that are bad about the way Node has evolved.

It's like the best roast possible because he's just roasting himself.

As a solution to his own negativity, he announces Deno, a secure TypeScript runtime based on V8.

It introduces a lot of new ideas for how JavaScript could work on the server.

One important idea is that is being browser compatible.

Where Deno overlaps with the browser, it should work the same way the browser does.

.In 2019, Microsoft retire Chakra and rewrite Edge to be based off Chromium.

Internet Explorer finally dies.

This is not really related, but it's fun to talk about.

In 2021, Jared Sumner starts Bun.

A batteries included JavaScript runtime based on JavaScript core, that's Apple's one, and written in Zig.

At this point, it looks a lot like Deno or Node.

But using a different engine.

Its goal is to be fast, but it wants to enable a great developer experience too.

It aims to be Node compatible, but also interoperably execute CommonJS, ESModules, JSX, and TypeScript.

On top of that, it's a bundler, test runner, package manager, and web server.

It's an ambitious project.

In 2022 The Web Interoperable Runtimes Community Group is founded by Cloudflare, Deno, Vercel, Shopify, and Node.

And there's actually a lot more, people that are participating in that now.

Its goal is not to write its own standards.

Instead, they aim to consult with existing working groups on existing standards to help them be compatible with servers.

The end result should be a world where more and more standard web APIs can run in any JavaScript runtime.

This is a really interesting development for those of us who care about the web.

In 2023, the Bytecode Alliance releases the WebAssembly Component Model.

They also create a project called ComponentizeJS, which is a way to run JavaScript inside WebAssembly.

Now, I want to point out, this is like pre standard stuff, so this is not going to be in browsers, but it is working and live in production on servers.

What's really interesting is that internally, the way it works is that they've compiled SpiderMonkey, the JavaScript engine from Firefox and they bundle it along with your JavaScript into a single WebAssembly binary.

So what they're doing is they're running JavaScript inside WebAssembly by compiling a JavaScript engine to WebAssembly.

Which is an insane idea and a bit hard to wrap your head around, but they've done it.

And then companies like Fastly use this to run JavaScript inside WebAssembly on their Edge network, which has some really interesting effects.

And now it's 2024, right?

And that's the end of my eras tour.

What have we learned?

I think it's important to look at the pieces that put runtimes together.

The vast majority of JavaScript runtimes are based on V8.

So that's Chrome, Node, Deno, Cloudflare, Vercel, every other browser you use, they're all based on V8.

But recently we're seeing some projects adopt V8 other engines.

This makes me think that we'll see some innovation in the JavaScript engine space, along with innovation in the JavaScript runtime space.

You're seeing Bunn adopt JavaScript Core, and the reason for that is that JavaScript Core works really well on iPhones.

IPhones are low powered devices.

Go listen to a talk by Alex Russell from last year.

But Safari is much more optimized for speed and low power usage than V8 is.

And then we're also seeing people do weird stuff with SpiderMonkey.

So that's cool.

And we'll see some innovation there.

The next thing worth looking at is the places where these runtimes are being used.

The list of browsers is relatively stable.

Firefox is still hanging on, but with the rise of AI based search, we might see their main source of income, Google, disappear.

And that would be a real shame for the web ecosystem.

But the browser list, that's probably going to stay the same.

There's innovation happening on the server side.

Not in the browser, you've got Deno and Bun looking to take over from Node.

This means we'll see changes in the way we bundle, test, and distribute JavaScript.

I, what I wanted to talk about, sorry, was serverless as well.

There's heaps of innovation happening in serverless.

That list, Deno, Cloudflare, Versal, Fastly, Shopify, that's where all the hot stuff in JavaScript is happening.

And that means that we'll see stuff from them leak back into the web and into what we're doing.

I think importantly, that puts me on to this point, ecosystem changes impact us, we're not in our own little bubble.

Especially since we want the web to be everywhere.

And if we want the web to be everywhere, that means that everywhere is going to affect the web.

Because of the iPhone, we're JavaScript developers.

There's an alternate reality where Adobe did a deal with Apple and got Flash running on the iPhone.

There's a strong possibility that in that universe, the dark universe, we'd all be writing ActionScript right now.

At the time, Flash was a much better tool for interactive web applications than JavaScript, CSS, and HTML.

It was genuinely better.

Is JavaScript still winning?

It seems like it is.

But where is tech going next?

Will the web go there?

Will JavaScript go there?

I hope so, because it makes me, makes it easier for me to keep a job.

When I started my career, I worked in agencies during the transition from Flash to JavaScript, and it was brutal.

That transition wiped out a lot of workers.

Because of Node, we have packages, bundlers, modules, types, and more.

But, what will Bun and Deno give us?

Are we done innovating in what is possible before our code gets to the browser?

So far, tools like Bun are doing the same thing, but simpler and faster.

That's really nice, but is there a job we need that they're not doing, but they could?

I personally am a huge fan of TypeScript.

I started out my career as a Ruby developer, and I have no idea how I held all the types and data flow in my head.

Genuinely, if I write Ruby today, it's like someone's cut off my arms.

When I'm onboarding developers, the parts of our codebase they struggle with most are the untyped parts.

Without types, the boundaries between modules are too unclear.

Is there something more in this space?

One of the reasons single page apps are so compelling is the UX.

Sure, the first load is slow, and that's absolutely something we need to fix.

But every tap after that is instant.

If you've done things right, it feels like flying.

That's just not possible with Server Roundtrip.

It's tens of milliseconds to a server in Sydney.

It's hundreds of milliseconds to a server in New York.

But edge networks are right there, and their startup times are insanely quick.

If your server is co located with your cell tower, that could be less than a millisecond away.

And if your edge cold startup time is less than a HTTPS handshake, which it is, cold start time, less than a HTTPS handshake, that's insane, then you can get the same instant feeling as a single page app.

But you can offload all the work to the server.

This could be a total game changer.

When I look at the performance of our single page app that we build at Stile, the main problem isn't that we're using React, it's that we're requesting so much data.

Figuring out ways to reduce the amount and round time of this data would really help.

And doing that server side rather than client side is much easier.

What will WebAssembly components give us?

This is my pet passion, and it goes back to the bit I was saying before about boundaries of modules.

I don't think the systems we're designing have very clear boundaries.

Particularly when we're working in JavaScript, the idea that you import something and then it does a bunch of side effects, or it bashes onto the prototype, which nothing is doing anymore I'm sure, but, we, we've done it in the past.

Those, without those clear boundaries, it's really hard to share and reuse code.

The WebAssembly component model creates a standard way to describe boundaries between modules of different languages.

Not just one language, different languages.

And WebAssembly is in the browser.

WebAssembly is a web standard.

And that means that we could have interop between our JavaScript and someone else's Rust code.

Or our JavaScript and someone else's Python code.

And that is a really interesting idea.

We could end up with, instead of a million Node modules, and a million Python packages, and a million Cargo packages, we could end up with just one ecosystem.

Which would be really neat.

There's more there.

It's another talk, I reckon.

I think, ultimately, I don't know where all of this innovation is going, but I do know that competition is good.

We've gotten a lot of neat things out of Node.

I talked about bundlers.

I talked about things like TypeScript.

The tools we have for CSS transformations, think about web compatibility, browser compatibility.

Browsers List just does that for you.

All of that stuff has come from Node.

But it's now time to see what happens when there's more players around.

It might get messy, but it also might get interesting, which would be really cool.

I work at Stile.

Our mission is a world class science education for every student.

We're serious about science.

And, we work on stuff that is related to this, but is not exactly this.

We don't do anything serverless.

We do build a single page app.

We also have servers, but they're written in Ruby.

I'm Tay Benlaw on socials.

I'm also here physically.

You can come say hi.

But if you want to find me online, that's the, keyword you want to search.

And that's me.