I’ve heard people talks about JS like that many many times. And I think that’s true. JS has many historical terms, and we cannot understand them if we don’t understand its history. Addition, some points are too hard to understand and have no document (if have, it’s too theoretical for dev). I’ve spent a lot of time trying to understand Event Loop but I cannot get it out clearly yet.
But JS doesn’t make us feel crazy. In another way, we feel like we’re in a journey with many interesting things ahead. It shows us that at some points of time, there are some decisions were made, some were not good (bad things), and how they were fixed one way or another way.
For 2 years work with JS, I have found out some pros and cons of it, and sometime I cannot understand the way JS runs a block of code. And, you know that, copying some lines of code from stackoverflow.com, and it’s run like a miracle. I decided to get deeply understanding of it and YDKJS is the best choice. In this topic, I’ll write about some interesting things I’ve got when reading the first book of the series.
You may have heard about ES5, ES6, ES7.. when work with JS. And the common question related to that is something like “what happen if I run ES6 code on a ES5 engine and vice versa?”.
This kind of question is about the backwards and forwards compatibility of a language and YDKJS shows us a clearly answer.
So JS is backwards-compatible. I write my JS app today and it will be run well in 2025 even I updated new version of browser or nodeJs, as long as JS keep this principle, every cool!.
This also explains why JS is confusing. We will find out that with a problem, JS has more than one solutions for that. They are implemented differently totally but they try to resolve only one. Some solutions are seem like ugly, and to be replaced with the new one, but it still there, because JS is backward compatible.
Compare backwards compatibility to its counterpart, forwards compatibility. Being forwards-compatible 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.
We cannot run ES6 code on older engine because JS is not forwards-compatible. The ES6 version has some new keywords or built-in functions (the gaps) that older engines cannot understand that, and, yes obviously our app will crash. For instance, we can merge two arrays in ES6 like following:
But if we run that code on engine support ES5 or lower, an error will be thrown. The key word ‘const’ (means constant) and spread operator (…) isn’t supported on ES5.
So JS is backwards-compatible and isn’t forwards-compatible, that means if your website is written in older ES, it will be run well on more device than the newer. Because there are gaps between them. But write code on new engine version is always easier, faster and less pain. That’s why we have the next section “Filling the Gaps”.
I wish I can code my web using ES10 (ECMAScript2019) but it can run well on a machine that support ES5, hmm.. Babel can help us.
It’s amazing! Yes that’s true! So what make Babel and other JS complier awesome?
Actually, there is no miracle. What Babel do under the hood is compile ours code to older ECMAScript version. For instance, the example in the 1st section will be compiled back to ES5 as following:
In the above example, our target is ES5, so Babel will replace function, keyword.. we are using in ES6 to ES5 by using what support in ES5. For instance, Babel use “.concat()” to replace spread operator which is not supported in ES5.
You can try it out at: https://babeljs.io/repl
Back to early days before ES6. There is a way to manage our code called “module factory function”. Basically, we design a pattern by using function then from that, we can create instances. The pattern is like:
If you was doing stuff on nodeJs, you may be know about some variations of this module factory function as AMD (Asynchronous Module Definition), UMD (Universal Module Definition), and CommonJS. They are based on the same principle.
Until the ES module is introduced in ES6, we have an official module structure with the idea of one file one module. With the same example above, let’s see how we implement it with ES module:
You can export functions, objects, or primitive values. And also use “default exports” (One per module) to export unnamed stuff.
Basically, JS has two kind of variable:
- Primitive: string, number, boolean, null, undefined
- Object: object, array, function When an variable A is assigned to an existing primitive, it means JS creates a new space in the memory to store the value of A. In other words, the value has been cloned and A point to new value. And when an variable B is assigned to an existing object, it means B just point to the address of the value. In this case, there is no copied value. To more clearly, let’s take a look in the following example:
We changed the name of motorbike and the name of motorbike1 is changed as well. That means two variables pointed to the same address in the memory.
I hope you’ve found some interesting views of JS and about the book. As the first line of the topic, we cannot understand JS totally, so if you find anything wrong please comment and then we can discuss more about that. Addition, I’m happy if you guy can help me improve my English skill, so please fix me if any typos, wrong words or missing character by comment as below.