How JavaScript became popular—part 3

Running the same language on the server and on the browser was quite appealing

In 2009, “Node.js” was released, a free command-line JavaScript environment that ran without a browser. Until that time, the server part of web applications was written in Python or Ruby or Java or PHP or in some other language, but normally not on JavaScript, since JavaScript was for the browser only. But Node.js made it possible to write the server part of the web application in JavaScript. There were many reasons this was very appealing:

• You only needed one language, JavaScript, which could run both on the server and on the browser.

• Some code could be shared between browser and server. Otherwise we often write the same piece of functionality in e.g. Python, so that the server can run it, and in JavaScript, so that the browser can run it.

• Node.js was very fast.

• JavaScript is an asynchronous language by design. I’m not going into detail about what this means, but it’s a good thing for servers. Python only got standard asynchronous features in 2014, whereas JavaScript was asynchronous in the core from day one in 1995.

It’s therefore no surprise that a year and a half after the first release of Node.js, Express.js, a web application framework for the server, was released.

There was a problem though. JavaScript sucked. It had some good parts, but it was a bad language. But this is a story for next time.