AI Generated Video Summary
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.
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.
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.
They don't want to wait for their linter. They don't want to wait for their formatter. The introduction of Node add-ons have evolved to an API, and there is a wrapper called NAPI.RS, which allows you to build API modules in Rust. Node 18 is shipping ECMAScript modules, HTTPS imports, and Fetch. Deno considers web APIs as first-class citizens and aims to be spec compliant. Deno is more spec compliant than some browsers. TypeScript will become the de facto dialect. The TC39 organization is considering ignorable typing for executing TypeScript out of the box.
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.
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. Another evolution is JSX has changed the way we build frontend. It's essential today. TypeScript is no longer the underdog and supports TypeScript out of the box. Runtimes will tend towards consolidation with batteries-included runtime. Node and Deno will converge, embracing web APIs more and more. Deno has Node compatibility and is evolving beyond add-ons to Wasm and NAPI. There's room for Node and Deno to converge, driven by fragmentation for developers. Let's move on to Clouds and Cloud Runtimes.
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.
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.
7. Clouds and Isolate Hypervisors
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.
8. Isolate Clouds and the Future of Cloud Workers
When running multi-tenant programs, VMs and containers are not viable due to their overhead. Isolates provide a low overhead solution for multi-tenancy. Modern isolate clouds will embrace isolates as their compute primitive, with directly routable isolate services. Blob and KV stores are emerging to replace block devices. Isolated hypervisors, like in Cloudflare Workers and Deno Deploy, may lead to the emergence of a Cloud Workers spec.
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.
Lambda, Isolate Clouds, and Deno Runtime
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.
Convergence of Deno and Node
Unix Primitives and the Future of Isolate Clouds
Unix primitives may become obsolete in modern isolate clouds as these clouds provide many of these primitives out of the box. Building worldwide applications requires moving beyond programming for individual processes and embracing new primitives like first-class blob storage and KV storage. The reinvention of queuing cron task mechanisms by startups like temporal.io indicates a shift away from Unix restrictions. The future may involve a stateful connection between the cloud and the client, although further clarification is needed. Thank you for attending the talk and see you in the spatial chat!
Yeah. Yeah, thank you. So you said that Unix primitives might be obsolete in modern isolate clouds. Can you elaborate on that, please?
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.