JavaScript Backwards Compatibility

May 05, 2020

As you may know from my previous post, I am now reading You Don’t Know JS Yet by Kyle Simpson. I highly recommend this series if you want to deepen your JavaScript understanding.

In the first chapter, the author explains some foundations and internal workings of the language. Whilst reading, two concepts caught my attention as they are directly related to the practices we use on our everyday projects i.e. transpiling and polyfills.

JavaScript is Backwards compatible,

(this) means that once something is accepted as valid JS, there will not be a future change to the language that causes that code to become invalid JS. Code written in 1995—however primitive or limited it may have been!—should still work today. As TC39 members often proclaim, “we don’t break the web!”

In other words, once you have written your code using the features of today’s JavaScript, it will always be valid. Although there are many upsides to this, the big downside in my opinion is my greatest frustration with the language. Sometimes, we would just like to have this particular feature available, and it does not seem like such a big deal to an average developer. And you might have wondered, why would they just not add it. That is the reason why. No matter how cool a feature may be, it really has to make sense to add it to the language. If it gets accepted now and a few years down the line we realise it was a mistake, there is no coming back as it could break the web if they were taken out.

On the other hand,

Forwards compatibility means that including a new addition to the language in a program would not cause that program to break if it were run in an older JS engine. JS is not forwards-compatible, despite many wishing such, and even incorrectly believing the myth that it is.

Sometimes we would love to start using the latest and greatest of the JS syntax right away, but we might get hold up by the need to support older engines. IE11 anyone?

However, that should not stop us from writing the code in the latest fashion. We can use transpiling:

using a tool (such as Babel to convert the source code of a program from one form to another

as a solution to the problem.

For example, ES6 introduced both let and const keywords. We could start using them right away in our codebase, but prior to shipping it to the production, we need to transpile all the packages to use the older syntax of var keyword instead, so that the older engines can still interpret our code.

Another issue related to the forwards-compatibility not being JS feature, is when there is a missing API method that was only recently added. For that we can use another solution:

polyfill is a definition for that missing API method that stands in and acts as if the older environment had already had it natively defined

Having read the first chapter of YDKJSY, I now have a better understanding why we need to use these at first confusing practices. I hope my post will help you understand that better too now. It is good to know how to use them, but even better to know why.

Photo by Goran Ivos on Unsplash