JavaScript/Compatibility

From Wikiversity
Jump to navigation Jump to search

The JavaScript specification (ECMAscript) is continuously updated. Occasionally, new methods and syntax are added that simplify the code. For example, template literal strings with backticks (`) were added in 2015,[1] the .replaceAll() method that facilitates text replacements across an entire string was added in 2020, and optional catch binding approximately in 2018.[2][3]

However, using such new methods would break compatibility with any version of web browsers released prior to the addition to the specification does not support the method. As such, it is not wise to quickly implement new JavaScript methods shortly after addition to the specification. Web developers need to be considerate about how long to wait until implementing new JavaScript methods to their site.

That does not mean that some features can not be implemented. Workarounds known as "polyfills" can be used to replicate the behaviour using existing methods that are supported in earlier browser versions. For example, .replaceAll() can be replicated by code which replaces each occurance of the specified string individually and checks if the string still exists using a for or while loop, until the string is no longer found. The .includes() method can be replicated using .search() and .indexOf(), which have been part of the specification for much longer.[4]

Error handling[edit | edit source]

The reason execution of JavaScript stops at any unsupported command (unless it is inside a try-catch statement where it dodges the error by running an alternative code snippet specified by the developers) is to prevent unpredicted situations from occurring.

It is somewhat comparable to traffic lights at a road crossing. If all lights are red, the vehicles do not move and nothing happens. If all lights are green simultaneously, there is a risk of a collision.

JavaScript is the most frequent cause for compatibility breaches in web browsers. In terms of compatibility, it is the weakest link in the chain of the three major web technologies (compared to HTML and CSS). If new features are implemented in HTML and CSS without regards to browser compatibility, at worst the layout of the site appears somewhat broken, but it remains largely useable. In fact, many of today's HTML-based web sites including Wikiversity could technically be browsed in early 2000s browsers if sites did not require more recent versions of TLS (Transport Layer Security).

If JavaScript features are used without workarounds being implemented for earlier versions, this causes an error, which terminates the execution of the script to prevent unexpected behaviour. On sites that are entirely JavaScript based, such as photo sharing sites Imgur and Instagram (as of 2022), no conent appears at all.

Case studies[edit | edit source]

April 2022

The following is a case study to test the compatibility of major sites on old browsers.

The browser used for this experiment is over seven years old as of writing. In particular, it is the mobile browser Samsung Internet 4.0, which has the browsing engine of Google Chrome 44, released in July 2015.

YouTube[edit | edit source]

As of writing, both YouTube's desktop and mobile sites are, presumably with the help of lots of polyfills, still supported. The performance of the mobile site is acceptable. But it is expectably just borrowed time and the compatibility could be deprecated any time, since other sites such as Dailymotion no longer support Chrome 44 anymore.

Performance on the desktop YouTube site is not that good, possibly because it is heavy. Also, the "YouTube" text of the logo appears blue, and red while pressed (active), meaning it behaves like a hyperlink.

Twitter[edit | edit source]

The web app is still supported in Chrome 44. Even their custom pinch zooming in the image viewer, although it takes somewhat longer to load than on newer browsers.

Dailymotion[edit | edit source]

A blank page appears.

Their embedded player shows the following error:

Dailymotion no longer supports your Internet browser. To continue, please update your Internet browser or try using a different one.

When deactivating JavaScript, the home page shows no warning while the embedded player instructs me to enable JavaScript, meaning they put more consideration into the embedded player than the home page.

Dailymotion still worked with Chrome 44 around 2020. The player interface has visually not noticeably changed since then. But looking at their code, their video player alone is 500 KB of minified JavaScript. Somewhere in that 500 KB, there is something that Chrome 44 does not support, and that made the entire thing inoperable.

Vimeo[edit | edit source]

Channel pages appear blank and only the top bar is visible, both with and without JavaScript. This means JavaScript failed to execute on the channel page.

However, with JavaScript activated, watch pages still work, and videos are playable.

With JavaScript deactivated, the watch page still shows and a thumbnail is displayed in place of the video player, which is a graceful degradation. The notice instructing the user to enable JS is partially covered by the top bar.

Conclusively, YouTube outlasted both Dailymotion and Vimeo, as well as some alt-tech platforms in browser support.

Sites using plyr.js[edit | edit source]

Plyr.js makes use of catch without binding since 2020 or 2021, and as such is also no longer supported in any pre-2018 browser. Though, it may fall back to the browser's default HTML5 player.

However, sites that use a splash screen that is removed by JavaScript (e.g. alt-tech video platform "BitChute") get stuck on that splash screen, since JS stops at the error. Another video platform, "Brighteon" is navigable, but no player loads.

VidLii[edit | edit source]

Works fine, since their JS-based player is not so complicated.

Tracle.TV[edit | edit source]

Navigation works, but player shows an error thinking JavaScript is deactivated.

Instagram[edit | edit source]

Instagram uses the React JS framework. In the test, it gets stuck on the splash screen with the light grey camera logo.

Wikipedia / MediaWiki-based sites[edit | edit source]

Since MediaWiki enhances progressively, it works well, including the JavaScript-based mobile editor overlay and the visual editor work. The only visible flaw is that the "Loading editor..." text of the mobile editor overlay is too far up, but that is trivial, since it does not affect function.

Everipedia[edit | edit source]

Like Instagram, Everipedia uses React JS, and behaves similarly accordingly. The browser's loading bar gets stuck indefinitely at around 90%, and no content appears. The loading never finishes.

SoundCloud[edit | edit source]

Both desktop and mobile front ends work fine in Chrome 44, though the desktop site has somewhat poor performance.

JW Player[edit | edit source]

August 2022

The JW Player, a JavaScript-based user interface, is used by the Internet Archive for its audio and video library. On item pages, the player does not appear in Chrome version 72, which was released as recently as 2019. However, since the archive serves its item and file listing pages as static HTML, the multimedia files can still be navigated to and played back through the web browser's integrated multimedia player. The same can not be expected from other sites.

Resources[edit | edit source]

See also[edit | edit source]

References[edit | edit source]

  1. Template literals (Template strings) – MDN web docs
  2. String.prototype.replaceAll() - JavaScript | MDN web docs
  3. JavaScript statement: `try...catch`: Optional catch binding | Can I use […]
  4. String.prototype.includes() § Polyfill - JavaScript | MDN web docs