DEV Community: Ekansh Kothiyal

:/javascript/1 - Compiled Or Interpreted? The mystery of JavaScript translation.

Ekansh Kothiyal — Sat, 24 Oct 2020 09:37:27 +0000

Is JavaScript a compiled language or is it interpreted? And why are people so torn between this simple choice?

We know what are the compiled and interpreted languages, as discussed in the previous article in the series. Let's look into it in more detail.

TL;DR

If you're looking for an answer 10 mins before your front-end interview starts - JavaScript is both and say the phrase "Just-In-Time (JIT) Compiler" a couple of times.

You're welcome!

Now let's dive deeper for you, my beautiful explorers of the JS wilderness!

Let's quickly get an overview of what these types of languages mean based on the traditional translations -

Compiled Language

A compiled language is translated directly into native machine code (imagine a file that only contains 0s and 1s) that the processor can execute. Examples: C, C++, Rust, and Go.

Interpreted Language

An interpreted language, on the other hand, is read line by line and executed by an interpreter. Examples: PHP, Python, and Ruby.

Now that the basics are dusted and settled, we continue our exploration of whether JavaScript is compiled or interpreted…

But before we dive any deeper…

Programming languages can have both - compiled and interpreted implementations. It is not part of the language's specification but an implementation decision.

Yes, you read that right! If a language is compiled or interpreted, it's not really the language's call but the way that it has been implemented.

Let's Start The Game, Watson!

Once you eliminate the impossible, whatever remains, however improbable, must be the truth. - Sherlock Holmes

Suspect 1: Is JavaScript Compiled?

Let's take a peek into the popular compiled language C. So we write some C code in an editor (a "sourcecode".c file) and after four steps of the compilation process- preprocessing, compiling, assembling, and linking (ignore the fancy terms for today), the compiler will create an output native code (in a "compiledcode".out file). This compiled file is what we run to see the result of our program.

So for every little change, we compile our program again and then run our executable. If I had a nickel for every little change I had to make on the fly while coding, I would... I don't know, have bought a ton of bitcoin or something! Now if I had to compile my code after every little change on the web, eish! Clearly, that's not how we do things in JavaScript. We are directly running our source code, the javascript we wrote, on the browser. There is no object code that needs to be run. So…

Verdict: Not Compiled!

Suspect 2: Is Javascript Interpreted?

As we know, web developers need to code stuff and run things quickly. Interpreters fit the job description perfectly here. We write a line and hit refresh - voila! Having compiler in this equation, no thanks.

Many definitions on the Internet seem to suggest its Interpreted. So let's try this example code:

Here, it works if you try. So from what we know about the interpreter, it will read line 3 and execute the function foo and pri… wait how does the Interpreter know of the function foo which is down at line number 5? Huh.

This can't be an Interpreter job! How could it know what's coming in the next line? We can rule that out now. There is some aspect of compilation involved here, Watson!

Verdict: Not Interpreted!

Blistering Barnacles, Watson! We are out of suspects!

Wait… what if we are not in a Sherlock Holmes novel but an Agatha Christie story. Like the plot of the book *censored to avoid giving out spoilers, when we are out of suspects, that means everyone is a suspect!*

It's both! * gasps *

The interpreter is amazing if you need to run the code once but when it happens multiple times, it becomes significantly slower in execution as compared to the compiled native code. So there was a need to shrink this gap - enter Just-In-Time compilation over traditional static compilation!

Criminal: Just-In-Time Compiler - the best of both worlds!

It used to be just interpreters back in the day. But in order to overcome the significant inefficiency gap, the browsers started bringing in the compilers for optimizing the process better.

So in a nutshell, the compilation, in this case, happens during the execution.

Every browser has its own way of handling this but generally, a new component called a Monitor (or Profiler) is added to the translator, JS Engine. This Profiler monitors the code for redundant code and the object types.

(A Very) Basic Workflow

First, the Profiler goes over everything. It monitors the process. If a code block runs a lot of times, it is marked "hot".
In the initial run, a non-optimized Abstract Syntax Tree is generated and handed over to the interpreter to execute (will cover in future posts, for now, it's a tree representation of your code). This is to avoid any more delay in execution.
Meanwhile there is an optimization step. The "hot" code block the profiler marked earlier is sent to another optimizing compiler that converts it to a faster and more optimized version of itself after proper checks.
If all things look fine, this optimized version is sent and we have a better code. However, if there are some problems with this optimized code, JIT will deoptimize *and trash this optimization, the non-optimized machine code is executed instead. *FYI this has a small performance hit.
So the profiler and the compiler are working together to give you the best possible performance.

Therefore,

The JIT compilation makes your code faster through monitoring the code and optimizing the recurring similar code blocks. And yes, this has its own overhead added to the process but the performance gains outweigh those.

Next in the series, we might *take a look into the JavaScript runtime ecosystem. *Whatever that means :/

💜

References

[1] A crash course in just-in-time (JIT) compilers by Lin Clark.

[2] Mike Samuel on Is JavaScript interpreted by design?

[3] How Does JavaScript Really Work? (Part 1) by Priyesh Patel

I am writing a series of JavaScript articles aimed at understanding the architecture of this language in the simplest language possible (for me). There are plenty of resources aimed at syntax learning. Not many people understand the jargons that are around a lot or what is really happening behind the scenes. Hope you like it!

In the words of Ed Sheeran, "My, my, my, my, oh give me love" 💜

:/javascript/0 - The Bare Minimum Computer Fundamentals

Ekansh Kothiyal — Wed, 21 Oct 2020 07:09:37 +0000

It's 2020! Everyone is saying developing websites is easy. It is. You learn the basics of HTML and CSS. Done! Now you start learning JavaScript. You can officially say at parties that you create websites.

So what is JavaScript?

JavaScript is a synchronous, blocking, single-threaded, dynamic language, supporting object-oriented, imperative, and declarative (e.g. functional programming) styles. Javascript is an exasperating farrago of distortions! [1]

Yeah, of course, it's synchronous and single-threaded and that "farragos" thing… I know that! I think I can start with React now.
[Dramatization based on real-life events]

I don't know about others but I, sure as hell, took my sweet amount of time to really know what all that "farragos" and alike, all meant. Being a good samaritan, I thought I should create a guide. This is for beginners and people like me who were in a hurry to skip the JS basics.

For learning the coding syntax and implementation, I always suggest starting with freecodecamp.org.

The Introduction

I'll start with the assumption that you know a little about computers but really, You know nothing, Jon Doe!

Javascript is a high-level language.

What does that mean? High-level language syntax looks closely like the English language more than it looks like the machine code. In contrast, a low-level language would look more closer to machine code though will not be machine code. This is how you code in a high-level language - a simple example of adding two numbers 1234 and 4321:

Computers don't understand that, not really. They talk in machine code. Machine code is just combinations of 0s and 1s - the language of computers. It looks something like this (the same example of adding 1234 and 4321):

Source: http://www.dspguide.com/ch4/5.htm

Translation

So now we have two entities - a computer and you, the user. Since we have two entities speaking different languages, we need a translator in order to enable a "conversation" between the two.

Fundamentally, we have three ways of these translations:

a. Assembler

b. Compiler

c. Interpreter

1. Assembler

The assembler converts low-level assembly code into machine code - what's assembly code? For now, it's basically just a "placeholder instruction" of a combination of bits that mean something to your computer. You are more in control of instructing what the computer does, one instruction at a time. Example: I want to instruct my computer to allocate two bytes of storage to a variable "x" and initialize it with a value 23. The assembly language code would look like:

x: .word   23

How it's different from other approaches is that it just does a 1-on-1 translation of mnemonics and literally just replace the labels with their machine code counterpart. I would suggest Google about it to know more.

2. Compiler and Interpreter

A Compiler will "process" the source file to machine code (or bytecode) before executing while an Interpreter will start "reading" the source code one line at a time and start executing.

I'll borrow Almog Adziashvili's fun alcohol analogy to explain the difference.

Let's make a Mojito!

You need -

White Rum

Fresh Lime Juice

2 teaspoons sugar

6 mint leaves

Soda Water We have two ways - the Compiler Way and the Interpreter Way.

**Compiler Way: ** We gather all the ingredients and the amount of those ingredients required in one place. Now we add all these in a blender together to mix.

Interpreter Way: We take the blender glass and start getting the ingredients one at a time. First the White Rum from the bar cabinet, then we go to the refrigerator to get the lime juice and run the blender, then add the sugar and run the blender, and so on.

Voila! We have the mojito ready and it's going to taste the same both ways.

In a compilation, the time to build a compiled code (i.e. the ingredient preparation time) is longer than the interpreter way BUT the run time (i.e. the time to mix the ingredients) is less than the interpreter way.

Continuing on the example, you will have to gather the ingredients again before the blending part, whenever your mom has cleaned the kitchen again or you are making a mojito in a different house. So this process of building the compiled code is going to happen every time you want to run your source code after a change (however small) or in a different environment.

Closing argument: The compiler is usually more secure since the compiled code is just machine code. It needs no source code to run. So no source is exposed. This is faster and provides a ready-to-run executable on the machine.
The interpreter is faster during the development phase - quick debugging and can be run on any machine that can support it. A little slower on runtime but faster while creating prototypes.

Question of the Hour: So is JavaScript compiled or interpreted?

Take your time to think. The elders call it interpreted. So it has a line by line execution way. Seems about right. Is it though?

*music intensifies*
Get your mind gears moving and wait for tomorrow!

I am posting about it in detail in the next article in the series this week.

References

[1] Referencing a viral tweet in 2017 from the Indian Politician, Dr. Shashi Tharoor.

[2] JavaScript - is it Compiled or Interpreted? by Almog Adziashvili.

I am writing a series of JavaScript articles aimed at understanding the architecture of this language in the simplest language possible. There are plenty of resources aimed at syntax learning. Not many people understand the jargons that are around a lot or what is really happening behind the scenes. Hope you like it!
Show some love (in any form really) <3

Duck Punching in JavaScript (with Example)

Ekansh Kothiyal — Fri, 19 Jun 2020 20:32:24 +0000

We have the famous Duck Test:

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck!

Coasting off that, we have Duck Punching (or Monkey Patching) in programming — a technique wherein alterations are made to a dynamic code during runtime without altering the source code.

Here is a great Consolia Comic strip to give you a better understanding in a funnier graphical way (if you’re into that):

Source: Consolia-Comic

So let’s dive straight into an example and get our hands a little dirty:

Problem Statement

We have the popular indexOf function in JavaScript’s String prototype. The indexOf function returns the first occurrence of the search value inside the string that calls it.

'King, are you glad you are the king?'.indexOf(‘you’);
// returns 10

Suppose you wanted to do something extra on top of this function by extending the legacy indexOf function. You were asked to add an optional parameter that would give you the last occurrence index instead — a simple boolean flag.

Let’s do some duck punching -

There you go! But let’s break that down a little bit.

We start with the simple Duck Punching pattern:

const oldMethod = Class.prototype.method;
Class.prototype.method = function (arguments) {
// Do Your Magik Thang!
return oldMethod.call(this, arguments);
}

Explanation: In the first line — we save the legacy prototype method inside a variable. In the subsequent lines, we redefine this method and do our ‘thang’ and we have extended the capabilities of a legacy function.

First, we initialize the old method to a new variable and then assign the indexOf method to a new method.

const legacyIndexOf = String.prototype.indexOf;
String.prototype.indexOf = function () {
}

Second, we add a new parameter getLastIndexFlag that defaults to false and we have two conditions based on its value. If the getLastIndexFlag value passed is false/null, we use the existing indexOf() functionality in the if block. But if the getLastIndexFlag is set to true, we get into the else block where we reverse the string using the Array method and call our legacy indexOf().

String.prototype.indexOf = function (searchValue, fromIndex, getLastIndexFlag = false) {
if (!getLastIndexFlag) {   
        return legacyIndexOf.call(this, searchValue, fromIndex);  
    } else {   
        return legacyIndexOf.call(this.split(' ').reverse().join(' '), searchValue, fromIndex);  
    }
}

Let’s try it out:

'King, are you glad you are the king?'.indexOf(‘you’, null, true);
// returns 14

Voila! There is your better version of indexOf as per your workplace needs!

Note: The 2nd parameter - null is passed for the fromIndex parameter that tells what index to start the search for in the original indexOf function.

So that was one example of Duck Punching. You can basically extend from the idea and work with your use case. A great way to articulate the advantage of this is how Paul Irish puts it -

a way to fulfill your own feature request on a library.

Future

Duck Punching has somewhat become less of a thing now by 2020 (or so I have been told by my more experienced colleagues). There are better methods using do the same thing (yet to explore). It still was a fun thing to read about and from my experience still a common coding tool in your back pocket.

Cheers!