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
Top comments (0)