How Node.js Transformed the Landscape of Backend Engineering
How Node.js Transformed the Landscape of Backend Engineering
B.N. (Before Node)
For most of software engineering history, JavaScript has been a language with limited functionality because of the simple fact that it could only run in the browser. Each browser has an engine that enables JavaScript to run, such as the Mozilla Foundation’s Rhino, or Internet Explorer’s Chakra. These engines, along with certain unique functionality, made JavaScript a powerful choice for the front-ends of applications, but impossible to use on the back-end. Its in-browser limitation meant that it could not be run locally, and could not be used to build a server.
Chrome’s V8 JavaScript Engine
In 2008, software engineers and internet users everywhere received an incredible gift from Google: the Chrome browser. In September of that year, Google launched both the Chrome browser and the V8 JavaScript engine on which it was built (the engine was written in C++). The V8 engine has proved to be arguably the fastest and most powerful JavaScript engine available, and its open-source status has allowed other developers access to it from a development standpoint.
The V8 engine offered the foundation to use JavaScript outside of the browser. Other options for server-side JavaScript had come before, but none were nearly as successful in their attempts. For those of us who have only ever known JavaScript with the availability of Node.js, we take it for granted. But at the time, this was huge. Ryan Dahl, the original developer of Node.js, saw the opportunity that the V8 engine presented and took to adding additional functionality to the open-source code. Most importantly, Node.js would come to support the creation of web servers, and introduced the event loop.
World, Meet Node.js
The first version of Node.js was launch in 2009, less than a year after Chrome was released, and included this ability to create web servers in JavaScript. In addition to allowing server creation, Node.js made it possible to run JavaScript code locally. If you have ever used IRB in Ruby, Node.js allowed for the same ability to run code in your terminal that IRB does.
While Netscape’s LiveWire, the first attempt at using JavaScript for server-side programming, never really took off, Node.js did not share this struggle. Having been built on the powerful V8 engine and been released at a time that the JavaScript language was already gaining in popularity, the Node.js runtime environment exploded and has not slowed down since.
To be clear, yes, Node.js is a runtime environment. It is not a framework, a library, or an engine. It is a runtime environment, because it is, as this description suggests, an environment that allows for JavaScript code to run. If the V8 engine and Chrome (or Firefox, Safari, etc.) create the environment that allows JavaScript to run in browser for a user to interact with, Node.js creates the environment on the back-end for JavaScript to run.
A.N. (After Node)
Node.js opened the door to a world in which writing full-stack JavaScript was not only possible, but a fantastic option. Using one language across an entire application just makes life easier. There is more fluidity between the back-end and front-end. The whole team working on an application is writing in the same language. Front-end engineers can more easily step into back-end work when needed, and vice-versa. On top of all of this, it’s incredibly fast, and incredibly performant.
Node.js has paved the road for popular backend frameworks like Express.js, Next.js, and Meteor.js. Between Express.js and React.js, you can have a full-stack application running with only two lines in your terminal. That’s pretty amazing. And with popular NoSql database options like Mongo DB (MERN, MEAN), you can even just store data essentially in JSON format in the database. From database to user, you have consistency and know what to expect, and that is a powerful thing in software engineering.
Originally published at https://www.syntx.io on November 15, 2019.
