Disclaimer: Author is not a js dev. This is strictly an outsider perspective. Please let me know if there is any information which is unclear or plain wrong.
In begginning there was HTML...
- no front end scripting
- static web pages
Front end scripting languages
Then arrives lot of techs for front end scripting like
- flash
- js
- java applets
After a dark period of war and turmoil, the choice converges to JS, with smile on its face and of course with lot of battle scars. Now all from web country speak one language.
All lived, happily ever after.
Well... NO
JS evolution
Any tech has to keep up with ever growing expectations or perish. Same is happening to front end. JS was not intended for heavy work. But, history decided otherwise. JS in first gen web engines was working as an interpreted language. But, it's nice because there is no overhead of compiling them which can take time.
Interpreted languages are very slow and you are good unless you want them to be... you know... faster.
Then a company called google had a project called "google maps" which needed a faster front-end thought, "I am gonna make JS faster and world is going to like it." Competition is the best encouragement!
JIT
They created V8 engine which JIT compiled the JS. JIT stands for just-in-time compilation where stuff goes like this in over simpilified world,
- JS is dynamically typed or duck typed, so we don't know what is parameter's type for methods.
- if a method is called multiple times, that means method is "hot".
- compiler thinks thats a spicy meat ball and goes ahead analyses that. If it can be optimized, it is done. For example, if a parameter is always going to be number for certain method, then goes ahead and makes it that way. "There you go buddy. Comfy? Sleep tight."
It is great, only if world is that sane. If they suddenly send a string parameter to a method that is hitherto optimized for number, ha ha, boy you are in for a ride! It has to be de-optimized to original form and run. I mean compiler should have to work on some assumptions.
Nonetheless, V8 worked great, it set a standard for other JS engines to aspire to.
But
But... in software world or any other world which can exist, there is always a but. Sometimes, because what's there is not good enough. Or because you just have nothing better to do.
Even with V8 and other fancy tech, JS does not come close to compiled set of languages. It is not aimed for it. Web is not in a position to handle major swift to a brand new language.
Then came WASM.
WASM, like an awesome possum
What can you do?
Well, well. WASM stands for web assembly, that allows to write other
language code in browser.
- C - can I run on web?
You go buddy.
- C++ - can I?
Yeah. You can run on browser.
You can run on browser.
Every language can run on browser.
Who are you?
Well. WASM is not tech, but more of a standard that lot of people who has say on web talked and came up with. It is an almost binary like notation to which any language compile to. It promises near native code performance and nice interoperability with JS.
Does it mean two different environments?
You can write any performance critical in any language that can compile down to WASM and of course compile it to WASM. Such methods can be called from JS and it compute return to JS.
Is it the new Js? Why now?
There has been attempts to create fast, typed, js language. asm.js was an early attempt but turned out to be lone dog attempt from mozilla followed by slow and limited adaption by other browser vendors.
On the other hand WASM was a unified effort from ground up. So, it is getting supported by all major browsers.
One another important factor is availability of technology like LLVM that provides a common back end for many language front ends.
It is now being supported by wide variety of languages including to my horror bf.
So, it was meant to be complimentary for the current JS environment not a replacement of it. It is something now all the major browsers support. So, unlike it's ancestors WASM is here to stay.
Top comments (0)