JavaScript is a single-threaded language - which means that only one piece of code can be run at once. However, I'm sure that you have noticed that setTimeout, Promises, fetch, etc. don't block the UI and the user is still able to use it. You may wonder why and the answer is Event Loop.\nIn JavaScript, once a function invocation is seen, a new frame for it is created and added to \nCall Stack\n. Then all of them are executed from the latest one - the FILO (\nF\nirst \nI\nn \nL\nast \nO\nut) rule.\n\nCool, so let's take a look at this code:\n```jsx
console.log(1);
setTimeout(() => console.log(2));
new Promise((res) => res()).then(() => console.log(3));
console.log(4);
```\nSpend some time analyzing the code and try to figure out what's the output.\nAnd the correct answer is ... \n1, 4, 3, 2\n. If your answer was different - no worries I'll explain it in a minute. :)\nSo basically when you write code in JavaScript you use JS API like Math.random(), etc. but you can also (and you do!) use external APIs provided by your environment - a browser or node.js. The most popular ones are timers (setTimeout, setIntervals), DOM API (document.querySelector) or fetch. When you call them, the browser handles the execution in a separate thread. Then you have to pass e.g. callback that should be invoked once the function finishes. For instance, in the example above, when the setTimeout is met, the JS engine delegates the execution to the browser and moves to the next one.  \n  \nOkay, I hope it's clear by now. However, probably you wondering now when the callback should be handled by the engine after the setTimeout finishes. So we need to introduce 3 new concepts:  \n  \nMicrotask\n - a task that is being executed once the callstack is empty and before the browser's planned work\nMacrotask\n - a task that is being executed once the callstack \nand\n the microtaks queue are empty. It allows the browser to finish its planned work.\nEvent loop\n - it keeps an eye on the callstack and moves callbacks' frames from microtasks and macrotasks queues to the callstack for execution. \n\n(credits: \nhttps://medium.com/@saravanaeswari22/microtasks-and-macro-tasks-in-event-loop-7b408b2949e0\n)\nSo as you can see in the visualization above, once the callstack is empty, event loop gets another item from the microtask queue and finally clears macrotasks queue.

Micro- and macrotasks. Event loop.

Backwards compatibility\n - means that if something was introduced in any previous version of e.g. language, it won't be removed or breakly changed in any new version. It ensures developers that their programs will be working in new versions of the environment - a browser for instance. 
\nForwards compatibility\n - means that if a program is written in a newer version of the language, it wouldn't break in an environment that doesn't support features later introduced.

⁠⁠
⁠So which one JavaScript is? You probably have struggled with a situation when your code didn't work correctly in Internet Explorer - e.g. you used Array.includes. IE 11 doesn't have this method implemented since your code couldn't have been executed properly, even though it worked fine on other browsers. It means that JavaScript \nis not forwards compatible\n. You cannot expect that if you use the latest version of JavaScript, your program will work as expected on deprecated browsers. \n
⁠However, every program written in any version of JS works in an enviornment that supports the following versions. A JS code that was written in the 90s would work in the latest versions of modern browsers as it used to work back then. It means that JavaScript \nis backward compatible\n.\n
⁠This is a huge challange for \nTC39\n (the technical steering committee that manages JS) - they have to ensure that the changes that are supposed to be introduced in a new version of the language, won't break anything. I'm sure you was confused when you saw the result of typeof null (object). It cannot be fixed in a painless way because many applications have been written taking into account this quirk. \n
⁠On the other hand, HTML and CSS \nare forward compatible\n but they \naren't backward compatible\n. If you try to open a website written in the 90s in a modern browser it may not be working correctly (or at all). But if you open a website written in HTML5 in an old browser - it wouldn't be broken (of course it may not look the same) - the unrecognized CSS/HTML would be skipped over, ⁠but the rest - proccessed accordingly.

⁠⁠
⁠More details can be found \nhere\n.

Backwards and forwards compatibility

The strict mode introduces a more \nrestricted\n variant of JavaScript into your module, function or classes. It's an opt-in mechanism and it doesn't have to be used within the whole application - although it's recommended. You can turn in on e.g. in one function when the rest can still be written in a "normal" JavaScript. It may be helpful if you want to migrate a legacy project. \nThe mode makes several changes to normal JavaScript semantics:\nintroduces \nearly errors\n - throws an error for errors that aren't strictly syntax ones but are thrown at compile time. Such errors without the mode might be treated as a mistake without an error so the program runs but it may create worse problems in the future. E.g.⁠\n
⁠```js
⁠'use strict';
⁠let variable;
⁠vriable = 10; // There's a mispelling so this variable doesn't exist. Without the strict mode on, this variable would be created but in this case a ReferaceError is thrown preventing us from a bug
⁠` \nspeeds up the code - it fixes mistakes that may have impact on JavaScript engines optimalizations\nmake the code more secure\nStrict mode is by default turned on for ES6 modules and classes.\n

Przemek Franczak

Software Engineer

Micro- and macrotasks. Event loop.

Backwards and forwards compatibility

Strict mode

Recent Posts

Categories