Is NodeJS enterprise-ready? Hmm, what is EE anyway?
Yesterday, a passionate professional debate in a cafe was meant to decide if JS is EE-ready. The discussion turned out to be interesting for different reasons than might have been anticipated. What is EE anyway?
My definition: prioritising scale over ingenuity
Harsh maybe, but it serves to illustrate two company attitudes and the gulf between. The ‘scale’ attitude is often represented in ‘safe’ policies and process libraries. In this environment however, bureaucracy flourishes while initiative corrodes.
This credo means, that rather than simply “getting the job done” you have talent wasted on checking if the “the KPIs are green”.
This is the state when, instead of collecting a nacho macho swat-team hitting the market hard in a few months, you are in fact hiring 50–150 people identified by some arcane HR recruitment process.
I admit Java and .Net are well adapted to this corporate mentality:
- even tinkers and tailors can be productive with a well-chosen toolset
- legal entities can be rebuked when components are shattered by unpleasant errors
- they support the clever but dangerous illusion of permanence
Enterprises, as such, are the houses from where the 9 circles of IT hell open.
I do not intend to show strong moral principles or ride on a high horse at all, but an understanding of how orthogonal ‘safety’ and ‘innovation’ are, is crucial here.
Following this path, I can confidently declare JS to be not EE-ready at all in that very sense:
- introduces functional world without type safety
- has no standard-like design patterns or paths
- diversity over monochromacity is highly encouraged
- no single framework/lib/toolset/stack
and you need a good team to tame it and to control it.
I tried to collect some golden rules here.
Keep them in mind and your JS project won’t be a failure but shows a lightning fast advance you have never met.
Do not let IT fossils make subjective judgements; carrier limbo is the first circle in IT hell. ;)