ECMAScript, specifications for JavaScript development
Remember when Ryan Dahl introduced Node.js runtime environment to the world in 2009? Frontend devs suddenly became full stack developers overnight! Well that's a hyperbole, but it works on LinkedIn. But very few of them understood how it all happened. How do you think Ryan came up with this idea of using Google’s V8 engine, which was released in 2008? Because he knows JavaScript and the machinery behind its execution, because of which he could co-relate V8’s event-driven and non-blocking I/O features and leveraged them to do efficient server side scripting. This greatly improved the backend server efficiency around the world.
JavaScript is one of the most popular programming languages around. Most coders have used JavaScript at least once in their careers. A lot of us were introduced to JavaScript as a language for "web browsers". Indeed, Web 2.0 was enabled by JavaScript. But today, the adoption of JavaScript as a programming language has become widespread in the form of a language used for backend programming, building databases, and even IoT!
How many of us know about how the JavaScript language is evolving today? Who maintains it? How are new language syntax, semantics, and features introduced? Beyond the web, where is JavaScript actually used, and where can it be used?
I will attempt to explore these questions in this blog post, and hopefully you will end up with a deeper understanding of the JavaScript language itself. Think of this blog post as JavaScript BTS, that takes you to the origin point and offers a glimpse of all the infrastructure and machinery that is constantly working to keep the language up-to-date. Hopefully, you will have a newfound appreciation towards JavaScript. Maybe, it will completely change the way you look at JavaScript and other programming languages as well.
History
Before 1995, the internet was static. Imagine visiting a website built in just HTML (CSS was formally introduced/published in Dec 1996), and styled with tags and attributes like <font>, bgcolor, align, etc. The webpage would load on your browser, and you could read the contents. That’s it, no sign-in/sign-up, no forms, no dynamically loaded data, no interactive form elements.
Brendan Eich in 1995 created JavaScript to add dynamic behavior in these webpages. Well of course, it went through several iterations and thus several different names before it was submitted to ECMA (European Computer Manufacturers Association) International for standardization, which led to the formation of ECMAScript which is the language specification, in 1997. ECMAScript specification is maintained by the TC39 committee, which makes sure the specifications are general purpose, cross platform, and vendor-neutral.
Note that ECMAScript is a language specification and it does not provide any suggestions or hints about whether to create the real world implementation to be used in a browser or backend server.
Implementations
For a long time after the specification was published, ECMAScript was implemented mainly by the browser vendors for building their versions of JavaScript engines. For example, Google Chrome uses V8 engine, Mozilla Firefox uses SpiderMonkey, Safari uses JavaScriptCore (Nitro), and so on. These engines are essentially the implementation of ECMAScript language specification which define and drive the syntax, semantics, and features of JavaScript language - which developers use to develop websites.
There are also other dialects and variants which adhere to the ECMAScript, but impact how the code is written in JavaScript. For example, TypeScript developed by Microsoft defines a type-system over JavaScript, which otherwise is a dynamically typed language. CoffeeScript is a language that compiles to JavaScript that adheres to ECMAScript and facilitates developers familiar with Ruby to develop web apps.
To look at it with a different perspective - if you want to build your own JavaScript engine, it has to adhere to ECMAScript specification. Why? Because JavaScript engines are typically developed by those who want to develop their web browser. If you want all the websites in the world to run on your browser, you have to comply with ECMAScript.
It's not just the browsers which implement ECMAScript specification. There are backend runtimes which also directly or indirectly adhere to it, and enable usage of JavaScript programming language to develop backends. Some indirect examples are Node.js and Deno which use V8, Bun uses JavaScriptCore as part of their backend runtime environments.
Some examples of direct non-browser implementations of ECMAScript specifications are:
QuickJS: used in CLI tools, IoT, or embedded applications with full compliance.
JerryScript: used in IoT devices and embedded systems with minimal compliance.
MuJS: used for scripting in PDF tools, lightweight applications.
Duktape: used in game scripting and embedded systems.
If you have never imagined JavaScript to be used in embedded systems, these are the projects to look for.
Is adherence necessary?
Having said that, JavaScript implementation **need not** adhere to ECMAScript specifications. Specs are a choice. You can still write programs in JavaScript and make them run anywhere, as far as you write/have a way to execute it. That way could be browser/backend runtime environment created by orgs or yourself. This is an important point. It basically means JS is a medium to enable development through human developers. It doesn’t matter how the code is executed during runtime.
In fact, a lot of embeded devices do not have enough resources to support the ECMAScript specs. But somehow the job needs to get done anyway. So using the “coding” talent available to move the business forward makes sense. Perhaps this might apply to all the programming languages available today.
If the ecosystem of devs is proficient in low level programming languages like C/C++, the businesses won’t need to got into this toolchain of higher and lower languages. Very few languages would have emerged.
Conclusion
This blog post is like a primer before you delve into JavaScript. If you take some time to go through links I have provided above to understand the origins and maintenance workflow of the language via ECMAScript standards, various browser engines, and non-browser implementations - you will have a deeper confidence when learning JavaScript. I am not saying read each and every word in the literature above, but at least get a sense of what it is. Perhaps make sure you have answers to the questions below.
What is ECMAScript?
How is JavaScript executed by web browsers?
Can JavaScript be used anywhere else without adhering to ECMAScript specs?
What are some non-standard implementations of JavaScript?
What other possibilities can you think of with JavaScript? Feel free to write to me about this.
It is always better not to be clueless about what you do.