If there is one galaxy in the software development universe that has suffered from the relentless, unstoppable, frantic, and unbearable pace of innovation, that one is, undoubtedly, JavaScript.
Around 2012, it was not uncommon to hear developers on Monday mornings talking over coffee about the new JavaScript framework they tried over the weekend. Some adventurous ones would even write yet another article in Medium or dev.to about their findings, with a nice comparison table that would help others find their way, or at least cover the hosting costs of their website via advertising. Some would even try to write their own.
Frameworks, Frameworks, Frameworks…!
JavaScript took around 15 years to rise, from its inception to the boom of the 2010s. It all began to explode when Douglas Crockford found out that JavaScript had some good parts; from that point on, the world of JavaScript frameworks evolved dramatically.
The first issue to tackle was the cross-browser chasm. Prototype, jQuery, MooTools, YUI, Ext.js, Dojo, they all provided ways to work around this horrible developer experience that was dealing with Internet Explorer 6 and later. Long before Apple introduced the <CANVAS> object, Walter Zorn gave us the first DHTML drawing library. The rise of Ruby on Rails pushed script.aculo.us to the spotlight, providing the first glance at programmable animations. Actually, scratch that; you could do cross-browser, JavaScript-powered, timeline-based animations with Macromedia Dreamweaver back in 1998. But I digress.
Then came Ajax, a term famously coined by Jesse James Garrett and whose initial implementation was based… on a Microsoft COM+ component called XMLHttpRequest. Gotta love those capitalization rules.
Later came Underscore and Moment.js, to provide a better APIs for common operations, respectively for functional programming or date manipulation.
All of these libraries were the pinnacle of the “Web 2.0” craze, providing developers for the first time a tool with which to build a decent user experience across all browsers with, wait for it, a single codebase. You heard right. No more if (userAgent == 'Netscape') and stuff like that.
Talk about innovation.
Then server-side JavaScript became a thing– again. The ground-breaking Node.js (itself based on a new wonder thing called V8, part of Google’s efforts to eat the web) begat Express.js, and its middleware architecture inspired from Sinatra, itself inspired from a subset of Ruby on Rails; and now replicated by almost all REST API frameworks out there, in all programming languages and flavors.
On the command line front, Node.js brought us npm, and its hellish package management fury; apparently yarn is better, but nobody can tell for sure. I wonder what is the package manager of hell called these days.
I defy any of the readers of this magazine to try to npm update your complicated Express.js application written in 2014 and never updated since, and try to fix all of the dependencies so that the tests run again in 2021. Innovating in the field of package managers made our apps weaker and impossible to update, but of course, indefinitely rewritable.
(Well, to be honest the same problem applies to apps written –and not often updated– in Swift 1.0, Android Jelly Bean, ANSI C 89, .NET 2.0, PHP 5.3… good luck with any of those. Maybe this is the future the Agile Manifesto authors were thinking about when they wrote it. Maybe not. Move fast and break things, kids.)
Then the iPhone and Android came along.
After Joe Hewitt’s iUI there were more sophisticated attempts to turn a website into an app. jQuery Mobile, Sencha Touch (of which this author has the doubtful honor of having written a book about), and lately Ionic. Around 2009 PhoneGap happened, later renamed as Apache Cordova, featuring a badly spelled anglicised version of the name of a Spanish city. Then Apple came out with the HTML5 Application Cache, but it turned out to be a douchebag. For a while it seemed that the Financial Times was the only team in the world able to build a decent web-based mobile app.
Finally, at some point Facebook vomited React Native, which quickly became the pinnacle of absolute madness and botched user experiences. Oh, but it is cross-platform, or so they say.
Lasciate ogni speranza, voi ch’entrate. In hindsight Responsive design turned out to be a better option that any and all of those enumerated above.
The sacrosaint trinity of HTML, CSS and JavaScript ended up living all together in a same file thanks to Vue.js and React, and apparently also Cycle.js and whatnot. Innovation in 2015 meant loading 12 MB of JavaScript to be able to fill a login form.
Because filling HTML templates on the client is apparently more scalable than doing it on a server, hence we bothered all users with our single page applications that crippled our web experiences for a whole decade.
Finally, on the desktop, we have got Electron. Let us not say more.
Microsoft
By the time this magazine saw the light, nobody was writing JavaScript anymore, of course; after the successful reception of CoffeeScript, Microsoft decided that it was time to own JavaScript once and for all, and created TypeScript, a surprisingly useful tool, and Visual Studio Code, a text editor written in and for TypeScript. Now they also own npm, GitHub, and it all feeds GitHub Copilot, no matter which license you were using.
And now, unbeknownst to most JavaScript developers, they are all using Microsoft technologies day in, day out. Quite an ironic turn of events, and one of the explanations for the skyrocketing MSFT ticker price in the last decade.
Among my readership, few, if any, will remember the HTML Application and the HTML Components specifications created by… Microsoft for Internet Explorer 5. In 1998. Microsoft even came up with CSS filters before GPUs were a thing.
Clearly, Microsoft has had its eyes laid on JavaScript for a long, long time.
In particular, HTML Components and Applications allowed for the creation of true desktop applications using the saint trinity of web development, all in a single file. You could, of course, substitute JavaScript with VBScript, a tasteless subset of Visual Basic which was even more crippled than its parent.
But the final result was surprisingly simple, and dare I say, extremely effective. Use HTML to add widgets to the screen of your application; style them with CSS; sprinkle some JavaScript to animate the inanimate. Thanks to COM+ components, developers could do pretty much anything with it. Want to read or write data to an Excel spreadsheet? There is a COM+ component for that. Want to send e-mail? There is another COM+ component for that, too.
Of course this was also a nice vector for worms, trojans, and viruses, starting with the infamous ILOVEYOU.txt.vbs frenzy of 2000, but that is another story.
Microsoft was, by the way, also a pioneer in the field of JavaScript in the server; back in 1996 you could write whole Active Server Pages (ASP) with JavaScript (or rather, JScript). “Oh but it was not asynchronous” I hear you say, and I say maybe (and frown at you), but you could serve tens of thousands of users simultaneously from a single Pentium II server with 32 MB of RAM. Talk about innovation in carbon emissions.
There has not been much innovation in the JavaScript arena since those times; at best, we had other players and some refinement. Paraphrasing Steve Jobs and his instructions per watt analogy to justify his choice of Intel CPUs over PowerPC ones, web servers these days are arguably serving less users per watt than in 1996; at best, the same amount.
And most of them are mining cryptocurrencies anyway, not even actually serving users anymore, and the Earth, or what is left of it, is painfully feeling it.
JavaScript, The Disappearing Parts
These days, the innovation around JavaScript is centered around making JavaScript go away. This trend was started, as mentioned above, by CoffeeScript and later by TypeScript; these days, you hardly need to write any JavaScript by hand at all. You can use Kotlin and a hundred other languages to create a JavaScript application without writing JavaScript.
Little by little, JavaScript became the new assembly of the 2010s.
And quite literally so, this assembly analogy was taken to the extreme when Firefox announced WebAssembly, an actual assembly language based on a subset of JavaScript. Somebody then used it to run Doom on a browser. Doom. Compiled from C++. Into WebAssembly.
Now we can create a full WebAssembly applications using Rust, compiling directly to WebAssembly from the confort of your command line, enjoying all the compile-time checks of the Rust compiler. You can even interact with the DOM if needed. And the weirdest of all is that you can even use Rust to re-create Flash, if so desired. The circle is closed. Neither Adobe nor Steve Jobs saw that coming.
(Flash, which used a dialect of JavaScript called ActionScript, to entice developers into their own galaxy.)
Once written and compiled, you can run microservices written in WASM inside your Kubernetes cluster; no need to create your web services with Express anymore. They are probably very fast and probably very difficult to debug; highly experimental, hence perfect for your project with a hard deadline that would be better served with single HTML page with a PHP page behind.
All is new again. Nihil sub sole novum. JavaScript is still there, somehow, but nobody can see it for sure. Hopefully somebody can still debug it. Or maybe not being able to debug it is part of the spec, who knows. At least you can get certified in JavaScript these days. Whatever that means.
All of these innovations have rendered obsolete the “View Source” command in your browser. Ever tried to read the minified JavaScript in a page minified with Babel.js or Gulp.js? Forget about WebAssembly code unless you are a CPU designer.
Call me nostalgic, but I draft websites with Vanilla JS or Postmodernize, the greatest web frameworks ever made, and arguably, the only one needed by 99.99% of web apps out there, allowing us to manage the DOM like we used to. There are lots of tutorials and guides, and even a full academy to go back to lean, small, simple websites. Who knows, server side rendering might be cool again soon.
It used to be a good practice to design websites that worked properly when JavaScript was disabled. These days, such an idea is not only laughable, it is actually counterproductive, and would render most of the web instantly and absolutely unusable. Even XMLHttpRequest is gone now; use fetch() instead.
We need more innovation in the field of innovation itself. So far, we have been reinventing (and arguably, worsening) things that worked properly before, while many actual issues remain untouched. In particular, JavaScript does not need any more abstraction layers built on top of it.
Ironically, now that Microsoft owns JavaScript de facto, this wish might as well come true. Embrace, extend, extinguish. We will talk about this subject next month.
Cover photo by Mathew MacQuarrie on Unsplash.
