Why JavaScript is Doomed
John Sonmez, @jsonmez, argues in his post Why JavaScript is Doomed that JavaScript will be replaced some day. Here is the last line of his post:
I don’t know when this will happen with JavaScript, but I am pretty sure it will happen.
Several commenters and retweeters apparently did not read that far, as they have belted out the "troll post" tag and are taking him to task for something he did not say. Some of them are quite uncomprehending:
You remove JS, you lose jQ.
What can be said to such people? What are they reacting to?
I happen to like things John criticizes - and appreciate when his criticisms point out things I'd overlooked - which means I have to read them carefully to be sure I've understood them - which means occassionally catching problems with his argument.
For example, John early on writes, "I don’t hate JavaScript," but later writes, "As much as I loathe JavaScript itself..."
That kind of dissonance can be a fertile source of irritation for those who read too quickly to be conscious of it. But irritation is not an argument or counter-argument.
Most JavaScript programmers will agree with John's assessment:
JavaScript has some things that are fundamentally wrong with it that no amount of covering up or pretending will fix.
John's argument is that the amount of "everything else" required to make JavaScript easier to work with means it has already created momentum that will result in JavaScript's eventual replacement (maybe DART, maybe not).
- JavaScript's rise in popularity is mainly due to jQuery, because that library made cross-browser DOM and Ajax easier.
I don't agree completely - it really was Ajax that drove the creation of cross-browser libraries like jQuery, so they were no longer just nice to have, they were necessary if you wanted to be productive.
- The JavaScript "IDE" is really cobbled together out of parts.
...so many developers get up in the morning, fire up their IDE—or excuse me, lightweight text editor which has 50 plugins installed to give the capabilities of an IDE, but is not an IDE—and write JavaScript code. Why do they do it, unless they think JavaScript really is awesome?
Some would argue that all programs should be built this way - Unix Philosophers, for example. But who really wants to build everything - by which I mean every tool - to support JavaScript on his own? Apparently there is a lot of people:
It’s because all the stuff around JavaScript and built with JavaScript and on top of JavaScript is actually pretty awesome.
- The Stuff Around JavaScript is its Achilles' heel.
All those frameworks were really useful at first, but they are becoming such a huge mental burden. Are you worried about what JavaScript framework you need to master and keeping up with what is the hot one to use on any given day? I am.
Like just about all software (see Zawinski's Law), the frameworks for MVC applications in the browser grow beyond ease-of-use - and then are replaced by the new hotness that has to be learned in order to be supported.
- I don't need an IDE
Text editors are enough, most of the time, for dealing with JavaScript. The extra stuff like linting, pre-processing, auto-running tests, or even LiveReload can be handled from the command line, rather than the editor (SublimeText2 is pretty nice, though).
- I don't need a framework
Lucky me, I learned to program JavaScript from plaintext and reading examples and trying them out with alert()-driven programs. Once I learned TDD to build with JavaScript at a small business I joined in 2006 which ventured to rewrite - from scratch - its only application, I hardly needed to use any libraries - in fact, preferred not to.
If you read through many of his other posts on simpleprogrammer.com, you'll find that John is - rightly - informed by healthy skepticism.
Read his thoughts and warnings about Scrum/Agile practices -> When Scrum Hurts: Mob Architecture, or Do hard things last, or even his conclusions on test-driven development.
These are "counter-cultural" positions, all about keeping your eye on the real prize - getting things done with a minimum of overhead or secondary activities.