Let's assume that you have a small application running on a single server. The simplified architecture would look like this:\n\nMultiple clients are sending requests to a single server that is responsible for answering them. This approach is fine as long as you don't have big traffic and you are okay with your server being down for a while if any unexpected problem occurs. It might be suitable for your blog or a hobby website, however, there are several issues that are deal-breakers for huge applications. Let's take a look at 2 of them. \nThe first one is your server is \na single point of failure.\n Once the server goes down, no one can reach your application. \nThe second one is \nscalability\n. If the traffic is getting bigger, your server might not be able to handle so many requests. The question is how to deal with it. Basically, you can try to scale your server \nhorizontally\n or \nvertically\n. \nVertically\n - replace the server with a more powerful one\n\nPros:\nit handles more traffic\njust one server to maintain\ndoesn't increase the complexity\nCons:\nstill only a single point of failure\nHorizontally\n - instead of replacing the server, add another one(s)\n\nPros:\nit handles more traffic\nno single point of failure - if one server is down, the load balancer reroutes traffic to  other servers\nCons:\nthe server has to be "stateless"\nincreases the complexity\nmore server to maintain\n

Horizontal vs vertical scaling

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

Strict mode

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

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.

⁠Let's imagine you have a component <FormWrapper> that stores some specific value e.g. to display additional fields:\n```jsx
const FormWrapper = () => {
   const [showExtraFields, useShowExtraFields] = useState(false);
⁠   
   return (
      <form>
      <Inputs/>
      {!!showExtraFeilds && <ExtraInputs/>}
      </form>
   )
⁠}
```\n
It works as expected however there's one tricky part. Whenever the s\nhowExtraFields\n value changes, the \nInputs\n component rerenders. This is what the FromWrapper component looks like after pure js transpilation\n```jsx
⁠const FormWrapper = () => {
   const [showExtraFields, useShowExtraFields] = useState(false);
   return React.createElement("form", null, React.createElement(Inputs, null),
      !!showExtraFields && React.createElement(ExtraInputs, null));
⁠};
```\nWhenever the parent component rerenders, React.createElement(Inputs, null) is called and it creates an object: { type: Inputs, props: {} } what forces \nIntpus\n to rerender as well (since props object's reference has changed). Although if you use the children prop, the issue is gone. It's because React has the "bailout" mechanism for preventing rendering children components. \nThat's how the FormWrapper looks with the prop:\n```jsx
const FormWrapper2 = props => {
   const [showExtraFields, useShowExtraFields] = useState(false);
   return React.createElement("form", null, props.children,
      !!showExtraFields && React.createElement(ExtraInputs, null));
⁠};
```\nAs you can see, the children are passed to the form however there's no createElement for them.

Przemek Franczak

Software Engineer

Horizontal vs vertical scaling

Strict mode

Backwards and forwards compatibility

Micro- and macrotasks. Event loop.

Use React children props

Recent Posts

Categories