Don’t blame me, I am “not” JavaScript
JavaScript has evolved over the years and behave differently on different browsers… Oh, wait! That’s totally not true, some of the JavaScript we write for browsers aren’t even JavaScript. Doesn’t make any sense? Keep Reading…
If we went back to around 2002, there were indeed different specification Implementations of JavaScript, but that changed around 2009 when the last versions of I.E(Version 8) running JScript (Microsofts forked version of JavaScript) went away and newer versions were created.
In 2011, when the TC39(the Ecma committee responsible for evolving and authoring the specification of JavaScript) released EcmaScript v5.1, they brought forth something called the one JS principle, this means that from that point forward, every major JavaScript engines, or anyone that's like a major player in the space of JavaScript(e.g babel) would have a representative on the TC39 team and that nothing would make it into the specification unless all of them agreed to implement it according to the specification, so if anyone of those major players disagrees with a proposal and refuse to implement it, it just would not make it to the specification.
This means that there would be different implementations of JavaScript, but they would all strictly comply with the specification and have a uniform behavior across the different engines.
You can read more about TC39 proposals from my article “Making JavaScript better (Ecma Scripts Proposals)”
In the above, it was stated that all major browsers, runtimes, or players in the JavaScript space have a say on what goes into the specification, but let's assert this even more.
There is a test suite of around 35,000 tests maintained by the TC39, these tests ensure or test that every single feature, syntax or implementation of the language conforms to the Ecma Specifications on different platforms like V8, Spider Monkey, Chakra, etc. Every test runs both in strict mode and non-strict mode. Additionally, before a proposal can make it to Stage 4, Test262 acceptance tests must have been written for mainline usage scenarios, merged and there must be two compatible implementations that pass the acceptance tests. You can find a visual representation of the test cases across different runtimes at test262.report.
Okay, enough said about the uniformity of JavaScript’s behavior across different engines. Why does it still seem like JavaScript behaves differently across browsers even though it is uniformly implemented across their runtime engines? That’s because the JavaScript that behaves differently across browsers isn’t JavaScript. Doesn’t make sense still? Hold my coke…
In JavaScript environments like Browsers, Node, Deno, there’s a lot of code we write that looks like JavaScript but isn’t actually the “JavaScript language”, we are actually interacting with platform API’s interfaced with JavaScript. Stuff like the Document Object, geolocation API’s, Web RTC, indexedDB, local storages, etc aren’t really JavaScript, we are just Interfacing with them using JavaScript-like syntax, they aren’t controlled or governed by the EcmaScript specification, in fact, most of them are actually written in C/C++. So the divergence that we see in browsers is a result of browsers(or runtime environments) not having a specification guiding non-JavaScript JavaScript implementations. JavaScript is actually way more stable than other web technologies because none of them have something similar to the one JS principle. Clearer now? Definitely!
So what features am I speaking of specifically? Because this does not seem to be a problem these days. I mean, we don’t have browser compatibility issues anymore(Except for IE), well the truth is, we do, but not like we used to. In fact, it isn’t completely true that all the issues associated with cross-browser compatibility are caused by browser-side JavaScript APIs.
Some very few examples of browser incompatibility issues in JavaScript
Slow/Early adaptation of proposals
Slow and, or early implementation of new JavaScript features that made it to the specification might pose some problems. A good example is the Numeric Separator proposal. When this proposal was still in stage 3, some major engines(V8, SpiderMonkey, JavaScriptCore) had already implemented it and shipped it with their latest versions(experimentally), even though it’s just on it’s way to the spec and not quite there yet. This can indeed make it seem like some browsers have a feature while some don’t.
Also, a proposal can only make it to the spec if at least it has been implemented and test262 compliant by major engines. This means, some engines might move faster than others in implementing new features, which might make it seem like there is a cross-compatibility issue when in reality it’s just a time difference in implementations.
Now the big question is why are engines even allowed to implement a proposal before it makes it to the specification? The answer is simple, proposals to JavaScript are actually more ‘open’ than we thought and are openly discussed on esdiscuss.org. Developers need a way to test these proposed features to contribute to the discussions, hence engines are allowed to experimentally support them before they make it to the spec.
Filesystem & FileWriter API
The Filesystem & FileWriter API allows the creation and reading of files on a user's device on the client-side. The API is currently only supported by Edge, Chrome, Opera, and SamsungInternet and is not supported by IE, Firefox and Safari. Here is a comparison chart on canuise.
Screen Orientation API’s
Have you ever tried to play a game on the web with your mobile and was prompted to change the orientation of your mobile device to landscape? That's the screen Orientation API! It monitors the state of the orientation of the screen and triggers an event when this state changes.
It is partly supported on IE, not supported on safari and fully supported on other major browsers.
Speech Recognition API
The speech recognition API allows you to incorporate voice data into web apps. It is currently only supported by Chrome, Samsung Internet, QQ, and Baidu browser.
Battery Status API
This API provides information about the device's battery level and emit events when the battery level changes or the state changes to charging. It is currently supported by all major browsers except for IE, Firefox and Safari/IOS.
The above gives a sense of how certain browsers can have certain APIs(which seems like JavaScript) and others would not. If we take a look at the specification of the Document Object Model, we would notice that all the Fundamental Interface code samples given are strictly in C++ and not JavaScript as It might have been perceived to be. If you take a look at the source code of chromium, you would notice that stuffs like webRTC, media, are all written in C++.
Conclusion
So yeah, browser-compatibility issues can't be avoided but there are ways in which they can be solved(polyfilling, transpiling) which I won’t cover in this article(would hopefully write about it in the future). But hopefully, you now have a good sense of what causes them and know better than to blame JavaScript or more importantly blame Web API’s. Don’t blame them, they aren’t JavaScript😁.
If you enjoyed reading and most importantly learned from this, kindly drop an applause, I’d love the attention!
