Erick Wendel:
The whole summary of building a real time from JavaScript is for developer experience, making things human-readable.

Noel:
Hello and welcome to PodRocket. PodRocket is a web development podcast by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking and product analytics. You can try it for free at logrocket.com. My name's Noel and with me today is Erick Wendel. Erick's a Node.js core team member, entrepreneur, professional educator, Microsoft MVP, Google Dev expert, the list probably goes on from there. He's here to talk about his conference talk, Recreating a JS Runtime from Scratch, Understanding the Magic Behind the Node Core. Did I get all that right, Erick?

Erick Wendel:
Yes. Yeah, I'm pretty excited to be part of this, showing some of my research, some ideas and some curiosities about Node.js in JavaScript, how it works behind the scenes.

Noel:
Can you tell us a little bit about yourself and your background and why you're suited to delve into this topic?

Erick Wendel:
Sure. I've been working... Actually, I've been teaching and giving talks since I was a beginner in software programming, so my way to learn programming was trying to share everything I was learning. Since the pandemic, I start working on my own company, try to sell courses, try to make more quality content. And I've seen that we have a lot of content on internet, but sometimes I feel that we have a lot of very similar contents. But very deep or very specific content, it's very hard to understand. And most of the content I will talk today is not on ChatGPT. It's so specific that there's not much information on the internet about it. So I think you're going to like a lot. So I've been working 100% of my time now producing content on YouTube, Instagram, writing posts on my social media, too. And always trying to get those mad science ideas. Oh, how could we create a DB driver? How can we recreate Node? How we can implement web sockets and so on?

Noel:
Let's get right into it and let's talk about what your talk covers. Yeah, so it's titled Recreating a JS Runtime From Scratch. Could we maybe spend a little bit of time defining some terms, especially for those that maybe they write a little bit of JS as part of their job, but it's not where they're spending most of their time or their cycles thinking. Maybe what is a runtime? How does that interact with a JS engine and why are their performance gains to be had there, Erick?

Erick Wendel:
Well, this content is based on a YouTube video I made, showing the step by step, doing the same thing. It's going to be great to follow along. But part of my research here, I noticed that we have two similar concepts and actually, they mean the same thing at the end, which is the runtime. The V8, it's the Chrome V8, is the engine that is running on the browser there that usually we heard that people say, "Oh, we use this to interpret and to execute JavaScript." Although if you create an application, let's say RS or a C++ application that receives a string and sends to V8, this is also known as JS runtime.
Even doing those proxies, they are meant to be runtime, and that's how Node.js was made, Deno and all the other competitors. On your Node.js project, you execute Node, which is a C++ program, and then you can pass the file name, by example. So you have Index.js. So internally, this C++ program will go to the operating system, read the whole string and send to the V8 API, which is the Chrome, which is a C++ binary that you can compile yourself and execute on mobile devices, desktops, or even on the web right now with web containers, which is a pretty nice idea to search on more later.
So [inaudible 00:04:15] prep, the JavaScript string we sent to V8, which is executing on browsers and other runtimes I would say. But the magic behind the scenes is how we can establish a bridge between the JavaScript and the C++ land. Imagine JavaScript cannot read a file. JavaScript, or let's say a very cool thing, JavaScript doesn't have console.log is not JavaScript. setTimeout, setInterval, they are not part of the JavaScript specification.
When you call those functions, we are actually parsing or mapping or when I call this string or this function, you go to the C++ and define this function and call from the C++ land. On the browser, it's how Chrome is doing behind the scenes. On the desktop, we usually have the operating system, the APIs on Mac, on Linux and so on. And on mobile devices you have the native APIs like Android and iOS. It's a brief idea because there are a lot of things there.

Noel:
Yeah, so to summarize, you're saying the engine, so V8 for example, Node that's less about how things are interacting with the outside world and more about the core of the actual running code. Is that accurate?

Erick Wendel:
I would say it's more like I define as a proxy, but I would say it's a poor term to a proxy because there are a lot of things happening there. But when you are working on the Node.js core, when you are establishing API there, we don't parse the JavaScript language. We don't know what is a verbal, or in the end for us is V8 trying to convert your JavaScript classes to C++ instances so you can go back and forth searching ideas? The whole game of performance right here is instead of running a loop or instead of running some heavy algorithm in JavaScript, I can delegate your C++, use all the threading or the whole ecosystem that we are running on the environment and then call back the JavaScript with the information faster.

Noel:
So why do you think people are talking about this more now? It feels like for a while, nobody really cared about this, everyone just used Node on the server if we were going to. And then you assumed that the browsers were just going to handle this for you. Why has this entered the headspace of the developer ethos?

Erick Wendel:
Well, I would say in technology we have cycles. Node has more than 10 years right now. But since then, we've seen a lot of other runtimes, but they are not so popular. But as Rust came and it seems everyone is falling in love with Rust, they are trying to recreate tools using this. And then they realize, oh, maybe actually, I think Mozilla is the company behind it and they are making the runtime. I'm not sure, but I think the runtime on Mozilla is based on Rust. Even calling SpiderMonkey, which is their V8.
Speaking about Deno and Node.js and Bun, we have two people. People sometimes are afraid, "Oh my God, I spend so many time learning Node and now I will have to change". And others are like, "Oh, let me experiment here and let's see each of the words." When we are working with Node.js right now, as we have 10 years of maturity and even so, we cannot break changes now. It's too impactful, it's too risky to implement some crazy idea there. With Deno, I saw Ryan Dahl's talk there, I think it was 10 Things I Regret About Node.js. And he was trying to fix this using Deno. One of them was TypeScript, and in my opinion, Deno is not about runtime. For my opinion, it's developer experience. When you have [inaudible 00:08:21], when you have more APIs, Deno was born with testing APIs right on the core. In the Node.js core, we just got it a year ago. They born with URL in ports. Now you can send a URL, import your module and you don't need to depend or rely on NPM or a third company there to download your modules.
But because Deno did this, Node.js did as well. But actually it's part of the [inaudible 00:08:50] description modules and specification, but I would say it's cycles. But one of them like Bun one of the main runtimes now, I wouldn't say the main runtimes because they're going hype right now. We don't know much how they're going to be in the future, but Bun has a very similar idea of both of them, but they are using Zig, which is a very rare or very specific programming language I've never seen before. When I was looking at the docs was very, "Oh my God, what is this?" And because of the language and this whole ecosystem they are doing there, they can parse informations faster.
This is something that people say, "Oh, but if it's just a proxy as you're talking, it's just a JS code that is trying to map to C++ classes, there's no difference." It could have been in any of these platforms, but the thing is when I'm receiving data and consuming data from the operating system, each of those runtimes can consume faster, can use a different approach to break cryptography or read buffers. And this is how Bun now says that he's the best in the performance side right now. It's pretty interesting to watch how is this whole scenario changing? But in my opinion, in the future we are going to have only JavaScript and the cloud computing or whatever platform you choose to deploy application is going to choose either Bun, Deno, or Node.js.

Noel:
Hopefully, again, devs won't have to worry about it too much unless they care about it for some reason. That's always the ideal. Yeah, perfect. I guess with that in mind, who do you think should be listening to this talk, following along? Who would you recommend go through the exercise of creating a runtime from scratch?

Erick Wendel:
Well, I would say curious people. Right now with ChatGPT, I've been asking a lot of questions like, "How can you create a code coverage too? Or how do you create a DB driver? Is it magic? How does it happen?" So if you're a curious person, this is pretty nice, but it's still people who are in masters or post-masters doing some research and experiment with other programming languages as well. Because right now in the Node.js Corps, because of all this runtimes appearing, we have a working group that they can share information with each other and they are trying to collaborate and sometimes people say, "Oh, this specific part in OJS by example was the URL. The URL, it's built in JavaScript, but if we move to web assembly it could be faster." And then someone tried to do this in Rust because in Rust you can compile a code that you can actually read a binary package there and execute from Rust as well.
But in the end, it wasn't faster than JavaScript, it was crazy nice. So we were making a lot of assumptions, but when we are experimenting and when we are trying to do some proof of concepts, in my opinion, my personal as a developer, as a just curious people, I saw a lot of people saying, "Oh, the libuv does this, the Node.js does this and this is the part." But when I got to the code, when I was able to run my Deno, a lot of things I was like, "No, this is not true. See here, this is not how it works." In the end, Node.js is not single core, it's just one piece of the puzzle. So we have multi-core since the beginning 2009 when it was built, and actually my opinion is when you learn the behind the scenes of some technology, this gives you power to troubleshoot when you have some performance issues, some memory leaks, and when you are discussing with your team, you could be the reference when speaking about this.

Noel:
Just a quick pause here to remind you that PodRocket is brought to you by LogRocket. LogRocket can help you understand exactly how users are experiencing your digital product with session replay, error tracking, product analytics, frustration indicators, performance monitoring, UX analytics, and more. Machine learning algorithms service the most impactful issues affecting your users so you can spend your time building a better product rather than hunting through tools. Solve user reported issues, find issues faster, and improve conversion and adoption with LogRocket.
I think that is the case a lot of the time it's having that knowledge, even if you're not using it or it's not impacting the code that you're writing day-to-day, when there are bugs or you're making some decision that does seem it's on the periphery, on the membrane of how things are going to work. "Oh, I have a better grasp of how things are probably working under the hood so I can suss out where to start debugging these really odd, hard to track down issues." Nice. That makes a lot of sense. So you touched there on the history a little bit, talking about threading and cores and all people assumptions people have about Node that they've had forever. Could maybe talk a little bit about the origins of Node and how we wound up where we are today or with Node as the industry standard for so long.

Erick Wendel:
Sure. Actually, I started programming as a C# developer.

Noel:
Oh, interesting.

Erick Wendel:
And it was, I would say, 2013 or 2014 maybe. And it was really hype and JavaScript people were saying about JavaScript is not a serious language. Nobody who's any production code is going to make with JavaScript, but it was 2013. In 2009, there was someone trying to actually execute JavaScripting the server. So during my research I was going through the whole Node.js project so anyone can go there and select the View one branch and notice how Node was. And this experiments, this video I built, it's very similar on what Node.js was doing there. So back then I think it was only Ryan Dahl in the first versions and the comments, they are hilarious. So it's like, "Oh, it's working. Oh, it's not working anymore." So it was very nice. But back then it was just you get a JavaScript string to the V8 side, and on the V8 side, this is what we call the bridge.
When I was researching this seems to me like, "Oh my god, this is so hard to understand." But what is this thing? In this C++, imagine that you can have a file in a bunch of exports. I'm going to say this train, like console.log, console.log is the print F on the C++. So there I export an object, which is the console, and then I will put a V8 object there with the log function and then the V8 size makes the whole magic. It looks like when you are extending something, so you get the V8, the raw V8, and you start injecting more and more functionalities there. So from JavaScript, when you call some functions, when you have the object, the globals, the environment, you can have like, "Oh, this function doesn't exist on the JavaScript specification. But in C++, if I try seeing all the exports there, we are going to see all of this."
So when Node was built, I saw the print, so they actually exported the print function. And from JavaScript you could say, "Oh, the console.log will actually save the print with the STD out. Oh this is console. error. So it's print on the STD error, it's not console. Error." So the whole thing right now, I think from back like 2009, what we have now is I would say the whole summary of building a runtime from JavaScript is for developer experience. Making things human-readable. It's not about, oh, let's make this performance, this is actually my opinion doing all this research. I always rephrase this because I know most of people have different ideas and Node, since the beginning, it's crazy to see how the performance was increasing, increasing. And even now with all those competitors, it's really nice to have a working group focus on performancy right now. But yeah, the whole point for me is to make humans to program faster and easier without having to know much about computer science concepts or knowing memory handling, all this stuff. They are just trying to abstract all the complexity so you can build faster.

Noel:
Would you say that creating a runtime, would you recommend that to someone that's just starting getting into development in general? Or would you say go to some more Hello, World's build-a-web app or something first and then come work on the runtime?

Erick Wendel:
Well, I would say this is something that my friend said, this is not something that people do. Like my case, this video I built with the whole tutorial was the first on the internet. So I had to make some meetings with people at Google, from people from the libuv to understand. So it's not something that I would say it's only you and Google you can do. Sometimes I was reading the testing the whole search code at V8 to learn how it was working, but I don't recommend people recreating from scratch. But I recommend people doing tutorials.
In my case, I did this tutorial for you, you can go there and learn step by step, but when you try to do, I've spent two months at least trying to build this thing and I would say a month was just trying to compile and to fix the environment. I think most people would give up just because the environment. But still, if you are a developer and if you are a curious people independent of your level, it's always nice to recreate something. Recreate your browser, recreate your application, recreate Docker, and it always gives a lot of cool insights for you and some assumptions that you're going to break.

Noel:
I feel like it's a humbling and exciting experience as well. A lot of the time it's like you walk away with an appreciation for how complex all of the stuff we just do every day and take for granted is. I appreciate people who are in the space trying to help build that appreciation because I feel like that helps us all communicate.

Erick Wendel:
Two weeks ago, I was wondering to make a similar video building a React Native application. So I was like, "What if I try to do the multi-platform?" So I want to deploy when I call alert, I want to see the toaster on iOS, the toaster on Android and so on. But it's so complex because you have to know Java or native APIs from Android, the iOS there, the native API there. And sometimes I was remembering people say, "Oh, you shouldn't use Ionic framework because they are on a web view," or, "You shouldn't use Flutter." When you realize the complexity and how amazing are those people who are abstracting this. Developers, sometimes we users, we are making more money than the creators, the builders there because sometimes they don't get enough for building this. So I would say now learning more the deep stuff, I'm more grateful than I was just reading about it.

Noel:
I guess, is there anything in the talk, in the video specifically that you might, I don't know, mention or talk about briefly here without going into all the details that might be particularly interesting or insightful to devs who are like, "I have a million tutorials I'd like to go through but the backlog is long." How would you entice them to it?

Erick Wendel:
Well I would say from this experiment was how libuv works. I would say libuv actually was made for Node. It was primarily a C++ library for handling events, but it was only working on Linux, and then those people built the library to work multi-platform. But it's so powerful and sometimes people say, "Oh, I wouldn't use JavaScript because it's not multi tread, because Java handled this better." But libuv, the way they are handling events, they make us spend less money, it's much cheaper than a lot of other tools. You can use very small servers and the architecture is beautiful. And when I was searching, oh, but why is it blocking? The blocking part is when you are trying to evaluate your JavaScript code. When I have a [inaudible 00:21:52], I have to inspect this instruction. The V8 does this job, but the time to inspect this instruction and execute it is what breaks everything.
So libuv is actually calling APIs from your operating system, is executing everything asynchronously. But when you have a JavaScript code and you have to make this bridge, I will say I have to execute the JavaScript code first and then I have to get all the async operations, like setTimeout, I have to schedule them and then when they are ready I'm going to call back the JavaScript code. So everything is so fast, but building that specific part, evaluating, you can imagine this process at V8 when you use the evolve on JavaScript. You pass a string and you wait for the result. For me it was so amazing. I was like, "Oh my God, it's just this small part." Again, it's a small part for me as a web developer. If I go to the compilers, if I go even beyond, it's crazy that this is because a lot of people there are compilers expert, but it's beautiful. It's beautiful. I was like, "This is the piece of art."

Noel:
Yeah, no, I think even just in our brief conversation here, I feel like I've got a slightly better grasp. The parsing and the reading in is the part of JavaScript that is blocking and I think your eval analogy is a good one to help connect those dots for people. Very cool. And again, I don't want to get into the details of the talk because I feel like it might be a little bit dry for people to listen to, but yeah, it sounds pretty cool. Is there anything else in there that might be a good hook for people?

Erick Wendel:
I think one last topic, and this was where I stopped, it was breaking change for me and I wasn't able to go through. So threading, when we are working with threading, it's another world for me because it's like traffic. You have signals when they said, "Oh, you should go on and we cannot have two people at the same thing, two cars accessing the same way. We have to have an order." And this was crazy for me to understand, but I was like, I want to make what Node is doing with worker threads, or workers as the browser. And when I was searching at the Node.js core code, it was crazy. V8 is so fast and so small that instead of trying to create more context there,, they are trying instantiating a new version of V8. It's so small that you can recreate the whole thing. Let's recreate the compiler, the interpreter and actually share memory and make everything there. But it was so amazing.
But why I say I stopped there, because there's no such content on the internet. I was talking to Googlers, to people at V8, at people at libuv and they were like, "I have no idea because I've never done such a thing here." And it's so specific and sometimes when we were talking about all the stuff, remember that I said that the libuv, we have the events running there in this part to sequentially dispatch the events is single threaded. But then you have to remember that sometimes I have timers that could spend 10 seconds long on the loop if you want. You can set a time out there with 10 seconds.
So you have to start it in memory, you have to synchronize it, and when you receive a call back, you have to remember which is the reference to call back and resend this message again. So when you're going deep and deep, you see there are a lot of concepts there that you cannot find on the docs. So if anyone from Google from V8 is listening this now, please we need more tutorials there because it's so amazing the job you have done there, but there's not much information about this. So for me it was pretty hard, and even with ChatGPT, I was asking ChatGPT, how can I convert this variable? I copy paste and it wasn't working because there's not much information about this.

Noel:
Thank you so much for coming on and chatting with me, Erick. Is there anything else you'd direct listeners to, again? I guess is the talk public, will we able to get a link to that in the show notes?

Erick Wendel:
Yes, actually we will have a talk, but the talk is going to be 30 minutes long, but I have already the YouTube video that I showed you, I built the whole environment on a Gitpod. So you don't need to compile the binaries you want, you only care about the C++ code, so you can find there on my YouTube channel. And stay in touch because we have in person talk, so if you are listening right now and you want to grab a coffee or a beer for me later, let's talk because I am really passionate of this tech in this scenario that we are living now.
So I could spend hours with you speaking because it's amazing how it's growing fast, but it's still... My opinion, the best programming language in the world is C++. I'm not a good at C++, but imagine the web assembly that we are in 2023 is using C++ programming in a lot of stuff that was built in like 1980s. So it's crazy. So for me it's something interesting. How could they build something so good for so long time and we are still using it in a performance way, in a good way and such a way that people can reuse and make money with this?

Noel:
Yeah, no, for sure. Yeah. It is always crazy how many tiers of things we've just built upon and especially you get down there and, "Hey, nothing here has changed in so long." It's always humbling and impressive to see it happen. Cool. All right, again. Well, thank you so much Erick, and we'll get links to the video and your YouTube channel in the show notes so people can go check out more. But yeah, thank you so much for coming on.

Erick Wendel:
All right, thank you so much. I hope to see more and more content about this, more people speaking about runtimes. For you who's watching now, go search, try learning what your tool is doing because it's not magic and it's not just there. Someone spent a lot of effort doing that and it's nice to give back. At least rich people on Twitter say, "Oh, this tool you made was amazing, it help me a lot because this is how our open source and our technologies grow."

Noel:
Yeah, yeah. Awesome. Awesome. Thanks again.