 |
It's always good to know how JavaScript works behind the scenes, even though you are just a developer using JS and shipping products that works well(sometimes in your machine alone). Being done with RTFM alone doesn't just help you. You just have to dive deeper. Because you might be thinking you are okay with what you know now,
Executing the code in the console,
Copying it to file,
Fetching data from API,
Manipulating DOM
and tada., you are done with your project. But not. JavaScript, now being adopted in all kinds of stack like Front-end, Back-end, and also in mobile as hybrid app, I think, it is wise to know all or at least some deep parts of JS, with good understanding and leverage the power within it.
And also sometimes things can get out of hand suddenly. Because your application has a set of processes for its execution. For example, your code needs to go over a network, received by the client machine, be parsed there, gets executed, gets painted in the DOM, then the server gets hit for every request, and much more.
So I always suggest you to know, not only to make the code work but also to know how the code works.
Only a subtle difference. But makes a lot of sense, right. So knowing the difference and the answer to this question is the objective of this Series - The JS Show.
So to a quick start of the series, let's get into some unknown yet useful parts of JS here in this post.
Your machine is your friend from foreign:
Whatever shit code you write, your friend machine will accept it and executes it. But the thing is, your friend is from a very different city like Wakanda, who speaks a different language like Wakandan. They have the smartest technology and could do lots of cool stuff inside their city, but your friend doesn't know your language. Simply put, to let your friend know what sort of stuff to do with his all smart technology, he needs a software that converts your instruction to the language your friend knows.
This software here for JavaScript is the interpreter. It executes the lines of the code one by one, so does other languages like Ruby, Python, Perl, and many other.
Now, no matter what language you use, what kind of translator it uses, either compiler or interpreter, it has a common thing to be done. It needs to be parsed.
As a developer why should you consider learning about parsing?
The instruction you give to your machine needs to be parsed and be stored in some data structure, that it is most convenient with. The data structure used here is the Abstract syntax tree (AST) or simply put Syntax tree. It just gives the abstract structural details of the construct of your code. But as a developer why should you care about it. Because, you write instructions, which gets parsed, and that parsing takes time. How much time? Roughly 20% of the total execution and rendering of Javascript is occupied by Parsing the language alone, note that here, this time here doesn't say anything about other preprocess, like execution, rendering and much more. So just parsing, it occupies 20%. You must reconsider your decision to know deeper about JavaScript to improve your application's performance.
What after parsing?
Your code needs to be executed, right. How does the code gets executed?
Your code gets executed in the execution context, the execution context is nothing but an environment or the scope provided for execution of code, and on top of which the execution stack(or simply call stack) and memory heap get its place for running the given code. The execution context thing is a pretty interesting topic that deserves a separate post in this JS Show series.
But where does all this happen? Who provides the execution context and all the other hecks? Does your browser take care of these? Yes, but not the whole of a browser. It has lots of other stuff to take care of performance, memory allocation, network monitoring and much more.
So all these JS parsings and executing works are given to some engines. Your browser must possess these engines to cooks the code given. The fastest engine we've got is V8 used by Chrome, and other engines like Spider monkey, Chakra, Nitro engine are also available and used by Firefox, Edge, Safari respectively.
As a developer why should you consider learning about the execution context and Chakras, Monkeys out there?
Remember your code gets executed differently in every engine, so does in every different browser. Your users, don't just stop with one kind of browser. One may use one, the other two may use something else. So it is always a good idea to check whether your code is compatible in every browser you anticipate your users gonna use your application.
So does JS run only in browsers?, but how back end is designed by JS?
No JS can run in the engine alone and not a complete browser is essential. So wrapping up the engine as an executable file, the Node JS was found. Actually, the V8 engine was wrapped inside a C++ program(Fun fact: V8 was itself built on C++) to get the application named Node JS. And here we can run our back end code without the need for browsers. And also remember the Objects like document, window are only available in Browser run JS, and the Node run JS has an object called global, along with other objects which powers NodeJS.
There is still other cool unknown stuff like execution phases, pre-compilation, web API, Garbage collection and much more which I'm more eager to share with you.
So next time as a developer or a student developing some cool project, I hope it would be very helpful for you knowing the unknown and deep parts of JS.
Feel free to ping me or comment below if you find anything irrelevant, annoying, or even if you wish to appreciate it.Written By,
Balaji SV
Nice one dude. Keep coding.
ReplyDeleteThis comment has been removed by the author.
ReplyDelete