The Future of JavaScript Runtimes

Hi everyone, my name is Aron and I'd like to thank you for joining me at Node-Congress. Today I'm going to talk about the future of JavaScript runtimes. We're going to look at how JavaScript runtimes have evolved from browsers to servers and how Node and other technologies have evolved over the past decade and how that will shape the runtimes of tomorrow, the ones we'll use in 10 years. I think it's an interesting exercise. Obviously neither me nor others can truly predict the future, but the interesting thing is, since some of us work on runtimes, we have the ability to impact it. And so I think with this talk, I want to open up that conversation, get the conversation started, and basically hear other thoughts because I think there is a lot of room to innovate and there's still a lot of room for JavaScript to progress.

So let's jump in. So I think, as I mentioned there, we'll look at what will runtimes look like in 2025, 2030, what new capabilities will these runtimes have, what new use cases will they enable, what kind of primitives will they have, what kind of ergonomics will they have, how will that impact the software we build and write or how we deploy software, how we use it. I think there's a lot of different angles that we'll look at as we step through this.

And so a quick disclaimer is obviously I work at Deno, so I'm slightly biased. I like Deno, obviously. But I would say these are mostly my personal views. I've been working full-time on JavaScript runtimes for less than six months. There's people on my team at Deno or even at NodeCongress today who have years or decades of experience building runtimes. So I'm quite new to this. And then also, of course, my talk won't be and can be exhaustive. I'm mainly going to be focusing on the CLI and cloud side of things, obviously browsers and desktop and mobile are huge trends and huge facets of JavaScript. But that won't be the focus of today's talk.

So anyway, let's jump right in. So, you know, first let's take a look at the historical trends and how JavaScript has evolved. And that will inform a little bit how it might evolve in the coming decade. So let's take a quick look at the timeline. So JavaScript was first created by Brennan Eich in 1995 in 10 days, which is pretty extraordinary. Obviously, there came some trade-offs. And, you know, JavaScript continued to exist in browsers. And it was only up until kind of 2008 when Google shipped V8 and Chrome, that web applications really became a thing, because V8 radically changed the performance of JavaScript runtimes and really enabled kind of modern JavaScript heavy applications that weren't really possible before.

And then, you know, only less than, you know, less than nine months later, Brian then built and shipped the first version of Node in 2009. And that's, I think that's, you know, Node's impact is not to be understated. We're obviously all here because of Node. You know, Node has enabled us to build server-side applications in JavaScript, and it's also enabled a ton of tooling on the front end side, et cetera. So I think that's quite impactful. Obviously this timeline is not exhaustive. There's other key events, but once again, I'm trying to stick to the points that I think are relevant.

And then I think, you know, another key event in the timeline is Microsoft shipping TypeScript in October 2012. And so it takes some time for TypeScript adoption to grow, but you know, I think today we're starting to see the TypeScript is maybe one of the dominant forms or dialects of JavaScript that teams are using to build new applications. So, you know, looking back at 2010, you know, we can see a few key trends, such as front end.

Obviously, not to say that front end didn't exist before 2010, but it really wasn't the same game. Before 2010, you had jQuery. Now you have React, JSX, Vue. And obviously with these modern libraries came modern tools, such as Babel, ES Build, Webpack. And that also enabled modern frameworks like Next.js or Tailwind CSS. And so front end has changed really quite radically in the 2010s, and especially in the second half of 2010.

TypeScript obviously came along. You know, TS Node has somewhere in the region of 18 million downloads per week on npm. So it's really quite widespread. Serverless became a thing. For better or for worse, you know, we now have Lambda, Google Cloud Functions, Firebase. But I think there's a few differences between kind of serverless and Lambda and then kind of the modern clouds that we'll get to later in the talk. Then obviously desktop and mobile. So a kind of quick recap of some of the technologies that have changed. You know, Yarn came around. We switched from callbacks to promises. We switched from jQuery to react. We switched from common JS with requires to ECMAScript modules and imports. We switched from XHR to fetch. It's hard to understand how much JavaScript has changed over the past decade.

I think when you think about JavaScript, obviously there's a core language. And that's not going to be the focus of my talk today. I'm not going to focus on the core language, which is still constantly evolving. There's lots of interesting things coming like immutable records or tuples, which are extremely interesting additions that I'm looking forward to. But today I'm going to focus more on a JavaScript runtime. So you can think of that language plus specific primitives to an environment. And so I think when you kind of look at JavaScript holistically, it was born in the browser, which gave it these core compute and document primitives. And then Node essentially kind of brought Unix primitives into JavaScript exposing Unix sockets, TCP sockets, the process model, you're spawning in and forking child processes, all that kind of things, which make it powerful, which made it powerful and useful to build CLI and server applications. But I think it makes sense to ask, what's next? Are you going to stick to these same primitives or are we going to come up with new ones? And when we think about like the modern cloud, should we bring cloud first primitives into JavaScript? Something worth taking a look at. So yeah, I think the takeaway here is, JavaScript is constantly evolving.

It's evolved over the past 20 plus years. And then the interesting thing is we can shape its future.

So let's take a first stop at browsers. I won't focus too much on browsers, as I mentioned before, but I think there's some interesting, quite notable improvements that kind of impact us as Node and Deno users. I think something that's quite notable here is the invention of web containers. So StackBlitz released this thing called web containers a few months ago. And it enables you essentially to run full Node-like applications in the browser. It does it quite efficiently. It's not emulation. I don't want to get too much into it, but it essentially polyfills key parts of Node. And then it reimplements a TCP stack using service workers. There's a lot of interesting technology there. And I think the key thing is that it's essentially Node packaged into the browser. But yeah, let's move on to that because browsers aren't the focus of today's talk.

So, let's take a look at CLIs such as Node, DNO, Bun, and many others. And let's really take a look at how they might evolve in the coming decade. And so, one of my first predictions is oxidation. We'll see more and more kind of core JavaScript runtime technology built in Rust. And the reason there is C++ is nice, but it's also painful. V8 is built in C++. It will likely never be rewritten. But Rust is a much more modern language that makes it easier to build key technology. And we're already seeing this. DNO is built in Rust. It's got wrappers around V8 and Rust. But besides V8, nearly the entirety of DNO is Rust. And that provides some safety guarantees, but it also, I think, increases the speed of iteration on the runtime, making it much more accessible for people to contribute to. We're also seeing the rise of Rust in tooling, such as Rome or SWC. These are pretty interesting involvements and they are mainly motivated by speed. People don't want to wait for their front-end apps to build.

They don't want to wait for their linter. They don't want to wait for their formatter. So there's a lot of interesting things that are happening there. And there's been the introduction of Node add-ons have evolved to an API, and there is a wrapper called NAPI.RS, which allows you to build and API modules in Rust. And this is used by Prisma, Next.js, Rollup. So we're probably seeing kind of adoption of Rust technology in the tooling and in the runtimes, both on the Node and Deno side. And so, I think that will continue. So this isn't so much necessarily on the runtime implementation, this is more on the ergonomics and APIs.

I think we'll continue to see the webification. Node, when it first shipped, didn't really align with the web APIs. And I guess also I think web APIs matured a lot over the past decade. And so, a key milestone is Node 18 is shipping ECMAScript modules, HTTPS imports, and Fetch in Node 18. And that's a major step forward. I think as these web APIs have matured, I think they're essentially becoming the standard and we're able to kind of phase out some of these older legacy Node APIs in favor of standard APIs, such as Nodes require crypto being replaced by WebCrypto, or HTTP and HTTPS being replaced by Fetch. Even though, in practice, a lot of people already use Node Fetch. My personal experience is that HTTP built-in APIs into Node aren't necessarily the most pleasant to use, and so I've seldom seen people use them bare-bones.

Anyway, moving on, I think if we move away from Node for a second and look at Deno, Deno very much considers web APIs as first-class citizens. We try to implement them as thoroughly as possible. We try to be as spec compliant as possible. We really think that there's a lot of value in implementing these modern web APIs. We have pushed this quite far. We run WPT tasks, which are the same test that browsers run. In fact, in some cases, Deno is more spec compliant than some of these browsers. If we take a look at No Crypto, for example, Deno is more spec compliant than Chrome and Firefox, only slightly behind Safari. It's interesting to see a CLI in server runtime embrace these modern web APIs that have evolved and matured over the past decade. Going back to some of the trends, we saw that TypeScript was a major trend of the 2010s. I think that TypeScript will become the de facto dialect that teams and programmers use. It's extremely widespread and there's tons of benefits to it. The TC39 organization is considering ignorable typing. What this would allow is essentially for V8 and other JavaScript engines to execute TypeScript out of the box.

They wouldn't understand the types, they'd essentially ignore them, but they would be able to essentially run TypeScript untransformed, which is really quite interesting.

I think another evolution is JSX has changed the way we build frontend. It's essential today. And I think given that it's become essentially a de facto standard, it's possibly worth considering bringing JSX into the language itself. That can be quite controversial, but there's a lot of control upside.

And as I mentioned earlier, TS Node has nearly 20 million weekly downloads, which shows huge adoption. Obviously a lot of that's probably CI, but it's fair to say that TypeScript is no longer the underdog today and supports TypeScript out of the box, because we think it deserves first-class support.

I think another key evolution that we'll see in the coming years is I think runtimes. Node led to this explosion and all this innovation with all these different tools, and I think that was necessary and quite important, but it also leads a lot of fragmentation in day-to-day workflows.

And so I think we'll see consolidation with these batteries-included runtime, and we can see that here with Deno and Bun, for example, which include built-in watching, linting, formatting. I think runtimes will essentially kind of tend in this direction. Obviously, Deno's current implementation isn't perfect, but we'll continue working on it and improving it.

I think one of my last points is Node is currently the dominant JavaScript runtime. Deno is kind of the underdog. It's up and coming and growing, and I think these two runtimes will converge. How they converge is still open and undecided. But I think we see different trends. We saw that the webification of these runtimes are embracing web APIs more and more, which kind of gives them these shared APIs that can both build off.

Deno has Node compatibility that can run non-trivial applications, such as Express, Coa, front-end tools like Vite. It can run package managers like NPM and Yarn. Node compatibility hasn't officially shipped yet, and my colleague Bartek has given a talk about it, but it's really getting quite powerful. And also, Native is evolving. We're evolving beyond add-ons to Wasm and NAPI. And Deno will, you know, we're experimenting supporting NAPI and Deno out of the box.

So, I think there's a lot of room for Node and Deno to converge. I think the main driver there is fragmentation for developers. It's just not fun. It's not great. So, you know, it's one of those things where we'll kind of wait and see what happens there, but I'm looking forward to it.

So, moving on from CLIs, let's take a look at Clouds and Cloud Runtimes.

You know, I think some of you may be familiar with IaaS or infrastructure as a service, which is kind of what AWS defined. And so I think kind of Clouds in the past decade have mainly been defined by AWS, Azure, JCP and kind of those- the commodification of primitives such as compute and storage. And, you know, I think in the coming decade, we'll see infrastructure as a service become isolated as a service. And I'll get a little bit- I'll dive into what I think that means in a few slides.

You know, if we take a step back and kind of look at hypervisors that are used in the Cloud, you know, traditionally we would have VM hypervisors. And VMs are- they're extremely flexible. You can run any operating system, but they're quite expensive. They take seconds to boot, right? You know, and in recent years we've seen, for example, firecracker VMs, which are also technically VMs, but they're much lighter weight. They don't try to emulate a full machine. They still build off KVM and other key technology. We've also, obviously, seen the emergence of technology like, you know, LXCs and Docker, essentially containers, right? And so the hypervisor there, the dominant hypervisor is Kubernetes. And so, you know, containers are less secure than VMs, but there's a ton of improvements in DXs and kind of, you know, boot performance that make these appealing. And I, you know, and I think the last evolution in these kind of hypervisors is- that we're getting to now is these isolate hypervisors. You know, instead of having hypervisors that juggle VMs, we're getting hypervisors that will manage isolates, and these are much, much, much, much more lightweight. You know, they boot an order of magnitude faster than both containers and VMs. And there's a lot of interesting primitives that we can- and things that we can enable if we embrace isolates first.

And so, you know, if we take a step back at one of the things, for example, that can- if you think about isolate hypervisors and modern isolate executables, I think there's this interesting idea of declarative entry points. And so, for example, we've seen Cloudflare ship this, and this is something we're actively thinking about at Deno with Deno Deploy. You know, this essentially allows you to declare a program declaratively. So, instead of having essentially all these declarative imports, you will have- and then having an entry point that is imperative, that, you know, extracts arguments from argv or sets up a listener. You essentially export functions, and that has a lot of interesting benefits. You get- you can expose multiple entry points in a JavaScript file, so a single JavaScript file is now self-sufficient to describe a full program. And then it encourages kind of, you know, this JavaScript first, and it's composable all the way down via imports and exports. Like, this doesn't have to be an entry point. You can just re-import some of these functions and rewrap them again, so you can get this nice pure JavaScript composability. Another thing that's enabled by, you know, these isolate hypervisors is you get these things such as, like, for example, when we build traditional clouds we often have multiple services called microservices and we'll have to talk to them, and these- that will often happen over the network, right? It will be a HTTP call or a TCP call. And I think one of the interesting things is when you have the isolate hypervisor that manages all these run times it can actually, you know, instead of sending these calls over the network, it can send them directly through memory. And so you get these really interesting gains in efficiency and things that aren't really possible in these classical abstractions because, you know, we were- in the classical VM setup or container setup we're still working with IP stack as first class citizens. Whereas here, you know, you have essentially got a fat hypervisor that profoundly understands these isolates and knows how to route between them. So, yeah, when we think about isolate hypervisors, I think the main argument is there's these extreme efficiency gains.

When you're trying to run, you know, hundreds, thousands or tens of thousands of multi-tenant programs on the same machine, that's not really possible or viable with VMs. It's not possible with containers either. Only isolates kind of have sufficiently low overhead to enable a kind of multi-tenancy. And, you know, I also think when we look back at kind of the cloud over the past decade, it's essentially, it preserves some of the key abstractions that we've been working with that have served us well, but are maybe a bit outdated, right? And so I think these modern isolate clouds will embrace isolates instead of VMs as their compute primitive. Instead of having, you know, internal IPs and VPCs and private networks and NUTS that replicate, you know, traditional infrastructure, you have directly routable isolate services where you don't care where the other service is running. It could be running elsewhere in the world, it could be running on the same hypervisor machine, it gets routed. And then, you know, there's the emergence of kind of blob and KV stores to replace block devices. And there's opportunity for these hypervisors to be as native, such as we're seeing in Cloudflare Workers or Deno Deploy. And so, I mean, you know, with these isolated hypervisors, which are essentially kind of the implementation of the runtime, I think we'll see the emergence of a Cloud Workers spec, right? Service workers were a good starting point, but AddEventListener Fetch is outdated, it's not the future. Cloudflare still supports it, Deno Deploy still supports it, but we know that we need to go beyond that. And, you know, I think the key thing here is in these Clouds, we're no longer just packaging node and containers. It's truly new primitives and, you know, a new process model, and that potentially warrants a new spec.

So moving on from the Cloud, and there's tons more to say, but unfortunately I only have a little bit of time. So let's take a quick look at some of the more exotic use cases that JavaScript could break into or how JavaScript runtimes could evolve. I think, you know, we can see this is not a new topic, but I think it'll be revisited. We see kind of JavaScript producing WASM or JavaScript being compiled ahead of time. So you see this both assembly script or Microsoft static type script. I think we'll also kind of see JavaScript runtimes embedded in more and more applications. Deno is built to be highly embeddable. We've seen people take Fabrice Billard's quick JS runtime and run that in WASM. So you get JavaScript in WASM, hooked into a JavaScript runtime, which is quite interesting. And so I think in the kind of coming decade, there's the opportunity for JavaScript to be embedded into more and more portions of our infrastructure. Cloudflare brought JavaScript into the CDN essentially. I think people might bring JavaScript into databases or other key parts of infrastructure and make that scriptable.

I think one of the key changes in, I think, programming and software in the past decade is machine learning. It had an undeniable impact on how we build software and the products we consume. And DNO, for example, has first class support for Web GPU. And if you combine that with TensorFlow JS, essentially you have the possibility to have GPU-accelerated training and inference. It's natively supported in a runtime. And obviously that's Python's bread and butter today, but I think it would be interesting to see JavaScript gain some ground there.

And so, though it's not as extreme as machine learning, Python is the de facto language for data science. And I think there's room for JavaScript there. At DNO we've experimented with first class support for Jupyter Notebooks. And allowing you to write TypeScript in these Notebooks and have charts, and all that kind of just seamlessly built into a coherent experience.

Yeah, so, unfortunately I don't have so much time, so I'll have to wrap up. But I could have spent a lot more time, I think, going into detail about the cloud side of things and these Isol hypervisors and what they enable and the future of that at Cloudflare and with DNO deploy. But to leave you some closing questions, the web currently handles about 150 million requests per second, HTTP requests per second. And I think it's interesting to wonder what fraction of that will be processed by some JavaScript runtime, whether that's Node as the upstream origin or whether that's AWS's Cloudfront Edge, Lambda, Cloudflare Workers, DNO Deploy, I think it'll be interesting to see, essentially, will there be a future where 50% of all HTTP requests go through JavaScript at some point, whether that's for an edge router or their upstream. I would also like to ask you, do you think JavaScript is too fragmented? Do you want this consolidation? Do you want this consolidation in formatting and bundling tools? Would you like to see JavaScript expand beyond development? What are your use cases? Would you want to use JavaScript for microcontrollers, for game development? Yeah, I'd love to hear about these use cases. And then, you know, I think lastly it's important to really consider TypeScript. Will TypeScript become the de facto language used for all JavaScript development in the future? I think it is a good shot. Anyway, I'd like to thank you all for taking the time to watch my talk and attend today. We're going to have some time for questions and answers. I'm very much looking forward to that. Here's where you can find me online. Feel free to shoot me an email or ping me on Twitter if you have any questions. And that'll be a wrap. Thank you very much, everyone. So now let's discuss the answer to your poll questions. Let's see what the people So which platforms running on the edge have you used? 40% have used Cloudflare workers, then 25% Lambda Edge, and 15% and 15% Versa and Dena Deploy, and 5% Netlify Edge handlers. What do you think about this, Aaron? Like, this surprised you, or this is what you expected? Well, I mean, in some sense, I'm not surprised and it kind of reflects a lot of my understanding, right. Cloudflare has really, I think, changed the game and people's perception of these modern kind of worker runtimes. They've done a great job at that. I think they've done a fantastic job.

You know, Lambda is AWS, which a lot of people use more or less indirectly. And then, you know, it's interesting to see DEM deploy, which is the product I work on. It's got a decent amount of usage. We're still in beta, obviously, but it's good to see traction there. So, yeah, I mean, I'm pleased to see this. And, yeah, I mean, I think there's a lot to, you know, we could maybe even talk about, like, the differences between these edge runtimes. They all run JavaScript ultimately, but there's kind of different trade-offs in each of those runtimes.

Thank you. Let me go back to… So, yeah. And now let's see some questions that people have asked you. So the first one is why would you isolate clouds, replace MVContainer clouds if they're less flexible and can only run JS and ones? Yeah. That's a great question. Yeah. The short answer is containers and VMs will be around for a long time still, right. But I think isolate clouds will replace a lot of typical usage of containers and VMs for JavaScript, because they're much, much, much more efficient, right. There's a huge gains in efficiency. Cloudflare has talked about some of these. I mentioned some of these in my talk, right. Where you have like zero costs, inter-service networking, much more memory efficient, they can be much more compute efficient. And I think the more interesting thing is that these isolate clouds can enable you primitives, things that weren't simply possible before, right. So they're not going to completely replace each other. But I think this decade will see a huge boom in people switching over from classical VMs and containers to isolates. They'll be the best place to run JavaScript.

Thank you. James, James is asking, any known plans or rumor for AWS to support an official Deno runtime for Lambda? Yeah, I think this actually came up in the Deno room earlier. So there's currently a community Lambda runtime for people to run Deno on Lambda. I think after this conference, I'll look into if we can talk with AWS and maybe put together an official Lambda layer. That's definitely something that's interesting. I think the Deno company, we want to embrace people to use Deno everywhere they can and want to, whether it's on AWS or on Deno deploy or Digital Ocean or other providers. So we'll definitely look into that.

Thank you. That sounds promising. Like, yeah. James has now talked about a standard JS lib, is that how you think Deno and Node will converge, or do you expect one runtime to replace or the other in the limit? Yeah. That's a great question and a difficult one. I think think the fragmentation is painful. So Deno and Node might not be able to coexist forever in the limit. I think five, 10 years out, they'll either merge in some form or one will replace the other. But I think, to James's point, over the past decade, we've seen a lot of expansion and innovation in JavaScript. And I think we're entering, going from an expansion phase to a consolidation phase. And I think a standard JavaScript library that share pre-knowledge on time is a great idea. So I think they'll converge there first before possibly replacing each other, I mean, one or the other.

Yeah. Yeah, thank you. So you said that Unix primitives might be obsolete in modern isolate clouds. Can you elaborate on that, please?

Yeah. So I talked about this idea of isolate clouds. I really think there's a lot more to say about this. Maybe I should make that a focus of a talk, right? But the Unix primitives such as the file system of processes and sockets, they've lived with us for a long time. But I mentioned, for example, this feature that Cloudflare has of zero cost interservice communication, in a classical setup, you would need to do service discovery via DNS or some kind of console service. And then you'd have to find out what IP is this other service running and then open up a socket. I think these isolate clouds, because they're much more involved in some sense with the isolates that are running, they'll provide a lot of these primitives out of the box. And when you're building applications that run around the entire world, it doesn't make sense to program for an individual process when you're building something that runs worldwide. So I think the Unix primitives have been great. They've served us well. And they'll take a long time to disappear. But I think as we start building these modern JavaScript applications for the cloud, we'll see them phase out and we'll see new primitives emerge. And that's maybe things like first-class blob storage, or KV storage, as Cloudflare shipped KV storage. We were looking to ship that to at dealdeploy. And I think today a startup called temporal.io raised a $100 million Series B, which is quite substantial. And one of the things that they change is they change the whole queuing cron task mechanism to reinvent those primitives, in part because they're moving beyond the Unix restrictions. So it will be a big shift because developers care a lot about Unix. But I think we need to shift beyond to build programs in a more modern fashion.

Very, very interesting. AgentRL1990 asks, compute keeps moving closer and closer to the client, do you feel that someday we will move to a stateful connection in the far future of the web? A stateful connection? I'm not exactly sure what they mean by that, a stateful connection between the cloud and the client. That could be interesting, but I need to kind of understand it a little more specifics of what they mean by stateful connection. Oh yeah, well maybe we can talk about that in this court with AgentRL1990, in a spatial chat. Yeah, in a spatial chat we can talk about that. So thank you, thank you Aaron very much. This was a great talk and great questions as well. So yeah! All right, well thank you everyone for attending. I appreciate your time. Yeah, see you all in the spatial chat.