Keeping up with JavaScript

As new versions of JavaScript are introduced the commands available to use in your scripts increases. This is because the number of new objects, methods and ways of coding your JavaScript are greater than the number that are marked as obsolete. This makes it easier to write far more sophisticated scripts using less code that will therefore run faster in the browser because more is done by compiled code for each JavaScript statement.

Old JavaScript will continue to work in the browser because the browsers don't want to break web pages by dropping support for antiquated code that is still common on the web. That's why the commands are marked as obsolete rather than deprecated (since deprecated also implies that the commands will be removed in the near future). In order to be able to further develop JavaScript without being tied down by antiquated commands the language was effectively split into two completely separate browser versions with the ES5 release in 2011. New scripts can now include a command that identifies that they are using a newer version of JavaScript and those obsolete commands that actually conflict with the way JavaScript is now being developed can be treated as having been removed without breaking other code that still relies on those antiquated commands.

One reason that people give for not using the latest version of JavaScript in the new code they are writing is that there are still popular browsers out there that don't support the new commands. This argument doesn't hold up. While a small percentage of your visitors may be using browsers that don't directly support the new commands there are ways to work around this. There is no reason to penalise the majority of your visitors using modern browsers that support fast modern code by forcing them to run much slower antiquated code simply in order to avoid commands that older browsers used by a few visitors don't support.

Where browsers don't support the new commands we can add that support ourselves. Code to implement a JavaScript command that antiquated browsers don't understand is called a polyfill. Using a polyfill your code tests once whether a particular JavaScript command that you are using is supported by the browser and if it isn't then it simply adds its own code to provide that support for that browser. The new browsers that do support modern JavaScript simply run the command as normal and the antiquated browsers that don't understand modern JavaScript run the extra code from the polyfill that translates the JavaScript command into a longer series of JavaScript commands that do the same thing. By doing this the only people who get a speed penalty are those using the antiquated browser that doesn't properly support current JavaScript. Once everyone switches to browsers that do support the JavaScript properly you can upgrade your code by removing the now unnecessary polyfill. If instead you penalised everyone by using antiquated code then the only way to get everyone using the faster modern version is to completely rewrite the code.

Some new JavaScript code is not quite so easily accommodated. Where there is an actual syntax change in JavaScript then presenting new code to antiquated browsers will simply produce a syntax error. The new command in ES5 to split JavaScript into two versions worked around this by allowing the new command to be written in a way that would allow older browsers to ignore it. While use strict; would generate a syntax error in old browsers, the command was set up so that it can still be recognised if entered as a string instead of as a command - "use strict"; does not produce a syntax error in older browsers that just see it as creating a string but not actually using it while newer browsers ignore quotes around use commands and treat them as if the quotes weren't there. Other syntax changes need to be not just concealed from older browsers but need equivalent code using an older syntax to be able to be fed into those browsers that don't understand the current syntax. Scripts called transpilers can take code written in modern JavaScript and convert it into more antiquated JavaScript that antiquated browsers can understand.

That polyfills and transpilers can take your modern JavaScript code and translate it into code that older browsers can understand means that there is no reason to not make use of the new commands and objects introduced in new versions of JavaScript.

Another consideration is the amount of time between JavaScript versions. The first three versions were released about a year apart in 1997, 1998 and 1999. There was then about ten years that passed with no new version being released as those responsible for the standard were split into two groups with one group wanting the next version to make fairly small changes and the other group proposing much bigger changes. This deadlock was broken at the end of the ten years with an agreement to introduce the smaller changes first and then progressively introduce the larger changes. The two groups called their versions 3.1 and 4 and to avoid confusion with either of these the newly agreed standard released in 2009 was called version 5. A minor upgrade to this called 5.1 came out in 2011. The release of the next version in 2015 means that there is only a four year gap between it ant the prior version - much smaller than the earlier ten year gap - and with that version being renamed to 2015 and with a 2016 version already well underway it looks very much like JavaScript will be returning to yearly versions. With more rapid changes to the language expected in the future, using the current version to write new code is the only sensible approach. After a few years it will be using what appears to be older style coding but it will not need as much work to update it to the latest version as would be the case if it were written in a version that was already antiquated at the time of writing.

Anyway, one of the biggest changes to JavaScript use came about during that ten year gap. There is a part of JavaScript that is developed separately from the main standard as it applies only in web browsers and not in all of the other places that JavaScript can be used. This is the Document Object Model (DOM) and it defines how JavaScript can interact with web pages. Although this too is changing over time, its introduction made it possible to separate out the JavaScript completely from the web page. Older style JavaScript embeds JavaScript event handlers into the HTML itself where it is both more difficult to maintain and needs to be hard coded into each page that uses the script. Once JavaScript could be separated entirely from the web page into its own file and made almost completely unobtrusive, it became extremely easy to be able to add scripts to web pages as required without the possibility of them clashing. This change by itself is a good reason to not consider using any of the earlier ways of writing scripts. With individual scripts being written in an unobtrusive fashion means that you can write your new scripts using the latest version of JavaScript and include them in the same page as scripts written using a slightly older version of JavaScript without clashes. Keeping all of your scripts completely up to date will become less important provided that they are written in an unobtrusive manner.


This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow