Why Is JavaScript Such a Big Deal?
If you’re anything like me (and have been in software development for a long time), several years ago you started wondering “why all of a sudden is JavaScript everywhere and why is everyone talking about it?”. In the intervening years JavaScript has, if anything, become even more ubiquitous in software development stacks and engineering discussions. In this post I attempt to explain why JavaScript is so dominant and so important to modern software development.
My experiences with JavaScript started in the late 90s when building plain old web pages (this was post-FrontPage but early-Dreamweaver) back when front end frameworks weren’t yet a gleam in developers’ eyes and even CSS browser support was thin. My most common use of JavaScript at that time was for navigation menus – you know, that cutting edge move where a user hovers a sliced image (remember those?), the image slice changed out to a lighter or darker variant and maybe some sub-navigation links would show as an accordion opens up. I can still picture the first edition O’Reilly JavaScript book that was my reference.
If you had told me in 1998 that JavaScript would form the basis of countless future enterprise software frameworks and systems I NEVER would have believed you. I would have put my money on an evolved Java stack or a future-state platform Microsoft seemed to be brewing (which turned out to be .NET). JavaScript was not compiled, it had no strong typing (you’d find out you made a mistake when you loaded the page!), it was slow and the development experience was rudimentary at best.
What drove JavaScript’s growth?
Web browsers turned into application platforms
Fortunately for Mercury, web browsers grew into highly-performant clients that have taken root as consumer and enterprise application delivery vessels. The last two decades have seen a major shift from “fat”/installed software clients and towards browsers (and along the way, “rich Internet application” plugins like Flash bit the dust). That left good old HTML, JavaScript and CSS standing on every PC and laptop (and soon tablets and phones).
User experience catnip
The move away from fat client installed software would not have been possible without the increasingly capable and responsive interfaces that JavaScript made possible. Instead of click-post-wait, click-post-wait cycle that users had become accustomed to, AJAX and successive incarnations of JavaScript ushered in real-time responsiveness, partial screen updates and highly dynamic web pages. Once users got used to that kind of experience (and make no mistake, they first encountered it on consumer websites), they did not want to go back to the pre-JavaScript experiences at work.
Computing moving to the edge
Back in the day, all real compute power was contained at the server, not at the edge (the user’s typically lower-powered laptop). The frontiers of the web were paved by users filling a form, hitting Submit, the page doing a POST and then patiently waiting for the server to work through needed logic, render the appropriate HTML and then send the HTML for a full new web page down the pipe. Increasingly, as compute power grew at edge devices, browsers became more capable and developers began to exploit that power, AJAX and then sophisticated to JavaScript frameworks making REST API calls got the client driving just as hard as the server ever did. And now even phones have the processing power to perform work that would have been typical of late-90s servers.
It works and it works everywhere
JavaScript runs effectively on any device that supports a browser. In the intervening time no other alternative came together (and sustained itself) to deliver a language or platform that would run as ubiquitously. Flash made a serious run for several years but Steve Jobs neutralized that as a viable threat in the 2000s. As a developer there’s nothing like knowing that JavaScript to a specific version will run everywhere you try to deploy it. In many ways it’s the closest we’ve gotten to date to the “write once, run everywhere” holy grail.
Huge improvements to the language AND browsers
Today’s JavaScript bears very little resemblance to the simplistic JavaScript I used to build rollover menus. Over the last 20 years the JavaScript language has been extended extensively to fill in holes in functions and overall evolve itself as a serious language. At the same time the browser makers have poured serious energy into their overall performance and particularly on handling JavaScript. Modern browser JavaScript rendering speed is more than an order of magnitude quicker than a decade ago. Now there is very little keeping JavaScript as a runtime language from delivering the sophistication needed for modern applications.
What makes all this possible?
Low learning barrier
JavaScript is not a difficult (and in many ways not very picky) language to learn. It’s a permissive language for first time programmer, a reasonable language for pre-web developers and an easy (if not counter-intuitive) language for experienced programmers to pick up.
Plethora of frameworks, libraries of every kind
JavaScript has an absolutely huge (and growing) number of front end frameworks, back end frameworks and everywhere in between. Many of open source’s most popular projects include a rogue’s gallery of JavaScript suspects: React, Angular, Vue.js and Node.js (for starters). Aside from those big name frameworks and libraries, there are countless numbers of augmenting libs, widgets and tools – tools to handle charting, forms, validation, device interaction, etc. This richness of frameworks and libraries enables developers to build applications that are that much richer and more powerful, driving even more penetration and popularity within enterprises.
Compatibility at the click of a build
Bundlers, build tools and a whole new generation of developer tools like Webpack, Babel and Browserify take the headache out of versions, supported browsers and backward compatibility. Developer setups now transparently cover cross-compilation to current and legacy JavaScript versions. In this way the packaged application will run on both old browsers AND run optimally on the latest browsers – without developers having to write variants to down-level browsers.
Testing frameworks
To ever have a chance of enterprise adoption, a software platform has to pack an effective means of serious and automated testing. The JavaScript community came out in force to provide not just one solution but many – Jest, Jasmine, Mocha and other testing frameworks match the kind of testing enterprise systems demand. Using these testing frameworks, development teams can both put together unit tests, integration tests and functional tests – and automate them upon builds.
Compile-time support
One of the main historical knocks on JavaScript is that JavaScript is not strongly-typed (a variable could be a string, could be an integer or maybe kind of both) as is table stakes for enterprises languages like C# and Java. Again, the JavaScript community rose to the challenge with stricture and compiled variants like TypeScript and CoffeeScript. Combined with debugging, strong typing and other syntactic sugar make JavaScript into a “real language”.
Where/how is JavaScript used now?
Every interface you can imagine
Yes, developers are still building website navigation menus like I did back in the ’90s. But the kinds of rich enterprise application interfaces software teams are building with React, Angular and Vue makes the traditional software interfaces you see at your doctor’s office look downright primitive. Modern JavaScript-driven interfaces are smooth, fast and responsive to every interface modality and size one can imagine. If you’ve been on 5 websites today, you’ve interacted with 5 JavaScript-driven interfaces.
JSON overtakes XML
Way back in the day, web-driven data interchange and pioneering web services were done with XML – XML is the markup language that was destined to be the data exchange vehicle between systems. But along the way developers realized that if they stored data as JSON and wrote APIs to return JSON they wouldn’t have to transform the data inside their applications – they could just use it as is. If you are not aware, JSON stands for JavaScript Object Notation – it is inherently how JavaScript handles data. Fast-forward several years and you are much more likely to run across APIs that return JSON and not XML.
Isomorphic and desktop JavaScript
JavaScript can now power all tiers of an application and when it is used at all tiers within the same application developers have a great amount of re-use across the data, logic and interface tiers. This design pattern, known as isomorphic JavaScript, is a rising trend. Isomorphic JavaScript aside, JavaScript can be packaged for a full desktop install with platforms like Electron or progressive web apps.
I hope this post has provided some level of insight into why JavaScript is so popular and how it’s used to build enterprise applications. It is anyone’s guess as to exactly where JavaScript (and allied technologies) are headed from here but it’s clear that it’s not going away anytime soon. Hit me up below and let me know what you think.