Very few technologies are as integral to the internet as we know it today as Javascript. While there are dozens of backend solutions — from the buggy and traditional PHP to relative newcomers like Python and Node.js — there is only one scripting language for frontend development.
It doesn’t matter if you are using a transcriber or avant-garde alternatives like PyScript. Everything, in the end, has to be translated to Javascript to work on browsers. For better or worse, this means that every web developer needs at least a passing familiarity with the language.
There are a plethora of Javascript frameworks in the wild, from the almost universally famous Angular, React, and Vue.js to the less common but just as interesting Meteor, Mithril, or Polymer. Many of these solutions are for more than just frontend. For example, the aforementioned Node.js has quickly become one of the most user-friendly and popular runtime environments on the market.
If it feels like too much, well, that’s because it is. The lifecycle of both Javascript and its many derivatives is headache-inducing, but there is a reason behind it. Why does it happen? And what are the implications for our projects? Before we answer those questions, a short history lesson.
The Birth of Javascript
Back in the ’90s the World Wide Web (what we used to call the internet) was a very different place. The idea of dynamic web pages was limited to a visit counter at the bottom of the page that would go up every time someone visited a website. In other words, the web was static, and Netscape wanted to change that.
Netscape worked in tandem with Sun Microsystems to embed the Java programming language as a scripting solution to their flagship web browser. Java was all the rage at the time. It was popular, powerful, and, above all, revolutionizing software development by pushing object-oriented programming to the forefront.
At some point down the line, Netscape executives decided that it would be better to create a new language instead of relying on a license from a third party. So they gave the project to Brendan Eich, and 10 days later, JavaScript was born. Yes, you read that right: 10 days. JavaScript was officially released in December 1995, and a year later Netscape submitted it to Ecma International as the starting point for a standard specification that all browser vendors could conform to. The rest is history.
By 2022, 98% of all web pages used some manner of JavaScript. That same hodge-podge of a language that was built in 10 days had grown to become a massive juggernaut in web development. But as we will see, the process was anything but simple.
Early JavaScript, jQuery, and AJAX
JavaScript has always had a reputation for being buggy and quirky. And to be fair, that’s not entirely wrong. While the language has advanced a lot in the last 20 years, many of its faults can be traced back to its early days and the rushed development cycle it went through. Credit where it’s due, Eich pulled off an impressive engineering feat, but some things can only be ironed out with time and testing.
The language is inefficient, unstructured, and inelegant. It has competing paradigms inherent to its design and overlapping features. It’s horribly verbose for some things and rather tame in others. But it did solve a big problem, and thanks to a very invested community it found its place in the tech industry.
JavaScript was saved in many ways by one of its most popular libraries, jQuery. This little project simplified JavaScript and provided solutions for things that developers were struggling with, including AJAX, a set of web development techniques that uses various technologies on the client side to create asynchronous web applications.
If anything, jQuery served as a rallying call to developers. It gave a common ground for paradigms to form around web development, and it was so successful and convenient that even to this day it is used by more than 70% of all web pages. So, how did we go from this rather stable paradigm to the lifecycle crisis we are living in today?
JavaScript After the 2010s
JavaScript has never stopped growing. In fact, most of the things that jQuery did in the beginning are now part of regular JavaScript. Since ECMA6 in 2015, we’ve been getting yearly revisions, from small changes to huge additions like async functions. If anything, this points to the fact that the JavaScript ecosystem is dynamic and ever evolving, to the point of almost not caring about stability.
JavaScripts frameworks, especially the most popular ones, are famous for getting new revisions. Angular, for example, has had 14 revisions in its 10 years on the market. Vue.js? 19 revisions in 8 years. React has had 18 versions from 2013 to 2022. In contrast, C++ has had 6 major revisions in 20 years. The disparity is obvious.
This growth goes in tandem with the increase of computer/smart devices’ processing power as well as the capabilities of web browsers. Simply put, it’s a self-reinforcing loop: more refined browsers push for more elaborate frameworks, and in turn, this pushes for better browser technology.
There is also the matter that JavaScript cultures seem to focus on following current trends, favoring new technologies over proven solutions. A look at framework trends from StackOverflow shows a decline in framework interest after only a couple of years with only React keeping a steady growth from 2016 to 2022.
The revision treadmill is certainly addictive. It’s easy to be excited by the hot new thing without realizing what effects it will have on our products. This is especially true with deprecations. While most companies are wise enough to carefully go over the documentation before implementing an upgrade, it’s easy to miss a line or two. The end result? Suddenly the code is no longer compatible with the framework.
What It Means for Your Business
On one hand, having such a huge and energetic community is amazing. The ecosystem has spun out of control and we are now seeing just how powerful JavaScript and web apps can be. On the other hand, JavaScript fatigue is real. Developers are feeling stressed, burnout, and frustrated because it’s extremely difficult to keep up with all the changes in the ecosystem in such a small time frame.
Do you really need to keep up with the latest release? Maybe. The only piece of sound advice I can give at this point is to understand that not every change is good and that new revisions always involve retraining to a certain degree. Don’t jump on the bandwagon when your current solution is yielding results. In other words, think before you leap.
