<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Mateus Toledo</title>
    <description>The latest articles on DEV Community by Mateus Toledo (@toledomateus).</description>
    <link>https://dev.to/toledomateus</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1401326%2F94e8b17d-7779-4853-ba17-6c6147a9f237.jpg</url>
      <title>DEV Community: Mateus Toledo</title>
      <link>https://dev.to/toledomateus</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/toledomateus"/>
    <language>en</language>
    <item>
      <title>How exactly does NodeJS use the V8 engine?</title>
      <dc:creator>Mateus Toledo</dc:creator>
      <pubDate>Thu, 04 Apr 2024 15:46:42 +0000</pubDate>
      <link>https://dev.to/toledomateus/how-exactly-does-nodejs-use-the-v8-engine-2gfm</link>
      <guid>https://dev.to/toledomateus/how-exactly-does-nodejs-use-the-v8-engine-2gfm</guid>
      <description>&lt;p&gt;When I was learning more about NodeJS and how exactly it works, I was faced with the following question: How does NodeJS exactly use the V8 engine?&lt;/p&gt;

&lt;p&gt;I don't know if you know, but JavaScript is not a language that is compiled to machine level (transforming to bytes) itself. You need to use a compiler to make this magic for you. And that's exactly what engine V8 does. It took (somehow) the JS code and compiled it to your computer run and understand. Now, how it is done?&lt;/p&gt;

&lt;p&gt;Firstly, the runtime needs to interpret what is written in your language and convert it to machine-level language. After, they took this code and compiled it. This process could take a while in some runtimes, and everything has to be optimized as much as possible to be efficient.&lt;/p&gt;

&lt;p&gt;To overcome this problem, V8 doesn’t interpret everything first and then compile to binary. Otherwise, V8 has a Just-in-Time approach. That means it interpreter and compiler line by line at the same time. This saves time and makes the compiler faster.&lt;/p&gt;

&lt;p&gt;Ok, but how NodeJS is involved?&lt;/p&gt;

&lt;p&gt;NodeJS use the V8 engine in the heart of the application to compile all the JS code. But this is not the only use.&lt;/p&gt;

&lt;p&gt;Going deeply, Node uses some of the V8 functionalities such as &lt;strong&gt;Garbage Collector (GB), PromisseHooks, heaps and space statistics, serialization and deserialization.&lt;/strong&gt; Of course, all those functionalities have some Node implementation on top of that to become easy to apply. But if you want, you &lt;a href="https://nodejs.org/api/v8.html"&gt;can access these functionalities&lt;/a&gt;. &lt;strong&gt;For instance, you can access the four lifecycles of a PromisseHooks (&lt;/strong&gt;init, resolve, before, and after stages). As one of the Node contributors (Erick Wendel) said,&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;A lot of NodeJS is nothing more than an extension customized and amplified of V8 functionalities.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;So, NodeJS needs a JavaScript runtime to interpret and compile its JS code. And back in time, the V8 engine was selected to do this job. Of course, some NodeJS functions were built on top of V8 functions and it’s incredible to see how they use these functions.&lt;/p&gt;

&lt;h2&gt;
  
  
  Next steps
&lt;/h2&gt;

&lt;p&gt;If you want to go deeply into your studies, I’d like to recommend some next steps to your studies. First of all, I strongly suggest the article series published by &lt;a href="https://dev.to/_staticvoid"&gt;Lucas Santos&lt;/a&gt; called: &lt;strong&gt;&lt;a href="https://dev.to/_staticvoid/node-js-under-the-hood-1-getting-to-know-our-tools-1465"&gt;Node.js Under The Hood&lt;/a&gt;.&lt;/strong&gt; He brilliantly explained a lot of what was mentioned here and more (for example he talks about how NodeJS does GB). &lt;/p&gt;

&lt;p&gt;Talking about GB, if you want to deeply understand this topic, I strongly recommend this article by &lt;a href="https://v8.dev/blog/trash-talk"&gt;Peter Marshall&lt;/a&gt; one of the contributors to the V8 engine.&lt;/p&gt;

&lt;p&gt;And if you want some hands-on experience to thrive in, please check this tutorial by &lt;a href="https://www.youtube.com/watch?v=ynNDmp7hBdo"&gt;Erick Wendel creating NodeJS from scratch&lt;/a&gt;.&lt;/p&gt;

</description>
      <category>javascript</category>
      <category>node</category>
      <category>v8</category>
      <category>runtime</category>
    </item>
    <item>
      <title>Biggest lesson learned from Nodejs Documentary</title>
      <dc:creator>Mateus Toledo</dc:creator>
      <pubDate>Mon, 01 Apr 2024 19:32:01 +0000</pubDate>
      <link>https://dev.to/toledomateus/biggest-lesson-learned-from-nodejs-documentary-2eb8</link>
      <guid>https://dev.to/toledomateus/biggest-lesson-learned-from-nodejs-documentary-2eb8</guid>
      <description>&lt;p&gt;Have you ever wondered what makes some tech projects keep going strong, even when they face big challenges? Well, I recently watched a &lt;a href="https://youtu.be/LB8KwiiUGy0?si=EwpNjRvr7ahsN7-8"&gt;documentary about Node.js&lt;/a&gt; that gave me a pretty cool insight into this. It’s not just about having a great idea or solving a big problem (which is definitely important), but there’s something else – having a good set of rules for everyone to follow.&lt;/p&gt;

&lt;p&gt;Node.js started off like any other project, trying to solve a specific problem with code. But, the real drama started when some of the main people working on it decided to leave, and the company that was looking after Node.js began to push their own ideas too much. This caused a bit of a stir within the Node.js community.&lt;/p&gt;

&lt;p&gt;So, what did the community do? They didn’t just sit back; they took action by creating a "fork" of Node.js. This means they made a copy of the project so they could work on it in their own way, without the company interfering. This move was huge because it showed that the people actually using and loving Node.js wanted to keep it true to what the community needed, not just what a company wanted.&lt;/p&gt;

&lt;p&gt;The best part? After some time, this forked project and the original Node.js came back together. They merged into one big project again. But this time, they had new rules. These rules were all about making sure the project would keep going strong and stay true to what the community wanted, even if the original leaders left or if a company tried to push its own agenda too much.&lt;/p&gt;

&lt;p&gt;For me, this was a big lesson. It showed that for open-source projects (which are projects anyone can see or change), having a good set of rules is super important. These aren’t just any rules, but ones that make sure everyone in the community is heard, that decisions are made together, and that the project can keep improving and growing without losing its way.&lt;/p&gt;

&lt;p&gt;In a nutshell, the story of Node.js isn’t just a tech story; it’s a teamwork story. It’s about how, when people come together and set up a good way to work, amazing things can happen. It makes sure the project doesn’t just start strong but stays strong, growing and getting better with the help of everyone involved. So, let’s remember: whether we’re coding, creating, or just contributing, having clear, fair rules can make all the difference in keeping our projects and communities thriving.&lt;/p&gt;

&lt;p&gt;Talking about creating a open source project with good guidelines please check my last project: it's a translation of &lt;a href="https://github.com/mateustsleao/the-art-of-computer-programming-portuguese"&gt;The Art of Computer Programming to Brazilian Portuguese&lt;/a&gt;&lt;/p&gt;

</description>
      <category>node</category>
      <category>opensource</category>
      <category>javascript</category>
      <category>backenddevelopment</category>
    </item>
  </channel>
</rss>
