Forem: Alireza Hamid

JavaScript Engine, a true story (Part 1)

Alireza Hamid — Mon, 29 Aug 2022 19:15:29 +0000

Anyone who has done any work with JavaScript is likely familiar with the V8 engine. Most people are aware that JavaScript operates in a single thread and employs a callback, which is crucial to the idea behind the language’s engine. Another common misconception is that JavaScript is a compiled language.

Let’s tackle what that means over the next couple of articles.

The mysterious “Engine” about which we speak

Well, if I write some code like this:

const iAmHappy = true;

Just some JavaScript that we whipped up, really. Currently, I am setting the boolean iAmHappy to its correct value. What does this mean, exactly, and how does the computer interpret it? Picture this: someone hands you a computer and instructs you to show a picture of flowers on the screen in Chinese.

Is the computer going to understand what you’re saying? No.
What you just said would be completely lost on the computer. Similarly, if I gave you a computer with a CPU. A file that contains JavaScript. And I tell it, hey, read this file and help me out. At the end of the day, the computer just knows ones and zeros. And when we give it the JavaScript file, it’s like me speaking Chinese to a computer and the computer saying, What? What are you on about?

Plus, speaking to a computer in Chinese while people stare at you as though you’re crazy. As a result, the machine has no idea what JavaScript is. So, how can we communicate using a JavaScript file so that the computer displays floral images? The JavaScript engine is the initial stage in our learning process. With a JavaScript engine right here, you can give this machine the JavaScript file, and this machine will comprehend it and instruct the computer on what to do to display photos of flowers.

Here is the list of JavaScript engines

Google-made Engine — V8 Engine

So, whenever we utilise an engine, we can pass it a JavaScript file. And the engine understands this JavaScript file, allowing it to communicate with the machine, the computer, and instruct it to do what we ask it to do with JavaScript. These engines are now created by programmers.

The V8 engine, for example, is written in C++. But why do these engines become created? When it comes to JavaScript, 2008 was a watershed event in history because Google published V8. Previously, most browsers used extremely primitive engines, which meant that JavaScript was a little slow. Google, you see, had this issue. They had a programme called Google Maps.

As you may be aware, Google Maps is rather a power hog. Multiple functions are supported by it. Google Maps is quite slow in the browser because of features like asking for directions, zooming in and out, and possibly even using Street View. And Google, being a search engine, would prefer that everyone use their search engine, which is why they developed a browser: to increase their market share.

So they used Google Maps and their own Chrome browser and thought, Hmm. The V8 engine will be our own JavaScript engine that we will create. As a result, JavaScript now executes much faster in the browser than it did previously. They also released V eight in 2008. But the main takeaway for us here is that extremely smart people work on these engines to ensure that our JavaScript executes as quickly as possible in the browser, on the server, or on any type of computer. As a result of the work that goes into these engines, JavaScript becomes faster and faster for us every day.

But what is inside this miraculous machine that knows JavaScript? It reads our code and then executes it. :)

Here’s a fun question. Who do you think created the very first JavaScript engine?

Brendan Eich, the creator of the first JavaScript engine, was the first to create it.

While working at Netscape, the first commercially available browser, this individual invented the early version of what became known as Spider Monkey, which Firefox still uses as their JavaScript engine today. And Brendan Eich was the first to invent the language JavaScript to implement this engine, allowing you to execute JavaScript on a browser that could previously only read HTML and CSS.

So we know that the JavaScript engine accepts our written JavaScript code and performs some magic to instruct the machine to do what we want. So, what’s going on within this engine? And now comes the hard part.

As we all know, anyone can build this engine. Yes, you can create your own JavaScript engine, but it’s a lot of work. And, at the end of the day, it’s just a computer programme. And the V8 engine, which is the most popular, most common, and, according to some, quickest JavaScript engine used by the Chrome browser and Node.js, which we’ll discuss later. C++, a low-level programming language, is used to create this engine. But first, let’s take a look at what’s going on inside.

We provide it with a JavaScript file.

And initially, as does lexical analysis, which splits the code into tokens to identify their meaning so that we know what the code is attempting to achieve. And these tokens are combined to produce an AST, which stands for Abstract Syntax Tree.

So we parse the code, that is, we try to figure out how the text is divided up based on JavaScript keywords, and it forms this tree-like structure called abstract syntax tree.

And here’s a nice little web tool you can use to demonstrate this. It depicts the appearance of this abstract syntax tree.

And, while this may appear to you as gibberish right now, it helps the engine to understand what’s going on in the programme or, at the very least, break things down one by one. And once this form is completed, it passes through a process known as an interpretation. We use the Profiler compiler to generate some code, which we will discuss later. And this entire engine will spew out some code that our CPUs on our computers will comprehend in order to give it instructions.

What problem(s) do you see with everyone designing their own engines in JavaScript?
Can we just make our own engine and then, bang, there it is? We’ve got our JavaScript engine. Yes, you can certainly do that.

But keep in mind that our list over here was labelled ECMAScript engines, not JavaScript engines. Because if everyone could just design a JavaScript engine, it would be complete pandemonium, which is why ECMAScript was formed. It tells folks, “Hey, here’s the standard for how to do things in JavaScript and how it should function.”

And the script is JavaScript’s governing body, which effectively chooses how the language should be standardised. So it tells engine creators that this is how JavaScript should function, but how you create the engine internally is up to you as long as it adheres to the standards.

And, to return to our example, as an engine designer, I can do whatever I want with this engine inside of this box as long as it adheres to my script rules. As a result, businesses and organisations compete to have the fastest engine so that people will use their product. For example, Google is keen on having the fastest engine possible so that more people use their Chrome browsers and their search engine, allowing them to sell more ads and generate more cash.

However, keep in mind that this may be implemented in any way we choose and that it is always changing in order to find the quickest way to have JavaScript work in our browsers or even outside of our browsers. And we’ll be talking about the V8 engine because it’s the most common. And you might see various variants on this. However, what we’ll cover here applies to the vast majority of JavaScript engines. And, while things may change over time, as long as you grasp the fundamentals and why it’s structured the way it is, we’ll be able to produce optimal code.

But, before we get there, let's finish the article here, and let’s define what interpreter and compiler are in the next article.

I will update this article by adding the next part link here, so stay with me :)

A headache named default style in CSS

Alireza Hamid — Sun, 30 May 2021 12:15:48 +0000

At least once, Front-end developers tackled default style in their projects and professional life. And also, swearing at CSS creator or Google Chrome and so on as well. So how we can get rid of this nightmare? Is any easy peasy lemon squeezy way to solve the problem?
Yes, this Is the short answer to this question. But how? In this short article or whatever you named, I will introduce how you can reset all the user agent and default styles.

Where the default style comes from?

Before understanding the solution, it's important to understand where we get our basic styles in our browser.
All the properties in CSS come with initial value to load the default style of each property. And this is NOT related to HTML.

The User-Agent Browser Styles

After applying the initial styles of all the CSS properties, the browser finally loads its default styles which are known as user-agent. These styles have nothing to do with the base initial values of the CSS properties.

Also, you can see them in the Chrome developer tools.

For Example:

HTML elements do not have initial style values! The basic styles of an HTML element, such as the <h1> tag, for example, comes from the browser user agent stylesheet and not from the initial value of the properties of CSS.

And now lets to talk about the solution

To reset all the user-agent styles, you can easily use all:unset property for each element in the CSS.
For example: h1{all:unset}
There are different values for all like initial and inherit which you can read about them more in the developer.mozilla.org.

Browser Support

inherit - works in all browsers, including Internet Explorer 11
initial & unset & revert- work in all browsers except for Internet Explorer 11

Final Words

That's all.
I hope you've enjoyed this article and learned from my experience.
If you like this post, I would appreciate applause and sharing :-)

How to fix the CORS issue in Vuejs

Alireza Hamid — Sat, 19 Dec 2020 22:24:51 +0000

Imagine the first day in which you want to connect and implement API(s) from the back-end into your front-end project. Suddenly when you call those API(s) something going wrong, and you likely see this error in your console.

Access to XMLHttpRequest at ‘http://api.back.end/data' from origin ‘http://localhost:8080/' has been blocked by CORS policy.

Boom, everything breaks down. This is a nightmare for developers. But how we can deal with this? Before to solve the problem we should deep dive into this error.

Why do we get CORS error? What really is CORS?

This is a common policy on the web we call it same-origin, which means web applications should interact with other services from the same origin. But sometimes it is required to send a request to another service-- server, back-end, API, and etc. CORS makes it possible to set a specific header on the request to the server. you can read widely about Cross-Origin Resource Sharing (CORS).

In my case, I was serving my Vuejs project on localhost and the API service was running on the server. As you can guess they're were from different origins completely against the same-origin policy as I mentioned. We assume you haven't any access to change the Back-end configuration.

so, How we can deal with CORS error?

Yes, we should have same-origin, But how? Hopefully we can achieve this easily with Vue CLI. In my case, the Front-end project was running on localhost:8080. We actually need to proxy the API requests to the Back-end during development.

To config this setting, you should put the proxy URL into this file vue.config.js if you haven't this file yet in your project, first, you need to create the file right beside the package.json in the root of the project.

// vue.config.js
module.exports = {
  // options...
}

Inside module.exports you can put your configuration using devServer object. Because we want to config our development server to proxy API requests to the Back-end Endpoint.

// vue.config.js
module.exports = {
  devServer: {
        proxy: 'http://api.back.end',
    }
}

This will tell the dev server to proxy any unknown requests (requests that did not match a static file) to http://api.back.end.

Now you need to terminate your app and run it again so that new configurations will be applied to the server. Just that, easy peasy lemon squeezy :))

You can find other configurations here Vue configurations.

If you want to get rid of this issue temporarily just install this chrome extension CORS Unblock.