The (Reverse) Redemption Arc of JavaScript

If you are a regular in the IT industry, chances are that, at some point during your hyper-productive daily routine of scrolling through internet junk, you stumbled across one of the countless JavaScript memes that inhabit the Interwebs right now. Yeah, I’ve seen them too, and I’ve seen them all. But even if it is considered a literal meme in the community, JavaScript currently stands as the most commonly used language in the world with 69%. Nice. However, this was not always the case, so today we are going to dig into how, and most importantly, why a scripting language is dominating the programming landscape in 2021.

Traditionally, a redemption arc is a storytelling device where a character who is evil and destructive atones for their flaws and overcomes them, transforming from villain to hero. However, given the circumstances and the love/hate relationship the community developed towards JavaScript (or perhaps, its notorious developers?) over the years, it’s up to the reader’s heart to determine whether it ended up as the villain or the hero ❤.

Do you want sugar with your Mocha?

No, I am not talking about the excellent JavaScript test framework (which you should totally use in your projects, BTW). I am talking about Mocha from 1995. That’s right — Mocha was the initial name for what would later be known as JavaScript.

It all started with Brendan Eich, who was employed by Netscape Communications Corporation in 1995 for the sole purpose of implementing Scheme (a dialect of the Lisp family of programming languages) into their upcoming browser — Netscape 2.0. You see, back in the ’90s, the internet was an unspectacular place. Not much was going on and the most exciting thing you could come across was a picture. Of anything. Naturally, the folks over at Netscape thought they needed some kind of goo to help them make the browsing experience a bit more exciting. Java was THE Michael Jordan of programming back in the day, but it was considered overkill for the simplicity and ease of use they were looking for. They wanted a scripting language that would interact with the DOM, be as simple as HTML and CSS, and resemble the syntax of Java. Thus, Mocha was born.

You’re a wizard, Harry

Mocha inherited the functionality of Scheme (well, most of it), the object orientation of Self (it had objects, OK ?), and Java’s syntax. It took Eich ten days to develop it. Ten. Days. Let that sink in for a minute. That sure explains a lot. The name Mocha was not exactly long-lived, since it was renamed to LiveScript shortly after release. A few months later, in agreement with Sun Microsystems, it was renamed JavaScript.

In 1997 the European Computer Manufacturer’s Association, also known as ECMA, inducted JavaScript into its Hall of Fame, meaning that it complied with their ECMA-262 standard. Long story short — it’s a JavaScript standard meant to ensure and standardize the exchange and use of information of web pages across different web browsers. It would later be known as ECMAScript as a result of compromise after a lot of naming dispute drama involving Microsoft and Netscape. Fun fact: Eich hated the name, as he thought it sounded like a skin disease. The more you know.

Roads? Where we’re going, we don’t need roads

In its early days, JavaScript was used to accomplish what CSS does today with ease — menu drop-downs, scrolling text, mouse hovers, etc. It was a simple scripting language. So, to truly understand the further development of JavaScript, you need to understand how the web worked back in the day. Duh.

Any user action such as clicking on a tab, submitting a form, or expanding content would require the server to process that event and load a new page, which was super inefficient. All page content disappeared, then the new page appeared. Each time the browser reloaded a page because of a minor change, all of the content had to be re-sent. This placed additional load on the server and made bandwidth a limiting performance factor. Honestly, from a mental standpoint, I don’t know how they did it. I get itchy about the sole thought of it.

Since Internet Explorer was the undisputed king of browsers around the early 2000s, Microsoft introduced a new library in one of their releases. They were developing it internally for their first web product — Outlook and conveniently called it the XMLHttpRequest object. A lovely name, I know. This library was used to send, receive and request data from a server in the background, allowing the web page to update specific information via JavaScript without having to reload the entire page. I cannot stress how important this was on a broad scale of things, as it allowed for a whole new generation of web apps — SPA’s (Single Page Applications), with Gmail in 2004, and Google Maps in 2005 being the more prominent ones that adopted this concept early.

One language to rule them all…

All of a sudden, the term AJAX started popping out of thin air. No, it wasn’t the football club, but what was it? Could you eat it? It turns out it wasn’t a candy bar, but a broad group of Web technologies that were used to implement Web applications that communicate with a server in the background, without interfering with the current state of the page. Close. It’s an abbreviation of Asynchronous JavaScript and XML, and it truly was what enabled JavaScript to step on to that next level. It incorporated HTML and CSS for presentation, JSON or XML for data exchange, the XMLHttpRequest object for asynchronous communication and JavaScript… Well, to bind them. Thanks, Frodo.

Maybe you’re not a wizard just yet, Harry

Not long after AJAX came to prominence, the first problems started to arise. It would appear that JavaScript wasn’t mature enough to handle large-scale applications easily, or any application at all. Ya boy wasn’t ready. Subtle differences in web browser implementations made it a nightmare to maintain any kind of project. The world needed a solution, and it needed it fast. Enter: Frameworks.

PrototypeJS, Scriptaculous, and MooTools were the pioneers that abstracted much of the functionality developers wanted into a clean and easy-to-learn framework. The most prominent of them at that time was jQuery. When it launched in 2006, its popularity skyrocketed immediately. Later adopted by Gmail, jQuery showed larger applications could be built with relatively easy maintainability, but even then it was clear — more enterprise-friendly tools were needed.

Y’all got any more of them frameworks?

All upcoming frameworks tried to build on what the previous ones were good at, and add on what they were lacking. Backbone was the first framework whose sole purpose was to build SPAs, and it fixed one of the biggest flaws jQuery suffered from — selector and handler hell. But it wasn’t until Adam Abrons and Misko Hevery created AngularJS that the world would see a complete architecture for front-end application development. Later on, Hevery took a job at Google and conveniently brought the framework with him. I wonder if his internship was free or paid.

Alongside the ability to build components for re-use, one of AngularJS’s main features was bi-directional data binding, meaning that it provided a way to bind a model’s data to HTML markup, enabling real-time DOM updates. Sorcery. Knockout and Meteor were frameworks that followed and provided similar features, but it was nowhere near what AngularJS had to offer at that time.

In 2013 papa React came around and we all know how that went. Although, its developers don’t want you to call it a framework, but rather a library. Yes, let’s go with that. So, the library that’s called React immediately took the spotlight as it was developed by Facebook, and quickly became a crowd’s favorite. It was well documented, fast and efficient and it introduced something called Virtual DOM, a concept that would prove to be crucial in building snappy Web apps with even faster and more precise data updates. And spoiled JS developers. It had a steep learning curve, but it would reward anyone who mastered it with its immense powers.

Can your programming language do automation, build web apps, mobile apps, IOT apps, restful APIs, CLI programs, and AI projects?

Didn’t think so.

I feel like somewhere along the journey someone started asking this question for JavaScript, and didn’t rest until the answer was affirmative. Node.js played a crucial part in this by developing an open-sourced, cross-platform JavaScript run-time environment that lets developers write command-line tools and server-side scripts outside of a browser. Later on, some folks thought it would be cool to make mobile apps writing JavaScript in the form of React Native. Why not? Google even ported TensorFlow, its end-to-end open-source platform for machine learning, specifically to JavaScript.

Devs were so preoccupied with whether or not they could, they didn’t stop to think if they should

But why shouldn’t they? Why shouldn’t JavaScript do it all?

JavaScript is being developed and further optimized via EcmaScript convention updates, and throughout the years it transformed into a mature language. It is super-fast and client-side, meaning it inherently reduces server load. It works very well with other programming languages as you can include it on any web page or inside the script of another programming language. Also, JS is everywhere and very accessible. Everyone can start typing JavaScript in their browser right now.

Type Coercion (a topic I will cover in-depth in another article), and on top of being loosely typed, means that JavaScript is very forgiving and easy to pick up for beginners. This further increased its appeal, and in the end, that is ultimately why it became so popular and why everyone is racing to integrate it into the next big thing. It’s an upward spiral that, as long as the market is in demand for specific kinds of projects that cater to the average JS developer (and that’s a hefty chunk of them), will probably continue to trend up.

So in conclusion, JavaScript is everywhere because it’s easy and forgiving to learn. It’s that simple. It is and will be a skill that will render you highly employable in virtually every market across any industry. That’s a fact. Whether or not that’s healthy for the current programming landscape is up for debate, but on another occasion.