In my first weeks at a new job many years ago, one of my backend colleagues asked me for a basic primer on frontend development. I prepared a basic history of JavaScript, TypeScript, ECMAScript, jQuery, Vue, React, and Angular. I embellished all the finer points, gave a comprehensive storytelling with personal anecdotes, and really went all out to present what I built a career on in the best possible way. His response was shock. Shock? …Why? He said something along the lines of JavaScript developers being a few fries short of a Happy Meal, thanked me for the time and insight, then gave me a business card for his therapist. That seemed a bit harsh… but just as I was about to protest, a core memory from my university days began playing in my head. A former professor once said to me, "In order to be good at JavaScript, it requires you to be a little crazy…". He then turned to me, looked me over for a moment, and continued, "You'd probably do well at it." Gee, thanks, Prof. So okay, perhaps a few fries short, admittedly. But why? I’m pretty sure I’m sane; as sane as any other engineer, anyhow.
Insanity, strictly defined, is doing the same thing and expecting different results… There was a period of time where what you did in one browser with JavaScript did not behave the same way in another browser. Do the same thing, get different results. Actually, in truth, that is still applicable today, but it’s not as bad. ECMAScript standards still get adopted at different rates by different browsers, leading not to the classical definition of insanity, but something closer to a classical definition of chaos.
Absolute. Unpredictable. Chaos.
Yes, I would agree that sums up JavaScript development. Let’s go back in time and imagine plowing along with your website code with jQuery; opening up your Firefox browser; cleaning the gunk under your ball mouse; and cracking open a Bawls energy drink. You click refresh to see if your changes took, click again on the button you were testing, and… Everything works! Time to ship
…But wait.
There’s this horrible browser that was used only by the same folks who insisted on using an abacus in the 2000s. And unfortunately, those abacus-wielding demons also controlled the checkbook ledger (money). So whenever something changed on the website, it was imperative to test thoroughly on their cursed hellscape of a browser. Internet Explorer 6 (IE6).
Let’s say you want to add an event listener to a button. Pretty standard.
document.getElementById("myButton").addEventListener("click", function() {
alert("Button clicked!");
});However, this feature was not supported in IE6! Instead, they had something called attachEvent, so you had to instead do this to achieve browser compatibility:
var button = document.getElementById("myButton");
if (button.addEventListener) {
button.addEventListener("click", function() {
alert("Button clicked!");
});
} else if (button.attachEvent) { // IE6 and IE7
button.attachEvent("onclick", function() {
alert("Button clicked!");
});
}“Well, that doesn’t seem so bad.” you might say.
Oh, if only you knew how many hundreds to thousands of event listeners were required and how some of them would bubble up differently depending on the browser. That’s also not even touching on the other horrors that David Walsh has documented in greater detail. IE6 and Microsoft decided they didn’t want to deal with Sun Microsystems about a trademark issue. Eventually, this evolved into it using its own standard of ECMAScript. This created headaches and caffeine || alcohol dependence for web developers everywhere. It effectively meant coding twice as much just to support all browsers. For the sake of simplicity there were 3 groups to support the IE4/5/6 chain, Firefox/Chrome/Opera (FCO), and Safari. For the sake of sanity, most service contracts either included support for a specific version of each or just said “Latest” since FCO didn’t have a hard numerical versioning system like IE and Safari. (I mean… of course, they had different versions, they just didn't lock that version into the name). The abacus demons usually got what they wanted, though. IE6 traditionally ended up in those contracts, but many a smart software shop charged extra for the pain and suffering “difficulty” of support and development.
Time passed.
- IE eventually became Edge.
- React Native became a thing.
- The Single Page Application (SPA) wars were already in full swing.
JavaScript developers were pretty excited! We had two-way data binding and the ability to load small snippets of JS code on the same page without having to make a full HTML page server request. This made applications ‘seem’ like they were switching pages, while also loading incredibly fast, usually only 20-30kbs of JS code per page. With all these new advantages, you would like to think we all lived harmoniously, singing Kumbaya and drinking our Red Bulls while slinging code along. But of course, there was a new territorial dispute over which SPA framework to choose between Angular, React, or VueJS. Angular was the first in 2010 and supported a Java-like experience that everyone except Java developers hated. React came out in 2013 from Facebook and used a JSX architecture blending JavaScript and XML syntax; created while a Facebook developer was drinking a Strawberry Kiwi Capri-Sun. (That last part may or may not be true.) And Vue JS made by Evan You, a former Google engineer who improved upon what he felt were shortcomings of React and JSX and kept to a “simpler is better” mindset. You (and everyone else) were in their right to build upon their predecessors; However, a darker influence was rising. It came in quietly with NodeJS, but eventually, SPA frameworks were no longer satisfied with ruling only the browser. It was time… to war against the server.
There were two options to consider. On the one hand, you had Server Side Rendering, which was basically an HTML request all dressed up in a ghost mask soon to be apprehended by the Scooby-Doo Gang. On the other hand, you had Progressive Web Applications. Download your favorite website onto your phone and treat it like any app you had on your phone. Would it work without the internet, you ask?
...Maybe?
Support for PWAs stalled, and eventually, everyone seemed to have decided it was better to make native apps instead. Server side coding practice is still permeating and a divisive factor in the JavaScript world. Whether it will continue on in the future or be replaced by something else remains to be seen. While all of these things were going on, you might be asking yourself what happened in other web languages, surely its just as chaotic with them. Well I have a newspaper here with the following: PHP got mildly respectable, Java yelled at you to update twice, and C#/ASP.net is still hated by everyone who doesn't use windows. That's about it.
In conclusion, JavaScript developers are agents of chaos. Within the last 25 years of web development, they have had to contend with belittlement from the programming community, browser wars, a war of libraries that turned into a war of frameworks that then turned into a war of Single Page Applications, that then turned into a war of what Server Side Rendering framework to use. It’s been a wild ride, and a lot of mistakes were made along the way, but JavaScript developers gain the benefit of keeping a fresh mind for new things and new ideas and its a good community to be part of. That said, if I have to learn another library for date-time conversion, I’ll give it all up to become a tree farmer.
DISCLAIMER:
No IP/Trademark/Product mentioned or not mentioned in this article gave me (or the company) any money to write this. They were chosen purely for relevance at the time in popular culture and nothing more.