Part 6: The Talent & Hiring Argument

First off, congrats on making it this far into my NodeJS rant. I hope I've made a fair point why not NodeJS, from a productivity standpoint, which has been the main emphasis in the series. You'll notice I haven't referred to any benchmarks or got caught up in language specifics and details. I don't think you can win a debate with those aspects of a language because they all have tradeoffs and preferences that may or may not be a good fit for a specific project.

It is the productivity of NodeJS that I am calling to attention. I am talking about the technical debt you incur at the moment you decide to use NodeJS due to the countless decisions and packages you'll need just to write code how you want, without even factoring in the complexities of the project itself.

This upfront and ongoing cost would be justifiable if there were insane performance benefits or exciting, cutting-edge innovation happening, but no, NodeJS is really just try to meet the status quo, and it's taking a worldwide effort to make that happen.

However, there is one valid argument that needs to be addressed in order for this to be a fair assessment of NodeJS, and that is the talent & hiring problem.

Hiring is hard

I can't blame companies and tech leaders for picking NodeJS for hiring purposes, especially in more conservative or risk-adverse companies without major technical challenges. The business appeal of being able to hire developers that can work on both the frontend and backend in the same language, combined with the ubiquity of Javascript, makes for a strong argument to pick it over more obscure languages that don't have tons of experienced developers ready to be hired.

If you combine this with the general cost and difficulty of hiring, assessing and retaining tech talent, it makes perfect sense for a company to minimize risk by picking a technology that will be easy to find qualified individuals for.

The best argument I can make against this valid approach is that the large, ubiquitous Javascript community can be a double-edged sword. I've already made a point about this in terms of open-source software, but the same applies to talent as well.

Yes, there will be plenty of junior, mid-level and senior engineers available with Javascript experience, and they won't need training to get up-to-speed with the language and ecosystem. However, I'd argue quality is far more important than quantity when it comes to engineers, and the problem you'll have when vetting Javascript engineers is finding quality JS engineers.

As already mentioned, there is a plethora of approaches to building software in NodeJS, and some are better than others. In addition, it takes a ton of discipline and agreement, which means extensive communication and quality control measures, to deliver a 'good' NodeJS project. I'm assuming 'good' is the lowest acceptable level of quality you'd expect from a team of engineers that you're paying $150k each, right?

You end up with 2 challenges to create 'good'; the code standards and the talent standards.

The talent standards can be all over the place when you have such a wide array of people who may be able to 'write' Javascript. This could range from a hobbyist/casual developer to a seasoned expert, and everything in-between.

Let's contrast that with a language like Elixir. Elixir has a far smaller developer community, even if you count Erlang engineers. Finding experienced Elixir devs will be challenging, and in some cases you may even have to resort to training new hires that are experienced in other languages to build your team. However, the reality is that the quality of the engineers experienced with Elixir is almost guaranteed to be higher. It's a self-selecting community and an amateur JS developer might not have even heard of Elixir, let alone know its intricate details and advantages, and will not understand why it uses the paradigms it does over other popular programming paradigms.

JS will give you quantity over quality, so if you want 15-20 NodeJS engineers of varying experience to deliver the same results as 5 experienced Elixir engineers then go right ahead, that's your right. Just keep in mind this communication diagram that demonstrates how communication lines grow exponentially when adding new members to a team.

Conclusion

In conclusion, I really don’t like NodeJS, if you couldn’t already tell. Haha. I just don’t think there is a good reason to use it for any non-trivial application in 2020, with some very specific exceptions. Although it may be quick to get started with Node, it quickly hits a wall and becomes quite unmanageable, with no real upside based on technical merit. Although an argument can be made from a talent perspective, I don’t think the benefits outweigh the risks, and at best is the only real advantage NodeJS is giving you over the alternatives.

It’s 2020, stop using NodeJS for new projects. If you need an alternative, look no further than Elixir.