The Problem Node was Meant to Solve
With how much it has found itself incorporated into the web development world today, it can be hard for some to understand what Node is, or what it is intended to do. I know it was tricky for me. It was hard to differentiate it from Javascript itself as creating a web application will typically involve using a great deal of Node-related functions and modules within the actual JS code. Certain frameworks rely heavily on Node functionality; React in particular gets a great deal of mileage out of the module exports feature. It isn’t often explained when and where Node is actually being utilized when these frameworks and features are taught. In my situation, I found myself often left questioning what the point of Node is? What is its purpose? And what separates it from Javascript?
Well, to start, what is Javascript? Javascript is a scripting language that works specifically within web browsers and it is used to create dynamic content. It is quite powerful, easily capable of controlling any and all elements of a web page at the whims at whomever writes the code. Essentially, whenever the web page you’re looking at refreshes or adds/removes an element on it without you having to reload the page, Javascript is responsible.
Web browsers provide a runtime environment for running Javascript code. What this means is that a given web browser takes the high-level language Javascript code and uses its own internal Javascript Engine to convert that code into a lower-level language that a computer can understand called Machine Code. Since a web browser typically comes paired with its own personal Javascript Engine, there are a handful of different ones. Mozilla’s Firefox uses the Spidermonkey engine, Apple’s Safari uses the JavaScriptCore engine, Microsoft’s Internet Explorer and initial versions of Edge use the Chakra engine, but the most widely-used engine is Google’s Chrome V8 engine. It is used in the Chrome browser, Electron, it will be used in future versions of Microsoft’s Edge browser, and various other applications. These engines gave developers the capability to access elements of a web page using the Document Object Model, granting the ability to create new objects on a web page, remove them at will, control their behavior when a user interacts with them in a certain way, etc. The possibilities are endless.
While the use of JS engines makes for a wide variety of experiences in manipulating things that occur within web browsers, there was no way to provide that functionality on a computer or smartphone or tablet system in wider functionality besides using a language native to that system. For example, if you were using Windows, you could use JavaScript to create dynamic content and user-generated experiences to your heart’s content on Internet Explorer, but if you wanted to create a program that ran on a user’s desktop or used the user’s file system in any way, you’d need to use C++ or Java. Javascript was doomed to being imprisoned within the browser window forever.
In 2009, John Dahl was watching a demo of a progress bar on Flicker. A user could upload a file from their computer and a “live” progress bar would display an approximation of how much of the file had been uploaded to that point. But the way this progress bar was done was by sending a request to the server every once in a while, essentially asking “Hey, Server, what percentage of this file have I uploaded so far?” This would happen several times while the user’s image was in the upload progress. Given that an upload would often take a few minutes time, and that the process only allowed for one thing to be done a time, the upload process would go a bit like this:
User starts uploading picture…1% of picture is uploaded…5% of picture is uploaded…Web browser asks server “How much has been uploaded so far?”Web browser waits for server to respond…Web browser receives response and updates the progress bar…6% of picture is uploaded…15% of picture is uploaded…Web browser asks the server “How much has been uploaded so far?”Web browser waits for server to respond…Web browser receives response and updates the progress bar…16% of picture is uploaded…
…And so on.
This clearly doesn’t seem to be an efficient way of doing things. John Dahl’s agreement to this sentiment is what ultimately led to the creation of Node.js:
Node was originally born out of this problem — how can you handle two things at the same time? Non-blocking sockets is one way. Node is more or less the idea, or exploring the idea: what if everything was non-blocking? What if you never waited for any IO to happen?
His solution to the problem was the creation of the Event Loop. He figured it would be faster if the server sent updates to the web browser without the browser having to send requests every so often for updates. So the web browser set up a ‘listener’ for any updates from server, and then it would go about its business. It would ignore that listener until the moment the server sends an update. Once it does, it will reflect that update in the progress bar, and then continue to go forward with the upload progress uninterrupted.
To establish this, he needed a way for information to be sent from the server to the client quickly. He figured the best way to do that would be to have Javascript running outside of the client’s web browser, so that when there is a change in the server, that Javascript program would be ready to send a message to the client’s browser, already formatted in a language it can understand, at the drop of a hat. In the example of a picture file upload, the “server” in question would be the place the picture is being uploaded from: the user’s own computer. So the Javascript application running outside of the browser would keep tabs on the progress of the image upload by reading information via the user’s file system. Once there is an update to be shared, it will send a message to the Javascript running in the user’s browser with the update info. Now not only does the information not have to travel all the way from the client’s computer to some far-off server, making a much shorter journey instead from two parts of the same machine, but now the user’s web browser can focus solely on uploading the picture file instead of making constant requests for updates. This is an example of two separate instances of Javascript committing to their own specific tasks and communicating. This is just one of the capabilities offered by Node.
Node is the result of John Dahl taking Google’s V8 engine and wrapping it within a C++ program. This program becomes the new runtime environment for the Javascript code, giving the resulting JS code the ability to access things it couldn’t access in the browser alone such as the user’s file system, handling a larger encompassing range of networking tasks, etc. Simple though it may be, what Node offers is asynchronous actions, the ability to scale a web application to accommodate a ridiculous number of concurrent users, autonomous actions, and much more, and this is to say nothing about its modular system and its popular open-source mechanics introduced via the Node Package Manager.
