Corporate software engineering is a world within itself. Huge codebases, often containing spaghetti code, call for a statically typed language that helps to maintain sanity when working on such complex projects. This used to be the case for a long time – Java and C# used to be the two kings of this domain, ruling with no real competitor in sight.
Software engineers struggled to stay sane while having to deal with complications and issues such as compilations, difficult package management, and the overall complexities of these languages. Little did everybody know that the language enterprises would start migrating to was right under their noses since 1995 – JavaScript (JS).
To be ready for “serious” use, it needed two releases, however. Enterprise teams were unable to use the language in bigger projects without Node.js, a runtime for Brendan Eich’s creation, and TypeScript, typed JavaScript superset. Both of them helped in their own way.
Node.js allowed to have JavaScript executed outside of the browser. While it was not the first attempt at allowing for that, it was the first one to take off. Several years later, and the project was one of the key factors of JavaScript march to #1 globally. Enterprise apps became lighter, were written faster, and teams could become smaller - all while maintaining the same (or even improving) quality of the apps. The last aspect is mostly thanks to the creation of TypeScript.
Many enterprises use frameworks such as Express.js, Fastify or Nest.js on the server-side, and React, Angular or Vue on the client-side. They don’t stop there either. React Native/NativeScript often serve them when creating mobile apps. Electron allows them to create desktop apps. Even though they have the resources to have dedicated teams working in native languages for all platforms, they choose not to. Why?
To begin with, if all software engineers specialize in the same language, then everybody understands each other. Traditionally this wouldn’t be the case with one team developing in C#/Java and the other in JavaScript. This created artificial divides that are difficult to overcome. At PayPal, back in 2013, front-end and backend teams were unified “into one team which allow[ed] [them] to understand and react to [their] users’ needs at any level in the technology stack.” Teams can share their experiences, often 1:1, which leads to faster bug fixes, for one.
Additionally, there is the economic benefit of smaller spending since the teams are smaller.
How was PayPal able to reduce the number of developers?
With their transition, they made sure that there is only one team writing code in one language only. Back then, full-stack JavaScript developers were truly a rare find. There were more popular stacks, such as Java & Java Server Faces (currently Jakarta Server Faces) or .NET + Angular.js.
Nowadays, developers working on both sides of an application are more common, and they enjoy certain popularity. They can save big companies a lot of money while the app maintains the same level of quality.
As a result, there are fewer team members and overall a smaller number of teams required.
Apart from being loved by large organizations, JavaScript is also the leading language in terms of developer affinity. Its simplicity, low barriers of entry, general availability of learning resources, and its universality make it a popular choice among programmers, both experienced and fresh.
JavaScript is the leader in GitHub’s “State of the Octoverse” study, being the most popular language since 2014 (the latest release was in 2020). TypeScript placed 4th, ahead of of C#, PHP or Ruby, and behind Java, Python, and of course, JavaScript.
In StackOverflow’s Summary from the same year, JavaScript remained the most popular language for the eighth year in a row [sic!]. When it comes to affinity, TypeScript places second, behind Rust, and ahead of Python.
Those are just some indicators of how deep the talent pool can be. One “catch” is that the bulk of JavaScript’s popularity on GitHub could be attributed to frontend engineers, ITMAGINATION’s Chief Innovation Officer, Marcin Dąbrowski adds.
That’s just the beginning of the advantages - enterprises enjoy many other benefits from adopting Node.js.
In 2013, PayPal wrote an article about their journey with Node.js. They managed to rebuild their app in JavaScript twice as fast, with fewer people. On top of that, there were 33% fewer lines of code, and it consisted of 40% fewer files (!).
Not only that – the app could serve twice the amount of requests versus the Java based application. Interestingly, the Node.js app utilized only one of the cores, while Java used… 5 of them [sic!]. If you are not impressed by now, pages were served 200ms faster.
Node.js in general does not require many resources to run and is quite fast. ITMAGINATION’s Artur Łabudziński in a conversation with us, shared how he is impressed by the language's performance and Google’s great work on their V8 engine – the foundation of Node.js.
[Talking about the reasons for JavaScript’s popularity in cloud & backend use cases] To me, because of its speed. Because of its optimization, because Google works really hard on V8, which is the engine that runs JavaScript. They optimized it, wrote a few compilers, which is why it starts fast and also can simultaneously optimize itself because of JIT, which stands for "Just In Time compilation".
Thanks to this, we now have a decent programming language that runs everywhere. And Node.js, an environment for JavaScript that runs on V8 with a connection to the Operating System that allows us to write both backends and apps that are more serious, and do more than just showing a website.
Since 2013, there were a lot of improvements made to the language, and runtime, which most likely further improved performance.
Up until a few years ago, the general approach for enterprises was to build apps using a monolithic architecture. To put it simply, all parts of the app were closely dependent on each other, leading to an important problem. If one part of the app failed, all of the app failed.
That is one of the primary reasons corporate teams started embracing the microservices architecture. All parts of the app were separate, thus if one feature stopped working, the app remained functional. There are two primary ways the separation is achieved – containers and serverless functions.
When teams are looking to make their apps more independent from the environment from which they are working, they turn to containers. They still require some consideration as to what and where they run, though not that much. In general, containerization is a reliable way to ensure we remove the very well-known problem with software engineering - “but it runs on my computer”.
Unsurprisingly, it is where JavaScript & Node.js rule as well. Node.js requires little to run – little RAM and configuration, among others. Developers also have a web server in the standard library, giving developers a lot of room to maneuver without needing to refer to 3rd party code. Even if you decide to use a library, such as Express.js, they are usually just thin layers on top of the built-in Node’s Http library. Create. Build. Use PM2 for managing the production app. Done.
Serverless functions are another step in abstracting the “where” away. Solutions, such as Azure Functions or AWS Lambdas are a bit radical in separating features and functions. They are also traditionally preferred by corporate users. In fact, in 2020, around 80% of AWS users from bigger companies use Lambdas. The biggest users embrace them heavily, as debugging can be an issue that is not worth it for the smaller teams, but fault tolerance, isolation, and is heavily desired by the bigger teams. They scale better, are quicker to deploy, and we can avoid any lock-ins.
An important metric here is the cold start, which is what happens when your functions is idle for a longer while. As it turns out, the only language that can compete with JavaScript is Python.
To end with, serverless functions are about the most cost efficient from all microservices solutions, as one pays only as much as one uses instead of paying up front for a month.
Before we go into much detail, we have to talk about one thing. Most of the enterprise apps, libraries, and frameworks are written in TypeScript (TS) – JavaScript’s superset which provides design-time type safety. Design-time means as much as type safety during code editing.
To give a simple example of problems that could have occured, should TypeScript have not been created:
If in C#, you write
Nothing will compile, and you won’t be able to evaluate the expression, because you get an error. Using a plus is fair game in C#, since it’s string concatenation. Using a minus will get you in trouble. Fair enough.
In Python we cannot use plus or minus.
This simple code will not run correctly, because we will get a “TypeError.”
Now in JavaScript, things get interesting. What we get from
is 111 and 10 respectively. No errors, no problems.
Even though these examples are trivial to say at the very least, they illustrate a bigger issue, and give a taste of what could happen should Microsoft have not created their language (TypeScript) in 2012. Luckily, they did, which made wrapping heads around large codebases much easier. What would TypeScript do with the snippet (please notice how it’s the same as the JavaScript one)?
The answer is: nothing at all. We would get an error when compiling our code, and our editor would complain as well.
The wider community also fell in love, quickly converting numerous projects to TypeScript, and adding type definitions for libraries and frameworks that did not have them previously defined. As a result, you can enjoy type safety 99% of the time. Artur Łabudziński, Senior JavaScript & Node.js Developer at ITMAGINATION, recommends using TypeScript in even the smallest of the projects in this recent video interview where we discussed the current state of full-stack JavaScript Development.
In the case of TypeScript, the benefits largely outweigh any possible negatives . Simplicity, speed, cost-efficiency. All while maintaining (design-time) type safety. To be clear, what are the possible drawbacks of adopting the superset?
We are mainly talking about time expenditure. Sometimes it will be necessary to declare type definitions for packages that do not have those. (Partial) Design-type safety can be achieved in JavaScript as well, using JSDoc comments, though it won’t be as good as TypeScript one. Lastly, your .ts files will need to be transpiled to JavaScript. Albeit it does not take long, it is slightly inconvenient.
After a long and rocky history, JavaScript grew up from being an ugly duckling to a beautiful swan. Corporate software engineers love many of the advantages of the language, while the most pressing problems are easily avoided thanks to TypeScript.
Node.js, faster than other alternatives, and more approachable as well, is consistently getting faster and faster, being the corporate gateway to microservices. Its alternative, Deno, might also get love from the big companies, however it’s perhaps too early to determine whether it’s going to give Node.js a run for its money.
Next up, 5 Reasons Why Startups Love Node.js!
.svg){kind=small}
