The Future of JavaScript Runtimes

Rate this content
Bookmark

JavaScript was born in the browser, Node brought it to the server embracing unix primitives and async I/O and lately Cloudflare Workers & Deno Deploy have brought it to the edge. Let’s take a look at where JavaScript runtimes are heading and how it will shape the software we write.

34 min
17 Feb, 2022

Video Summary and Transcription

Today's Talk explores the future of JavaScript runtimes, their evolution, and impact on software development. It discusses the historical trends of JavaScript, the adoption of new tools and libraries, and the convergence of Node and Deno. The emergence of isolate clouds and their potential to replace traditional VMs and containers is also highlighted. Additionally, the talk touches on the possibilities of JavaScript in exotic use cases, its impact on machine learning, and the potential for TypeScript to become the de facto language for JavaScript development.

1. Introduction to JavaScript Runtimes

Short description:

Today, I'm going to talk about the future of JavaScript runtimes, how they have evolved, and how they will shape the runtimes of tomorrow. It's an interesting exercise to explore the possibilities and open up a conversation about innovation and progress in JavaScript.

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.

2. JavaScript Runtimes: Trends and Evolution

Short description:

Today, we'll explore what JavaScript runtimes will look like in the future, their new capabilities, use cases, primitives, and ergonomics, and how they will impact software development and deployment. I'll provide my personal views as someone new to working on JavaScript runtimes, with a focus on the CLI and cloud. We'll also discuss the historical trends of JavaScript, including the creation of JavaScript in 1995, the introduction of V8 and Chrome in 2008, and the impact of Node in 2009. Another significant event was the release of TypeScript in 2012, which is now widely used. These trends give us insights into the evolution of JavaScript in the coming decade.

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.

3. JavaScript Front End and Runtimes Evolution

Short description:

Before 2010, front end development relied on libraries like jQuery, but now we have React, JSX, Vue, and modern tools like Babel, ES Build, and Webpack. TypeScript and serverless architecture have also become widespread. JavaScript has undergone significant changes, including the adoption of Yarn, promises, React, ECMAScript modules, and fetch. While the core language continues to evolve, this talk will focus on JavaScript runtimes and their evolution. JavaScript was born in the browser and later incorporated Unix primitives through Node. The question now is whether we should introduce new primitives for the modern cloud.

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.

4. JavaScript Runtimes: Browsers and CLIs

Short description:

JavaScript has evolved over the past 20 plus years, and we have the power to shape its future. Browsers have seen notable improvements, such as the invention of web containers that allow running full Node-like applications in the browser efficiently. Moving on to CLIs, we can expect more core JavaScript runtime technology to be built in Rust, offering safety guarantees and faster iteration. The rise of Rust in tooling, like Rome and SWC, is driven by the need for speed in front-end app development.

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.

5. Evolving JavaScript Runtimes and Web APIs

Short description:

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.

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.

6. JavaScript Runtimes: Evolution and Convergence

Short description:

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.

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.

7. Clouds and Isolate Hypervisors

Short description:

In the coming decade, infrastructure as a service will become isolated as a service. Hypervisors are evolving from managing VMs to managing isolates, which boot faster and enable interesting primitives. Declarative entry points, such as those used by Cloudflare and Deno Deploy, allow for self-sufficient JavaScript programs and composability. Isolate hypervisors can route calls directly through memory, resulting in efficiency gains.

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.

8. Isolate Clouds and the Future of Cloud Workers

Short description:

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.

9. JavaScript in Exotic Use Cases

Short description:

JavaScript could break into exotic use cases and evolve in runtimes. It can produce WASM and be compiled ahead of time. JavaScript runtimes can be embedded in applications. Deno is highly embeddable. JavaScript can be embedded into infrastructure. Cloudflare brought JavaScript into the CDN. JavaScript might be brought into databases and other key parts of infrastructure to make them scriptable.

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.

QnA

JavaScript's Impact on Software and Future Trends

Short description:

One of the key changes in 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. JavaScript has the potential to gain ground in machine learning and data science. TypeScript may become the de facto language for all JavaScript development. Thank you for attending the talk. Let's now discuss the poll results and the usage of edge platforms.

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.

Lambda, Isolate Clouds, and Deno Runtime

Short description:

Lambda is AWS, which many people use indirectly. DEM deploy, the product I work on, has good traction. There are differences between edge runtimes, but they all run JavaScript with different trade-offs. Isolate clouds will replace typical container and VM usage for JavaScript due to efficiency gains and enabling new primitives. While they won't completely replace each other, there will be a boom in people switching to isolates. There's currently a community Lambda runtime for Deno on AWS, and we may explore an official Lambda layer in the future.

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.

Convergence of Deno and Node

Short description:

Deno and Node might not be able to coexist forever in the limit. They'll either merge or one will replace the other. A standard JavaScript library that shares pre-knowledge is a great idea. They'll converge first before possibly replacing each other.

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.

Unix Primitives and the Future of Isolate Clouds

Short description:

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?

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.