Merriam-Webster defines religion as:
Definition of religion
1a : the state of a religious
b(1) : the service and worship of God or the supernatural
(2) : commitment or devotion to religious faith or observance
2 : a personal set or institutionalized system of religious attitudes, beliefs, and practices
3 archaic : scrupulous conformity : CONSCIENTIOUSNESS
4 : a cause, principle, or system of beliefs held to with ardor and faith
In software development, nothing exemplifies an institutionalized system of religious attitudes, causes, beliefs and practices held with ardor and faith as JavaScript and Node.js.
The JavaScript devotees worship multiple gods (I counted at least 10) and expect strict conformity out of one another. There are many sub-religions within the main JS religion, usually revolving about IDEs and client-side single page application frameworks. Most importantly, JS community is distinguished by its disregard for factual reality about their programming language.
This post is not meant to convert true JavaScript devotees or convince them to expand their horizons. Try convincing a Trump supporter that Climate Change is real — it’s kinda like that. Just like there are independent voters out there, there are quite a few independent thinkers in the software development community, and this post is for them.
In 2015, I wrote a blog post called “The Three Myths About JavaScript Simplicity.” A little over three years later, I am pretty sure nothing has changed. First, let’s the visit the three myths I wrote about:
1) JavaScript developers are easy to recruit
JavaScript stands in third place regarding the number of job openings (I.e., demand) and fourth place (out of 15 or so) in terms of compensation. High demand and high compensation indicate difficulties employers encounter recruiting qualified JS developers capable of building scalable enterprise applications.
2) JavaScript is easy to learn
All programming languages are Turing-equivalent. That means they are all the same and equally easy to learn. The problem with JavaScript, however, is not the language itself. It is the frameworks.
In 2016, I wrote:
This 2016 list of frameworks one should learn includes Angular, React, Polymer, VUE, and Ember. A similar article for 2015 lists out Angular, Backbone, React, Meteor, Ember, Polymer, and Aurelia. In one year alone, it would seem as if Backbone and Aurelia fell off the radar and VUE showed up out of nowhere.
Meanwhile 96% of web apps use JQuery. Yes, that is ninety-six percent.
Let’s see what the 2018 list of JS frameworks to learn include: Angular, React and VUE are still on the list; GraphQL, Next.js, Storybook, Reason, and Jest replace the others from my 2016 list. Web apps have been around for 20 years, you’d think by now there would be some movement towards standardization.
So, while JS itself is relatively pure, the frameworks needed to build a modern application are not. The only good thing about JS frameworks and libraries is that they encourage some of the JS religious rituals such as installing hundreds of megabytes worth of modules and arguing about bower vs. NPM and the color of the bike shed.
3) Non-developers can learn JavaScript
I have yet to meet a business user who is interested in learning to code. Period.
Now that we covered the three JS myths from 2016, let me throw in a few more that seem to persist:
4) You can build any enterprise application in JavaScript
Reality is that you can create an enterprise application in any language. This is not an argument in favor of JS per se. Of course, you can build simple forms-based apps.
Lack of high-performance precision math and single-CPU nature of JS make it an inappropriate language for anything involving high-volume financial transactions. That same single-CPU nature of JS makes it scale poorly for privacy, security, and encryption related tasks.
5) JavaScript is the only language you need to learn
There was a time when COBOL developers felt that COBOL was the only language they ever needed to learn. Let’s leave it at that.
6) The same developer can work on both client and backend
This holds true for only simple applications. The reality is that front-end development is very different from back-end; front-end frameworks are very distinct from server-side. Writing for the front-end, you don’t have to worry about a million users exercising the same bottleneck in your code at the same time; on the server-side you do.
Final thoughts
Nothing I said here should deter enterprises from using JavaScript where it makes sense. Even on this blog, I wrote many times that JavaScript makes a perfect API mashup language or for writing server-less cloud functions. It is indeed decent enough for fairly simple non-transactional (as in ACID) forms-based applications. It may even make an excellent inexpensive substitute for data transformation and enterprise service bus frameworks.
All developers should learn one new programming language every year, even if they don’t end up coding in it. Cross-pollination of ideas is a good thing, and using the right tool for the job is what distinguishes a religious zealot from a qualified engineer.
The Dulin Report 