>tfw there is nothing like the JVM for browsers and we're stuck with JavaScript
AUUUGH GANTOO
just wait for webassembly
JS-only webdev cucks are gonna get left in the dust as systems and traditional applications programmers replace all the bloated javascript ninjas.
we have v8/spodermonkey/chakra which is faster anyway
That's pretty much what WebAssembly is going to solve.
Oh, I can't wait to lick the JScucks' tears directly off their eyes as they realize that all the meme.js bloat frameworks they learned and all the hours they spent trying to learn the billions of quirks of this trainwreck of a language were totally wasted.
>but but meme.js 2 is coming out and that has a 8% faster initial render and 13% faster vDom implementation
go fuck yourself, that is meaningless. You are meaningless.
>>54803509
Implying anyone would build a web page in C++
>>54805136
You;re a little deluded if you think that's the purpose of Wasm. The purpose of Wasm will be much more modest than you think. It will be mostly useful for game devs.
the jvm for browsers does exist
it's called "applets"
we had them in the 90s
they were shit
Lol C cucks don't really understand what will Wasm lead to. It will lead to the C-family of languages losing their dominance on the desktop. Basically you will be able to build apps in the browser with the same performance as a desktop app built in C++. Nobody is crazy to build websites in C++..
>>54805216
For now, yeah. No DOM access.
That will probably change after the browsers implement the first revision.
As page load speed, especially on mobile, is really critical, people will need something that is really fast to parse and execute. And that's where webassembly will come in.
Runtime performance improvements, multithreading and the fact that you can use sane languages will really help.
>>54803468
there is nothing wrong with JS
>>54805327
What? Isn't wasm just supposed to be pre-compiled JS bytecode? I'm pretty sure it can do anything plaintext JS can do (assuming it's not running in a webworker, since that does mean a lack of DOM access)
>>54805235
I remember those ugly, buggy grey boxes. Gives me chills just thinking about it.
>>54805196
>implying there won't be a Java to WebAssembly compiler
>>54805496
Well, not really. There are some other differences too, for example there is no garbage collection and some other JS features are not there, as reasonable languages wouldn't need them.
It has access to some things JS does not, and doesn't have access to some things JS has. So currently, it really just is for muh games. And canvas based UIs if you want the literal retards to get mad at you (MUH ARIA, muh A11y!)
>>54805590
I'm kind of ignoring the Emscripten half of the equation, because libraries would need to be written to interact with the various web APIs. But for JS to wasm, that's currently an option, no?
>>54803468
that's literally what asm.js is
>>54805327
> no DOM access
>>54805642
I don't know, I don't think so, though.
Maybe eventually when they add that garbage collector.
i tried writing an asm.js application, how the fuck are you supposed to do anything without dom access?
>>54805691
Paint stuff on a canvas. Use shared memory. Something like this.
Currently, this really is a "muh games" technology.
