This article attempts to be a conceptual introduction to the history of JavaScript as opposed to a full-blown tutorial. There are already many more focused and thorough tutorials out there than what I will attempt on this blog. Instead, I will focus on knowing how to use the language, its nuances, its strengths and dig into the particulars that tutorials will generally not explain. My goal is to help with a more in-depth understanding of the language, its’ features, and direction today.
History of JavaScript
JavaScript has had an intriguing history. It has risen through the years to be the king of web front-end development and is inching its way into server-side and application development (through Electron, React Native, etc.). I’ve seen over the years numerous professionals that laughed and thought JavaScript would die out.
Tech giants like Microsoft thought they could easily roll their competition to the language and take the market (VBScript and Silverlight). Inevitably today, JavaScript stands tall and reigns supreme, now looking to stretch itself out into other software development spaces beyond the web front end. Now no one laughs.
We can define the success of any thought or idea based on its’ general “market share,” and JavaScript growing market share is indisputable (especially for the front end).
JavaScript is a programming language that, as of today (in the mainstream), only runs on top of established JavaScript interpreter engines. Some of the most common ones are built into browsers themselves. (For example, Google V8, Safari JavaScriptCore, Firefox SpiderMonkey, etc.) Another popular engine that can run without a browser (giving a much more broad range of applications) is Node.js.
Also growing in popularity is Facebook’s Hermes engine used as apart of React Native. All of this gives JavaScript more capability to run in more spaces than just the web front end. Still, its’ origin and current strengths are geared for the front end.
Flaws of the interpreted languages
It is essential to point out a critical flaw of JavaScript. It is an interpreted language. By nature, this code needs to be interpreted at run-time in plain text. (This means large code bundles.) The interpreter is an optimized program that translates the code’s intention to actions that the underlying machine understands. Using an interpreter will ALWAYS be “slower” than talking directly to the machine, such as C, C++, and Rust languages support. Not to give a pitch that you should go and start doing everything in C, C++, and Rust; Javascript is fast enough for what it needs to do well.
You write your code. Then use a compiler that packs the code down to “machine code.” Machine code runs straight on top of the OS and can be used directly on the processor. The JavaScript interpreters are good for the front end. However, you probably wouldn’t want to rely on an interpreted language for solutions requiring intense mathematical equations—for example, 3D graphics and scientific model computations.
At least not yet… JavaScript a language, and the fact that it often runs on an interpreter today is only detail for today. There could well be a day when someone builds an optimized compiler for JavaScript to translate it into machine code. The language would need to expand to support this, as more control over memory, threading, and lower-level operations would need to be supported.
Getting closer to the machine
Something more realistically sooner than later would be that JavaScript may follow Java and C #’s path. Where JavaScript doesn’t compile down to machine code but “byte code.” Byte code is still interpreted but has a smaller pack and pre-optimized. It could be packed and bundled much smaller than it is today. Byte code instruction is also much closer to the machine (and thus needs less pre-processing, making it faster).
This byte code “revolution” is already happening to some degree in browser interpreters. V8 from Chromium and SpiderMonkey from Firefox are performing intense optimizations with JavaScript. They can receive plain JavaScript code, compile it to byte code, and then utilize the “Just In Time” (JIT) compilation on the byte code to optimize run time performance. There is a drawback to this, though. It is more work upfront making potentially slower load times of your JavaScript application (in exchange for a faster -run-time).
This is why I mention in other previous articles the importance of code splitting. This allows control over the interpretation of the code bundles on these interpreters. It is crucial to user-perceived performance. It is also worth noting that Node.js also uses the V8 engine and will take advantage of these features.
The landscape is changing fast. I can see one day where websites deliver byte code or even machine code directly to the browsers. These will pass through straight to the machine. This allows JavaScript applications to receive great performance gains, memory usage and improved run-time efficiency. It will also require us to start compiling our JavaScript. Some of us already compile our JavaScript using Babel and Typescript, so you are already prepared!
The future directions of web front end
Also worth mentioning is Web Assembly (WASM). WASM is a capability being implemented by browsers. It promises to allow machine code to be delivered and ran directly on the browser engine. While JavaScript doesn’t have much mainstream capability to compile to machine code. Other languages that already compile to machine code or even byte code can now start running natively using WASM! I imagine it won’t be long until JavaScript also starts competing in this space through a large party or open-source support. We will have the capability of using JavaScript through the entire Operating System (OS) stack. In the meantime, WASM has exposed API points to work with JavaScript today.
ECMA Script and its influence on the evolution of Javascript
I wouldn’t say I liked JavaScript, I thought it was slow, and the language is hard to read. After embracing the language over the last couple of years, I’ve done a 180-degree turn. Now I choose to specialize my knowledge in the web front end, where Javascript is the centerpiece. I even prefer the language for web front-end clients (with Typescript).
I genuinely believe the future landscape is strong for JavaScript, and it certainly is capable of taking more of tech space as the most dominant language. Do note it is far from perfect; the state of the union mentioned above is genuine. However, the community strength around the language is loud and booming. It is only time until the big issues are improved or removed by the community.
It is up to the community and the ECMA to grow the language and take on new market space without making the language overly convoluted. (ECMA is the organization controlling the ECMA Script standard. ECMA Script defines the direction for JavaScript to follow.)
I will dig into more detail in various bits in this article in future articles. Let me know what interests you in the comments!
