And so it goes, the eternal question “What is wrong with JavaScript?” and the inevitable, inescapably droll, reply:
Oh, ho ho ha ha haaaaaaaaaaah… The gag never gets less funny. I need to be clear that Scott Hanselman is one of my favourite people in the public eye. I hold him to be an industry treasure and I’m fully aware of him just poking fun here but we’ve all seen this dialog before and we all know it is not always so lighthearted.
At the end of the day, these scenarios showing how ‘broken’ JavaScript is are almost always bizarrely contrived examples that can be easily solved with the immortal words of the great Tommy Cooper:
Patient: “Doctor, it hurts when I do this”
Doctor: “Well, don’t do it”
Powerful Facts
Lets be absolutely clear that JavaScript is an incredibly powerful language. It is the ubiquitous web programming language. Of course it currently has a monopoly that ensures this status. That does not change the fact that JavaScript runs on the fastest, most powerful and most secure websites. So clearly it does exactly what is needed when in the right hands.
JavaScript is free with a very low barrier to entry – all you need is a web browser.
JavaScript through its node.js guise powers Netflix, LinkedIn, NASA, PayPal… The list goes on and on.
Furthermore it is easy enough to learn and use that it is a firm favourite for beginners learning programming. It is in this last point that we observe some particularly harmful industry attitudes towards JavaScript.
What’s The Damage?
So now that we can all agree that Tommy Cooper has fixed JavaScript from the grave and now that we’re clear about just how seriously capable JavaScript is as a language, we can get onto the central point: industry attitudes to JavaScript are damaging. While many languages such as SQL and PHP are common targets of derision and it seems to me that each case has it’s own unique characteristics and nuances, there is something notably insidious about the way JavaScript is targeted.
One of the more painful examples of JavaScript’s negative press can be observed in the regular reports from those learning programming that they feel mocked for learning JavaScript. This is, quite frankly, appalling. We work in an industry that is suffering from a massive global undersupply of talent and we’re making potential recruits feel like crap. Well done team! Even globally established personalities such as Miguel de Icaza of Xamarin fame can’t help but fan these flames. What chance do new recruits have?
The JavaScript Apocalypse?
Moving on to the issue that prompted me to start writing this article; WebAssembly is here. It has a great website explaining all about it: webassembly.org. It even has a logo! It also has a bunch of shiny new features that promise to improve the experience of end users browsing the web.
From distribution, threading and performance improvements to a new common language with expanded data types, WebAssembly offers a bunch of improvements to the web development toolkit. I’m all for these changes! JavaScript and the web programming environment are far from perfect and these are another great step in the right direction.
Of course WebAssembly’s common language also promises to open up the web client for other programming languages. “Hurrah!” I hear many cheer. I’m seeing countless messages of support for the death of JavaScript at the hands of the obviously infinitely superior quality languages of C#, Rust and Java 🙄 Yeah… I’m not so sure…
Nah!
Like most programming languages, JavaScript is a product of its environment: namely, the web browser. It did have competition in the early days with VBScript back in IE4/5… I think… It was a long time ago. But otherwise it has developed on its own in response to demand from the web developer community and in response to the changing web landscape. The modern incarnations of JavaScript (ECMA Script 6/7/8) are incredibly powerful, including modern language features such as an async programming model, functional capabilities and so on. In many ways modern JavaScript resembles the languages to which it is so frequently compared but it also lacks many language features that are less relevant to web client programming such as generics and C#’s LINQ. It’s loose typing system make it well suited for working with the HTML DOM. Overall it would appear, as you might expect, that JavaScript is made for web client programming and is in fact the best choice for this task.
Even the WebAssembly project agrees, confirming on the project website that JavaScript will continue to be the ‘special’ focus of attention and you know what? This is a good thing!
Babel
Look, we already have other languages that compile for the web client but I don’t see any existential threat from the (albeit beautiful) CoffeeScript or from the (misguided) TypeScript. Sure, WebAssembly will make this more effective but the reasons that TypeScript hasn’t already taken over the web development world will still apply to C# and WebAssembly. We have seen a similar battle play out in the database world where NoSQL was lauded as the slayer of the decrepit 1970’s technology we all know as SQL. That was until NoSQL databases started to implement SQL. Turns out that SQL is hard to beat when it comes to querying data, which is unsurprising when you consider its 50-odd years of evolution in that environment and the same rule will apply to any JavaScript challengers. Personally I suspect a large part of JavaScript’s alternatives failing to take hold is that web client programming doesn’t need the added static typing, etc.; in my experience all these challengers do is introduce compiler warnings and complexity that waste time. Ultimately I don’t have all the answers here but it is fair to say that it would take a serious effort to out-web the language that has evolved for the web environment.
Where my real concern lies is in the well known problems that are brought about by having too much choice when it comes to communicating. We use human readable programming languages so that we can communicate our programs to each other. With that in mind it is clearly more effective in the long run if we all learn to talk the same language. The story of The Tower of Babel shows us that for a long time we have considered too much choice to be a very bad thing when it comes to communication.
It would be a frustrating situation indeed if we were to end up having to consider and manage the overhead of multiple languages for a single task all because of some daft attitudes towards JavaScript. Furthermore, businesses that are struggling to find web developers don’t now also need to worry about whether these developers are Rust, Java or C# web developers. JavaScript is the right tool for the job so lets stop wasting time with all the JavaScript bashing and get on board with an incredibly powerful language we can all understand!
Stephen Roughley - A Common Developer 
2 responses to “Babeling in defence of JavaScript”
[…] Babeling in defence of JavaScript (Stephen Roughley) […]
LikeLike
Sorry if I missed this but … The issue is ‘too much choice’ in my opinion; but too much choice in regards to the flexibility of JS.
The flexibility of the language is a hard pill to swallow if you’re a C#, typed language programmer, and may be the source of contention.
Running into what Scott H. posted in the twitter post depicted above is a confusing matter, and potential for an mistake. This confusing matter can be remedied with studying, and experience; but it’s considered ‘wrong’ because it leads to confusion, and because you do have so many options.
There are some people that will have no issue learning JS, especially if that’s their first language. However going from C# to JS you have too many options, and this opens the door for quality issues, and learning roadblocks.
Typescript provides (maybe coffee script too) provide a mechanism for reducing options with compile time errors. This provide a safety net, and one less thing to worry about.
In my opinion, based on the endless debates on this matter, it seems that JS’s ‘cons’ come from people with less time on their hands, not from ignorance. JS’s flexibility allows for too many outcomes, which I think easily equates to more time no matter the benefits the flexibility gives.
There are endless popular frameworks that make JS easier to maintain, and write. This is a good indicator that there’s a common consensus that it is harder to maintain, and write.
I enjoy JS; but I didn’t enjoy it until JQuery came along. I’m loving all the great frameworks that make it easier to understand, and use. When I first used it, JS was introduced as a utility language. A language that you used to manipulate DOM elements. It wasn’t until years later, that I learned it as a language. I think it’s done/doing a lot of great things; but I don’t think we should have just ignored the ‘cons’, and focused on the flexibility ‘pro’.
LikeLike