DEV Community: Aditya Tiwari

Scope & Closure Ch. 1&2 Summary(YDKJSY)

Aditya Tiwari — Fri, 10 Sep 2021 13:53:42 +0000

This blog post is a summary of what I could understand from the first 2 chapters of this book.

Chapter 1: What's Scope?

Scope refers to a part of the program where variables/data declared in that part of the program are accessible to the program based on where they were declared. Confusing? Let's try one more time. A variable in any part of a program can be accessed by the program in other parts based on where the variable was declared/exists. This is where the term scope comes in to simplify things and make our understanding better by actually having some rules that help to predict/understand and access variables/functions easier.

Compiled vs Interpreted

What does compiled or interpreted mean? So computers don't understand human language. They work on 1's and 0's. So in the initial days, people wrote code in assembly language that was converted to machine code by processors. But it was hard you didn't get a lot of flexibility with those languages. On top of that, it was harder to understand and learn. That's where languages that were close to English started coming in ex. Fortran, COBOL.
But we still had one issue ⇒ Computers don't understand that. Computers need instruction to complete tasks.
That's where this process comes in that converts a program that's written in a high-level language to instructions that the computer would understand.
This process has different models like compiled and interpreted. How do they differ? In code compilation, the compiler compiles the whole file in one pass and then generates a new file that could be used to run the program later. In the interpreted model, your program still compiles the code in machine instruction but instead of doing that at once, it does this line by line.

Is JS interpreted language?

So most of the time, JS is considered an interpreted language but Kyle has written and gave proof that how JS isn't interpreted but compiled in the first book.

What does compiling code mean?

Why does it even matter if JS is compiled or interpreted? Since we're discussing scope, the scope is defined during this phase only.
What does happen during compilation? So basically there are 3 steps taken during compiling any code.
1. Tokenizing/Lexing: This step refers to tagging reserved keywords of language. Breaking whole program into chunks that language understands.
2. Parsing: Taking streams of tokens and turning them into a tree of several elements. This is called as Abstract Syntax Tree(AST).
3. Code Generation: Converting the received AST to an executable code by machine.

Two Phases

Compilation Phase
Execution Phase

Kyle said these 2 phases can be actually observed through JS programs and are not just facts in theory.
We can observe this pattern if we look and notice the following things: syntax error, early errors, hoisting.

Compiler Speaks

The following program has an array of addresses that has two property city and country. We see a function getCountry that receives a parameter named city and based on city name, it returns name of associated country inside object.

const addresses = [
    {
        city: "SF",
        country: "US"
    },
    {
        city: "MUM",
        country: "IND"
    },
]

function getCountry(city) {
        for(let address of addresses) {
                if (address.city === city) {
                        return address.country;
                }
        }
}

const country = getCountry("SF");

console.log(country);

Every variable/identifier in any program act as one of these 2 roles: target and source.

What's the target/source? How does someone identify them?

Variables that are being assigned a value are a target in our program and rest of the variable/identifiers are sources.
In above code, addresses, cityparameter of getCountry function, addressin for loop block and country are targets of this program. Since they were being assigned value. But we left one more target to mentions above.
That's function getCountry(city). Yes, function declarations are subtle target reference that exists in JS codes.

Scope is defined during compilation phase, so you can't really change it during runtime. But JS also has ways do this through

eval(...)

function badIdea() {
    eval("var a = 2;");
} 
badIdea();

with()

const info = { name: "John", age: 30 };
with(info) {
    console.log(name);
    console.log(age);
}

So following way, you could still change scope during runtime but Kyle suggested avoiding this at all costs and they're not available in strict mode anyways.

Chapter 2: Illustrating Lexical Scope

Let's have a look at the code snippet that we used in the last section.

const addresses = [
    {
        city: "SF",
        country: "US"
    },
    {
        city: "MUM",
        country: "IND"
    },
]

function getCountry(city) {
        for(let address of addresses) {
                if (address.city === city) {
                        return address.country;
                }
        }
}

const country = getCountry("SF");

console.log(country);

Now Kyle came up with the following metaphor/mental model to understand scope through

Marbles, Bucket and Bubbles

Now I am gonna explain/write what I understood through his metaphor and explanations. For an accurate mental model, I suggest reading this section.

In the code above, there are 3 scopes that we can observe. The outer scope ie Global Scope, the scope of the function, and since JS now blocks also create new scope, we can see the scope created by for loop.
Through Kyle's metaphor,

⇒ a scope is represented by a colored bubble

⇒ each scope has their own scope bucket

⇒ a variable/identifier represents marble and belongs to a scope bucket depending on the bubble it resides.

So we have 3 different scopes we would say

BUBBLE 1 - The outermost scope holding marbles addresses, country and getCountry

BUBBLE 2 - The scope of function getCountry holding marble city

BUBBLE 3 - The scope of for-loop holding marble address

How does scoping work in their bubble?

A scope can only access its outer scope and can not access scopes that are nested inside them.

⇒ So expressions inside BUBBLE1 can access marbles of BUBBLE1, not BUBBLE2, not BUBBLE3.

⇒ An expression inside BUBBLE2 can access marbles of BUBBLE2, can access marbles of BUBBLE1, but not BUBBLE3.

⇒ An expression inside BUBBLE3 can access marbles of BUBBLE3, can access marbles of BUBBLE2, and can access marble of BUBBLE1.

A conversation among friends

In this section, Kyle wrote about how these variables are put into respective bubble and scope buckets during compilation and how does the lookup happen for the marbles aka variables/identifiers during code execution based on bubbles.

Whenever JS engines would start processing code, it would happen in 2 phases

Compilation
Code execution

what does happen in the compilation phase?

compiler starts compiling the code and it takes help of scope manager to create declared variables
compiler also asks scope manager to create functions declaration and create a separate scope for that function with its own scope bucket and scope manager ie function scope manager
compiler does this for all of target references it finds and asks scope manager, maybe global scope manager or maybe functions' scope manager or maybe a new blocks' scope manager depending on where the control of the program is in right now, to create that space in memory

what does happen in the execution phase?

Now in this phase engine asks respective scope managers if the target reference it found exists in scope from the compilation phase. If scope manager says, yes it exists in current scope then engine assigns undefined to it so that it's ready to use when program actually starts execution
If the current scope manager doesn't have that target reference then it asks engine to go in outer scopes and ask the respective scope manager

Nested Scopes

We saw if the current scope doesn't have a variable/identifier then engine goes to next outer scope and asks respective scope manager. This stops once the engine reaches global scope. If engine doesn't find the variable in global scope as well then it results in an error. These errors are handled differently based on if they're target/source. Usually, a reference error is thrown.

accidental globals

In non-strict mode, when a program tries to assign a target reference a value and if value was never declared either in current scope or in next outer scope then scope manager(global) goes ahead and creates a new variable but this look should've resulted in failure.

function getStudentName() {
    // assignment to an undeclared variable :(
    nextStudent = "Suzy";
}

getStudentName();

console.log(nextStudent);
// "Suzy" -- oops, an accidental-global variable!

One more metaphor

Kyle came up with one more metaphor is an office building. So if you're trying to resolve a target/source reference so you first start by searching the first floor and when you don't find that you proceed to search on the next floor and you do this until you reach last floor in building and you have no more floor to go.

What's Critical Rendering Path?

Aditya Tiwari — Sat, 03 Jul 2021 13:50:01 +0000

Whenever we talk about web performance, we come across things like async/defer, perceived performance, and critical path rendering. In this blog, we're going to discuss in length about Critical Rendering Path and how does it affect web performance.

We can define CRP in one line as

The steps taken by the browser to convert HTML, CSS, and JavaScript into pixels, that can be painted on the browser, are called Critical Rendering Path(CRP).

The whole process involves several steps and processing of code. The following flow would give you an idea of it -

Whenever you hit some page on internet, browser goes to server and requests the page it needs.
Server replies with the data on the network. The data comes in form of bytes.
Once the data has come back CRP starts executing steps to process HTML files

🛠CRP steps -

1. Document Object Model(DOM) Construction -

Browser reads the HTML, CSS, and JS files and starts converting data to HTML markup. It uses a defined unicode type with an HTML page to convert data into characters.
After browser is done converting characters, it starts tokenizing the HTML page. Tokenizing is done to identify different tags and form nodes based on them. With tokenizing browser also converts the HTML element data into Objects because it needs to store information such as parentNode, childNodes, events attached to that respective element etcetera.

Once tagging is done and browser knows HTML elements then browser starts constructing nodes. Nodes store information about HTML elements.
After constructing nodes, browser starts constructing DOM and establishes a relationship between nodes as a parent, child, and siblings.
While DOM construction, if browser encounters external resources like JS, images then it is blocking request. Browser waits for request to resolve and then restarts DOM construction.
So depending on external resource fetching, DOM construction time varies.
We can avoid blocking resource by fetching non-critical data using async/defer keywords.

2. CSS Object Model -

Browser performs CSSOM construction after DOM is ready but CSSOM construction is render-blocking because browser waits for different CSS files to arrive.
This behaviour isn't strange. It exists for a reason.
CSS cascades down from parent elements. It means, say for example, styles given to body tag would go all the way down in DOM tree. But we might override the cascading styles from parents in child. So browser waits until it receives whole CSS and then constructs the CSSOM.
With custom styles given to any HTML page, there are set of pre-defined style that exists in browser. That is the reason, even if you write plain HTML files without styles. You would observe some basic styling done by browser. So CSSOM is constructed using both custom and pre-defined styles by browser.
Usually more specific rules increase the amount of work browser has to do.
For example, .inner {} selector would take less time than .outer .inner { } selector. Because once browser finds .inner { }, it has to go and find it's parent .outer { } also.

3. Render Tree -

Browser has DOM and CSS trees at this point. So browser knows what do we want to put on screen and how to style it but independently they don't mean anything.
So to construct render tree, browser would have to visit each node in DOM and find each nodes respective styling from CSSOM and finally construct a combination of both in a tree known as render tree.
So it combines DOM and CSSOM but it doesn't put every node from DOM in here.
Render Tree stores HTML elements/node that needs to be in view. So it doesn't have HTML elements like head, meta, script etcetera.
It also doesn't store elements that have property display: none or any of its descendants. Because render tree represents elements that are going to be painted on screen. So it omits any element that would not be part of our layout. We would talk in length about layout in the next step.

4. Layout -

Now browser has a render tree, that stores elements and their respective styles to be put in the browser screen. But during whole phase, browser didn't compute any position or size-related property. So how does the browser know what to put where? It needs some information so that it constructs the layout of HTML page.
That part is done here because based on viewport of device, these properties vary. This process is called layout or reflow.
Time taken by browser to do this layout depends directly on size of DOM tree because it has to perform render tree step again.
What causes layout/reflow in browser? So window resizing, device rotation, scroll etcetera are responsible to make browser do layout again. Since on all these events, size/position of elements would definitely change.
In this step, every relative unit, i.e. %, rem etcetera, is converted to specific pixels.
This GitHub gist shows what forces layout in browsers.

5. Paint -

With layout done, only part left is putting elements on screen in form of pixels.
Browser uses render tree to do this painting. Time taken by this step depends on size of DOM and amount of work required by browser to do for styling, layout, render tree construction.

We saw steps involved in converting data from bytes to pixels that the browser performs. That means the time taken by CRP is the initial loading time of our web app.
If we want to reduce the loading time of our web app then we need to optimize our CRP. Optimizing CRP lies in above steps. In order to optimize your CRP, you need to optimize each step and reduce the amount of time browser spends on each of them.

🤔How do we optimize CRP?

Basically you need to reduce the time taken by each steps to optimize overall CRP but how would you do that?
If we go back for a refresher then we know that browser does the DOM construction and CSSOM, right?
Can we do something here? Yes. Let's discuss the solutions now.
To optimize DOM construction -
- As we already saw, DOM is render-block. It is render blocking because if it encounters a link or a script tag, browser stops DOM construction waits and after the link is fetched or JS engine has completed running JS code in script tag, browser starts where it left the construction.
- Browser does this because, when it encounters a script tag, it doesn't know what changes that script would do after completion. This is the same case even if you don't write JS code directly in script tag but write it in a different file and link via a script tag. Browser would still behave the same.
- So in order to load app as soon as possible, we need to decide what our critical resources are and what aren't?
- You can do this by attaching a async attribute on your script tag like this
```
<script src="index.js" async></script>
```
- When browser encounters async tag, it understands that this is not critical resource for page, it doesn't stop and keeps the DOM construction going to next part of file.
How can we optimize the CSSOM construction step?

🧐CSS perf optimizations -

As we saw, DOM and CSSOM construction are render-blocking and it affects CRP. We can't do anything for DOM cause to start painting pixels on browser we need elements but can we optimize CSSOM construction.
If we think our styles are composed of different things like we would have different set of styles for mobile devices and desktop devices.
At one point, we would use just one of them. So we can define and ask browser what to load and move to render tree(discussed in step 3) step instead of waiting for whole styles to arrive and load.
We can do this in several ways. Some of it is defining media types and media queries when we link our CSS files.
If you link CSS files like this

<link rel="stylesheet" href="index.css">

then it's CSS parse blocking.

If you know some parts of CSS would only be applied if the page loads on Mobile Devies or smaller screens. So you could defined them like this

<link rel="stylesheet" href="mobile.css" media="screen and (max-width: 680px)">
<link rel="stylesheet" href="portrait.css" media="orientation:portrait">

then this wouldn't be blocking since it only loads when screen size is under 680px.

In second link tag, this would only load when orientation would be portrait.
Putting animations on GPU instead putting heavy computations on main thread
Using property like will-change to let browser know beforehand that this property would change in the future. If browser encounters this property then it does some optimizations even before the element actually changes.

⚡If we want to put optimizations in points then -

Optimize your critical resources so that browser doesn't waste a lot of time fetching them.
Load critical resources as early as possible. Don't make your browser wait for them.
Understand what's important for first or initial load of your app and defer rest of resources by making them async and loading them later.

📚 Resources -

Are you using context right?

Aditya Tiwari — Mon, 19 Apr 2021 11:31:44 +0000

Did you ever think why does context exists in react? You might have seen people asking on the internet that when to use context or context+useReduer and when to use redux. So let's understand the use cases of context in react and how hooks have made life easier.

React docs define Context as -

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

This means that context helps us in avoiding prop drilling. Wait but why should we avoid prop drilling? What is wrong with prop drilling?

You wouldn't understand why prop drilling is bad until you go through the pain of passing down a single value all the way from the top of the DOM tree to deep down in some component.

Let's see an example of prop drilling...

// App.js
export default function App() {
  const [userName] = useState("Mr. Ferb");
  return (
    <div>
      <Dashboard userName={userName} />
    </div>
  );
}

// Dashboard.js
export default function Dashboard({ userName }) {
  return (
    <div>
      <Profile userName={userName} />
    </div>
  );
}

// Profile.js
export default function Profile({ userName }) {
  return <div>
    <h1>Welcome { userName } </h1>
  </div>;
}

In the above code, we're trying to pass the username of logged-in user from App component to Profile component. But profile component isn't enclosed inside app but it lies in Dashboard. Dashboard is enclosed in App. So to make this userName available to <Profile /> component, we would have to pass it as props to <Dashboard /> first and then from <Dashboard /> again to <Profile />.
Now this was a hypothetical scenario and we were passing just a single value but consider the real complex application where your state is needed in many parts of the DOM tree. You would reach a point in your app where it would become really hard for you to track down the value and bugs that are being passed down through props.

So this is where Context comes in to save us. So in order to use context react gives us a hook called useContext. (Context can also be used with class-based components but we are going to cover the hooks part only.)

Using useContext

React gives us an API createContext. This returns a Context object and our components can subscribe to this returned context object and consume those values that exist in this context.
Now we would code the previous example where we tried accessing the userName inside Profile without context.

// UsernameContext.js
import { createContext } from "react";
const UsernameContext = createContext();
export default UsernameContext;

Above we used createContext API and made this UsernameContext that would hold the username for our app. (You can pass initial values right here in createContext as well).

// index.js
import UsernameContext from "./UsernameContext";
const intialValues = { userName: "Mr. Ferb" };
ReactDOM.render(
  <StrictMode>
    <UsernameContext.Provider value={intialValues}>
      <App />
    </UsernameContext.Provider>
  </StrictMode>,
  rootElement
);

Here we used Provider of UsernameContext object that would make the values of this context available to children components. In this case, the children component is <App />.
UsernameContext.Provider expects value prop.

// Profile.js
import UsernameContext from "./UsernameContext";
export default function Profile() {
  const { userName } = useContext(UsernameContext);
  return (
    <div>
      <h1>Welcome {userName} </h1>
    </div>
  );
}

Now to consume values of UsernameContext, we would use useContext hook. We pass the Context object here that we want to use. In our case we want to use UsernameContext object.

Note - There are cleaner ways of writing context like taking Context.Provider out of index.js but I left them as it is for simplicity's purpose.

Did you see that when we used context we no longer had to touch the <App /> and <Dashboard /> components? The values came down without having to pass from App/Dashboard. This is the power of context.😎😎😎

Woohoo, now we know why does context exist in react? and how to use it?

Some things to point about context -

Whenever value prop changes in provider, react causes rerender to each consumer components of that respective context.
If the provider sits at root component then changes in provider causes the whole app to rerender.
You don't have any means of preventing the rerender cause on every prop change each component subscribed to context is forced to rerender.

Now coming to the title of article - Are you using context right?

So this question because people usually say Can we use context+useReducer instead of redux? To understand this question let's go back to definition of context by react -

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

If you read carefully it clearly says that context helps to pass the data? Right? It never said that context manages state. But when you use term redux it means that you're referring to state management.
Speaking of state management, we can say that useState/useReducer does manipulate our state. So they are sort of state management but context never manages your state. It just passes it down the DOM.
You can think of context as conveyer belt where you put something(some values) on it and then that belt keeps rolling. Whenever those things(values) reach desired station(component where you want to use values), you take them off the belt.
In the whole process, context never stores and manipulates the values.

So how does redux differ in this scenario?

Redux also uses context for availing redux store instances to components in DOM tree.
But in redux, your components can subscribe to part of the whole store and they would only rerender when those values change but this is not the case in context.
So this feature of redux helps us improve the performance of web apps by controlling the rerender that would happen in-app.

So it really depends on what is the need of your app. If your app performs frequent updates then using context with useReducer might yield some performance issues in your app. But if you want control over your component updates then redux is the way to go. We got to understand that context wasn't supposed to be used as state management.

So with this, we've reached the end of the article. I would like to put a statement here that I came across when I was reading this blog by Mark Erikson. Sebastian Markbage(React Core Team) said this about Context -

My personal summary is that new context is ready to be used for low frequency unlikely updates (like locale/theme). It's also good to use it in the same way as old context was used. I.e. for static values and then propagate updates through subscriptions. It's not ready to be used as a replacement for all Flux-like state propagation.

Thank you if you read till here! 👋

Why thinking asynchronous is important in JS?[Part-2]

Aditya Tiwari — Fri, 18 Dec 2020 21:18:25 +0000

Hello folks! Now we know the working of JS that we discussed in my last article. Let's understand how synchronous JS code can lead us to problems.

Let's recall one thing - JS execution waits until current statement executes completely before jumping to next one .
What does the above line mean? That when JS code wants to access resources outside the program, the program control waits until that block of code does its task.
So what? What's the issue here? it's alright if we wanna access resources like files or accessing local storage(considering JS code in Nodejs).
Yes, but the issue starts when our code hits outside our machine and goes into the network. There are chances that the URL we wanna visit doesn't exist anymore. Maybe we put wrong URL.
In the above-mentioned cases, the main execution thread would remain blocked until the request made in network returns. This, in turn, blocks the call stack.
What would happen now? Since the execution thread and call stack are blocked, any DOM and other events would stop resulting in the freezing of browser.
Consider an example given below -

var dummy = $.get("dummy.co.in");
var dummies = $.get("dummies.edu");

console.log(dummy);
console.log(dummies);

In the snippet given above, there are chances that dummy.co.in or dummies.edu doesn't exist or maybe the server is down right now or maybe the domain has changed.

What's the issue with the above approach?🤔

So it's alright if we didn't get a response right?
Yes, but the main execution thread was blocked for the whole time when program control was waiting for a response and didn't finish executing later code.
This is the problem that our program is waiting unnecessarily when we could've finished our remaining code and when the response came back we would've come back and printed the output.
Therefore synchronous code would lead us to a dead-end where our main execution thread would be blocked and call stack doesn't work.

What can be done to avoid these cases?👀

I know you guessed it right. Yes, asynchronous calls.
Hold on! hold on! I know what are you thinking. If JS is synchronous and single-threaded how would it make asynchronous calls?
Okay, so do you remember in the last article when we were discussing WebAPIs. I told you that they kinda provide way to write async JS.
WebAPIs like fetch or setTimeouts() are part of the browser, not v8 but somehow v8 can communicate and access it as well as WebAPIs can access callback queue.

1  console.log("1");
2  setTimeout(function timer(){
3      console.log("2");
4  }, 2000);
5  console.log("3");
6
7  // output
8  1
9  3
10 2

Code snippet shows that console.log("3") being last statement executed before console.log("2").
Because when execution started setTimeout set a timer of 2000 milliseconds inside WebAPIs section of browser. After line 2 program control jumped to line 5 logged 3 and popped the console.log("3") from the stack.
Once timer of 2 seconds set by setTimeout stopped WebAPI pushed the callback timer() that was passed through setTimeout.
Now timer() is queued in the callback queue. Event loop checks if stack is empty and pushes the timer() callback onto stack which in turn pushes console.log("2") onto stack.
There we saw how console.log("2") was put on hold asynchronously but we didn't block the call stack. Call stack went ahead and put console.log("3") before the timer would have finished.

Just like this, promises are also helpful to achieve async behavior.

   fetch("https://jsonplaceholder.typicode.com/todos")
  .then((res) => res.json())
  .then((json) => console.log(json))
  .catch((err) => console.log(err));

In the above snippets, we're calling a REST api and we don't know when would it return object. So instead of blocking the main thread, we're chaining it with other methods of promise like Promise.then() and Promise.catch().
After an unknown time, when the response comes back. We can do whatever with it inside Promise.then() which is catching the promise thrown by fetch().

So never block your main execution thread and event loop

So see you in next one👋
Thank you if you read this long!

Why thinking asynchronous is important in JS?[Part-1]

Aditya Tiwari — Fri, 18 Dec 2020 19:55:09 +0000

Hey folks! I have been learning about javascript lately. I came across a lot of terms like v8, DOM, callbacks, stack, etc. So in this article, we are going to look at how javascript works internally and supports asynchronous calls when it is synchronous. Why thinking asynchronous is important?

The above diagram shows actually how javascript is executed in the browser. So now let's divide the above diagram into parts and see what each of them exactly does.

1. v8 engine -

Any programming or scripting language requires the bare machine to run. Consider when we run our c/c++ code or golang code, they've got compilers. Compilers convert them into machine code and then machine code is executed by processors.
So JS also requires some means through which the browser understands JS code.
v8 is a JS engine that was developed for chromium-based browsers and written in c++.
This is responsible for running JS and code execution in browsers. Call Stack and heap is part of v8 that helps JS to execute commands.

2. Heap -

Heap is the memory area where memory management of JS code happens.
This is where variables and functions are stored in form of objects by JS.

3. Call Stack -

We have come to the exciting part now. This is where JS code is actually executed in the code execution phase.
We know, JS is interpreted language. So JS is executed line-by-line.
Let's see an example.

Do you know how would call stack execute it? Let's see.
Before we start talking about the stack, let's just understand how execution starts.
- Whenever JS starts execution it always happens in 2 phases. Memory Creation and Code Execution.
- In the memory creation phase, the whole code is checked. Variable and function declarations are hoisted.
- After memory creation, in the code execution phase initialization of variables and calling of function happens.
- So coming back to the above example, when the interpreter reaches line one, sees a console.log statement, pushes this statement on the stack.
- As we know stack is last-in-first-out, interpreter waits until this statement executes. Once it finishes 2 things are done. First, the previous statement on stack is popped from call stack and then it moves to line no 3 and finds a function declaration.
- Since it's not invoked, interpreter moves to line no 7. Here printName is invoked so control goes back to line no 3 and this function would to pushed in stack now. now this function has a console.log() statement. So that also pushed to stack.
- Once the console is logged, the previous 2 items on call stack i.e. console.log() and function printName() would be popped respectively.
- So this is how code execution occurs in JS. So a quick summary - Statements are pushed onto stack, program control waits until execution of top item on stack finishes since JS being single-threaded in can not move furthers until the current line of execution happens and then moving on to next statement;
- It makes sense right? that's why javascript is synchronous single-threaded language.

4. WebAPIs -

The WebAPIs aren't part of v8. They are provided by browsers. That means WebAPIs are available to each browser you are working on.
DOM actions, fetch() request, XML objects and other functions like setTimeout() aren't part of v8 but they are given to us via WebAPIs that are incorporated with browsers.
Till now we were saying that JS is synchronous, right? No?
But WebAPIs are part of browsers that helps JS to make it asynchronous. We would come here why does it make JS asynchronous? in the next part of this article

5. Callback Queue -

Whenever some WebAPIs are called or any DOM event happens, that event triggers a function that acts as a utility function to perform tasks after that event. This function is usually known as a callback function.
Since they trigger after the event, they aren't pushed to call stack but they are queued in callback queue to wait until being pushed on the call stack.
Asynchronous calls also return callbacks or promises that are queued right here in the queue.

6. Event Loop -

As we discussed in above section that callbacks aren't pushed on call stack but are queued in the callback queue.
So how would callbacks waiting in queue know that it is my turn to go on stack and finish the job instead of waiting here. They need a way, aren't they?
This is where the event loop plays the role.
The only job of event loop is Wait until call stack is empty. If call stack is empty push one callback onto stack and start waiting until the call stack is empty again .

So we've covered the parts that help JS to execute and saw why JS is synchronous and single-threaded. In next part, we would see why synchronous nature of JS is not good and what are harms of it.

See you in the next part.😃

Do you know autoboxing in JS?

Aditya Tiwari — Sat, 17 Oct 2020 16:42:16 +0000

Hey folks 👋!
I am currently learning javascript. I came across something that I never heard before. I learned about autoboxing and wrapper. I knew wrappers are used in java but had no clue they exist in javascript.

Look at the code given below -

Strange isn't it? We declared name and age variables. We didn't declare objects. So where are these methods and attributes coming from?

So whenever we try to access functions from the prototype of primitives, under the hood, javascript wraps these variables to its wrapper types.

See above, this is how they are initialized as temporary wrapper objects by the javascript engine.

What are wrapper objects?

Wrapper objects convert primitive data types to object type. This is the same case in java where primitives are converted to objects by wrappers classes because collection framework doesn't store primitives. The primitives in javascript are number, string, boolean, undefined, null and symbol. Their wrapper objects are Number, String, Boolean as follows.

How are they temporary?

Whenever this conversion from primitive to object happens, the objects are dumped after a single-use.

We are overriding toUpperCase() and returning "toUppercase", still toUpperCase() was not overridden. Do you know why? Yes because they are temporary. They are invoked when we are accessing functions in the prototype and dumped immediately.

I'd be coming with a follow-up article where we'd discuss what's need for autoboxing.
Thank You for reading!

How to fix npm create-react-app stuck at 'found 0 vulnerabilities'?

Aditya Tiwari — Fri, 03 Jul 2020 16:27:04 +0000

I started learning to React recently. I was following The Net Ninjas' over YouTube. So as I was instructed to install Node.js, I downloaded and installed it (64-bit). I ran npx create-react-app app which is responsible for creating a react app with boilerplate required.

What problem did this command cause?

Once I ran this command, It would start fetching data from the repository. The folder would be created with the project name having package.json, package-lock.json, and node_modules folder. After this, the command would run and get stuck at found 0 vulnerabilities.

If you are using cmd on windows

If you are using bash

How to fix this?

I was searching a lot and found out people were asking on StackOverflow about this fix but none of them had answers and
even if some had but they were not useful. So I kept searching on GitHub under issues and came across some fixes. There are 2 ways to solve this.

Fix 1 (Easy One)-

I don't know why but this problem is observed with 12.16.2-x64.msi node version. If you installed x64 version then you just need to uninstall this version and install x32 bit version. This fix should solve your problem.

Fix 2-

If you don't want to reinstall node and continue with the current version then this fix would work.

Open a new cmd window and run resmon command. This command opens resource monitor and you would see something like this -

Once you could see resource monitor. You need to start looking for cmd.exe processes (because there would be more than one cmd.exe based on how many windows you have got open) which are suspended. You could see if a process is suspended by right-clicking on it.
If you find any cmd.exe suspended resume it. Your cmd process would also get resumed. There might be a case where cmd again stops, you just follow the above steps again.

The only problem with this is you might need to follow these steps 1 or 2 times more when using npx create-react-app before the error goes away.

Conclusion -
This was my first blog. This problem was faced by so many people out there so I tried to write this blog.

Thank You