Why JavaScript Sucks! (for now…)
A Brief History
JavaScript first came out in the mid 90’s. Sometime between 1995 and 2000 this language became very popular. Even from the beginning, the naming of JavaScript confused the hell out everyone! (first named Mocha, LiveScript, and finally JavaScript possibly due to Netscape closing a deal with Sun Micro to include Java JDK in Netscape’s web browser). However, this is not where the confusion ended.
Imagine you travel back in time to 1995 and learn Mocha/JavaScript. Then you jump ahead 20+ years and try to write a modern program using the language you knew and loved. It would be like Chaucer trying to write a Medium article today. It would be practically impossible, as would climbing a mountain which face constantly changes.
Words & Grammar
The “guts” of the JavaScript language from roughly version 1.1 (pre-ECMAScript) included only these (used) keywords:
- break
- continue
- delete
- else
- false
- for
- function
- if
- in
- new
- null
- return
- this
- true
- var
- void
- while
- with
This list of only 18 used keywords (circa 1996) is compared to 34 from the ECMAScript 2018/ES9 language specification (in strict mode, let and static are also considered restricted keywords — bringing the total to 36). This means from solely a “used” keyword standpoint, the language has doubled in 22 years.
To put this in perspective, the current English language has at least 250,000 distinct words (Global Language Monitor says 1,000,000+). The average estimate is 750 new English words added per year; 16,500 words in 22 years or at most 6.6% was added to the English language in 22 years. By comparison, JavaScript doubled the language or 100% was added in 22 years (only considering used keywords). Once concepts such as Promises or Classes (both added in ES6) are counted, the JavaScript language of today is almost completely different from the original specification.
Engines & Environments
Prior to 2000, there were only a couple JavaScript Engines (a program or interpreter which executes JavaScript code) in use with the majority of the code being used for client-side browser implementations. JavaScript server-side scripting and other JavaScript server implementations were capable in 1996, but they were not adopted in the mainstream. In mid-2000’s, the engine race had begun. The outcome of this race had a huge impact on the landscape of engines & environments leaving SpiderMonkey, Rhino, V8, Nitro, Chakra as the predominant engines and Node.js as the new run-time environment on the block.
We are still experiencing the fracturing effects of the engine race. From this point on, front-end developers had to keep track of several engines and the specific JavaScript version they were implementing. This became painfully apparent as the version went from ECMAScript 2009/ES5 to ECMAScript 2015/ES6. Any code written in ES6 and loaded into a browser without support for this version would not work. It has taken until 2018 for the majority of engines and therefore browsers to support ES6 (see compatibility tables here).
Because it takes a long time for browsers to implement the new specification standards, tools started popping up like Babel, Browserify, and Webpack in order to transpile the code for all browser’s use (bundle, and compile, and a lot of other crazy stuff). However, none of these tools were really possible until Node.js and Node Package Manager (‘npm’) came into the picture.
‘npm’ allowed code to be versioned and reused by everyone. Packages were made accessible so we don’t need to reinvent them — just perfect them with debugged new versions (haa!). Other than Linux package managers, npm is probably the best know and largest .
800K+ packages
4B+ past week downloads
24B+ past month downloads as of 28/Sept/2018
The problem is, npm began as a Node.js package manager — meaning the code was written to work as Node.js package modules (and many are Node.js version specific). Even today, it is not possible to call packages and have them work in every Node.js version, every JavaScript engine, every browser, and every environment. It requires (pun intended) the use of tools like Babel or Webpack in order to bundle the code in such a manner which will work in the intended environment.
There are so many great tutorials, videos, and code samples on the web for JavaScript and all the many frameworks/libraries available today. Unfortunately, it has been my experience very few of these reference the exact version, environment, or engine the code is meant to run on. The confusion is astounding. Sometimes it takes trying multiple code samples/packages before finding the code that works as intended in the particular development environment. After going through this hell several different times, we finally start understanding which code is which, and read through it with the knowledge of whether this will work in our particular development environment or what we need to do to it to make it work.
Frameworks & Libraries
Frameworks and Libraries are by far the most specialized “packages” in the JavaScript ecosystem. If you think JavaScript was not meant to do a certain task, I guarantee there is a library or framework which will do it! ‘jQuery’ is one of the oldest and well known libraries for JavaScript. It is difficult to search Stack Overflow without answers popping up referencing the jQuery way of doing something. Without jQuery, it used to take multiple exhaustive lines of pure JavaScript to duplicate the same simple jQuery code. As the ECMAScript versions keep proliferating (and browser support is becoming current), jQuery is becoming an older dialect in some respects. JavaScript is not as verbose as it used to be and many Stack Overflow threads will ask “how do you do this jQuery with pure JavaScript instead?”
Angular and Vue.js are two of the true JavaScript frameworks not shy about being called a framework. These are application specific libraries and tools meant for producing user interfaces and developing single-page applications. They are like hardware stores who stocks dimensional lumber from mills who churn out 2x4’s, drywall from manufactures who produce 4x8x1/2 panels, and other standardized building materials so buildings can be built in a normalized way. But like building standards, these frameworks constantly change, sometimes requiring weeks or months of study in order to learn the new version.
Nowhere is this more true than the “Don’t Call Me A Framework,” library/toolchain/framework Polymer. To be fair, the Polymer Project has done a great job at pushing the web “industry” towards the realization of what the modern web can be. The current web assessment is better in their words:
From a user point of view, too many mobile web apps launch slowly, perform poorly compared to native apps, and don’t work at all when network conditions are poor.
For app developers, the web platform has been frustratingly slow to evolve. For years, we’ve had to plug holes in the platform and build layers on top of it to meet basic needs like defining components and loading modules. (from About: Why #UseThePlatform)
Polymer project has done more to attempt to fix these issues and provide the necessary learning experience (bumpy as hell!) than any other initiative.
However, if you have been on the wild ride from Polymer 0.5 to Polymer 3.0, I bet you have the scars to prove it. It is not surprising that a Google project would turn on a dime since they are usually at the technological forefront. This transformation from Polymer 0.5 through Polymer 3.0, and now onto the up-and-coming Lit-Element completely illustrate the pain caused by ES6 and HTML 5 (assisted in completely redefined the DOM and added other API’s such as Service Workers). JavaScript has gone through a major, painful evolutionary process because of HTML 5 and subsequent additions. The developers caught in the middle of this evolution and the clients/bosses wanting tangible results are collateral damage.
Climbing The Mountain
JavaScript has changing words and grammar. The interpreters and environments are completely different, ever-evolving, and frustrating. The bumpy library/framework ride will bruise your soul and can leave your spirit on life-support. Yet, it is difficult to imagine a world without JavaScript and its ecosystem.
Let’s face it, change can really suck. For those trying to learn JavaScript in 2018, I feel for you. Good languages and toolsets don’t come easy. ESM support may be our salvation, but it may be just another adjustment until we get where we are going. Thankfully, there are initiatives such as Webpack and Polymer Project out there trying to make things easier.
Bottom-line, navigating JavaScript is more about writing code. It is about understanding the complex ecosystem, how it has changed over time, and where it is heading. If we can understand this, developing awesome apps isn’t so bad. Without the new complexities, JavaScript would not be as powerful as it is. Without change, the web will stagnate and die. Understandably, with change comes additional challenges.
Nothing worthwhile is ever easy…
