Ruben’s Beguile lady-in-waiting

The Lie That Has Beguiled A Generation Of Developers

It is truly disturbing to see how JavaScript has beguiled the current generation of software developers, esp. on the client side of web development. With the trend toward the Single Page Application (or SPA), along with an uncontrolled proliferation of client-side web frameworks for JavaScript, we are seeing many foolish companies going down the road to software engineering chaos. SPAs are far more complicated to write than traditional server-based applications, eating up more time and resources; the returns are highly questionable. And the web framework landscape is a wild wild West of free-for-alls with most of these frameworks having the life span of a fruit fly. Think Angular, React, Ember, Meteor, Backbone, Knockout, Express, Mithril, Aurelia, etc., etc., etc. Whoa! It would be hilarious if it wasn’t so horrifying. We’ve seen a civil war break out between Angular 1 and 2, and recently witnessed React attempting to upend the JS industry. Who knows how long before React itself is eclipsed.

On the server side, we’ve seen Node.js gain traction for “back end” applications. But Node has been pretty much relegated to a web niche. ERP solutions like SAP aren’t using Node. While a company may use JS for their website, don’t expect any serious shop to be washing their critical Business Intelligence data through JS code. The truth is, most Fortune 500 shops aren’t basing their businesses on JavaScript and never will. Moreover, we’re starting to see cracks in the usefulness of this runtime environment.

The reason is simple. JavaScript is intrinsically a dysfunctional language. It has many more flaws than any other programming language in wide use. JavaScript is wholly unsuitable for serious software engineering, esp. at scale. When your application grows to tens of thousands of lines of code, it becomes much more difficult to maintain, much more difficult to ensure a specific level of quality.

While JavaScript appears to be spreading well beyond the web UI domain to things like games and graphics, mobile, and the Internet of Things, upon closer inspection the truth is quite revealing. Aside from the little “indie” games you find in app stores and mobiles, no self-respecting game developer is using JavaScript. Hardcore console/PC games like FPSes, RTSes, RPGs, MMOs and up-and-coming VR titles relying on bleeding edge technologies like DX12, Vulkan or Metal will never use JavaScript. The performance requirements are extreme and JS simply cannot deliver.

For the Internet of Things, there are many well-entrenched languages like Python, Ruby and Perl, and even the ol’ C/C++ standby, available. JS does not have a competitive advantage here.

In the mobile space, JavaScript won’t be displacing Java, Objective-C and Swift any time soon. Wherever JS can be used outside of the web sphere, better and more solid languages have already staked out the territory. The web browser is really the only place where JavaScript dominates, and even then, its days are numbered. WebAssembly is coming, threatening to make JS irrelevant.

To drive home this point, let’s look at some job statistics. If you compile a list of job postings at for several cities and several languages, here is what you will find (the stats are for April 21, 2016):

It is quite evident that JavaScript job postings are nowhere near as plentiful as Java postings, but the more salient fact is this: Nearly all of the JS postings are for “front-end” web developers. Some involve Node. Hardly any are directed at non-web-related activity. If all you want to do is write software for web browsers, then JS may be your ticket, but it’s hardly the path to a rich IT career.

More job stats can be found at The Hacker Life, which looks at tech jobs in various kinds of companies versus programming languages. For example, in the San Francisco Bay Area, JavaScript is less popular with startups than with older, well-established companies. Startups generally favour Ruby, C and Python. Even the older companies show a greater preference for C++, C#, PHP and Perl! (The results may seem to contradict my look at Indeed, but it must be noted that for The Hacker Life, we don’t know what their data sources nor their methodology are.)

It is, thus, risible that so many young people are entering the IT industry via the JavaScript route. I see this all the time, everywhere. At Quora, for example, there are endless questions from IT newcomers inquiring about JavaScript. Developer forums such as those at Reddit reveal many new programmers taking online courses from the likes of Free Code Camp and believing that they have a bright future in IT. The JavaScript lie is leading everyone down a garden path.

No self-respecting Computer Science curriculum teaches JavaScript as a first language. Not the University of Toronto nor the University of California nor MIT. It’s an awful language that teaches you bad habits. So who are these online hucksters peddling JavaScript courses? Do your due diligence.

Recently, StackOverflow released their developer survey which further fuels the JS craze. There are all kinds of selection bias in this report. Its findings are not consistent with most language rankings, which show that JavaScript is hardly eating the world of software. IEEE Spectrum, which is based on 12 metrics from 10 data sources, places JavaScript at #8. PYPL puts JavaScript in #5 position. TIOBE says JavaScript is at #7. CodeEval ranks it as #6.

Even Redmonk’s language ranking is deceptive. JavaScript is on top because of the massive number of lines of code committed to Github. What are we to make of this? Well, since JS is the only language native to web browsers, any web project in any language must have some JS code. The number of lines of code for JS is greatly inflated when all of these projects are committed to Github. JS is not used by choice, and Redmonk proves that the web is popular, not that JS is popular. Duh!

Lest you think I’m all about tearing down the language, I am also about reforming the language. Read my plan for JavaScript.

Originally published at