5 ms·

ugh. I am so sick of this "build a proper VM" wailing. It is such a naive and ignorant position. It completely ignores the reality of the market. JavaScript is

by phpnode 14y ago

ugh. I am so sick of this "build a proper VM" wailing. It is such a naive and ignorant position. It completely ignores the reality of the market. JavaScript is dominant, it is fast, it runs on basically every device, browser vendors are deeply invested in it and you want to throw all that away and start afresh? ASM.js is a realistic way to get better performance today, not in the 10 years or so it would take for a new platform to reach acceptable adoption rates. And who's to say that some new "proper" VM wouldn't end up with warts like JS has anyway?

PommeDeTerre 14y ago
What you're saying is contradictory. If JavaScript is already "fast", then why the need for something like this "to get better performance today"? If JavaScript is "dominant", then why is technology like this needed, mainly to enable developers to use non-JavaScript languages? The market is speaking, and it's saying that JavaScript needs to go. Besides, there are numerous proven VMs and runtimes that could either be used directly, or at least used as a model if a new system is needed. NaCl and PNaCl have already shown one much better approach that is possible. Your "10 years" estimate is not based on reality. And frankly, no, I don't think any proper VM or runtime would ever end up as bad as JavaScript is today. No other language, aside from perhaps PHP, exhibits so many inherent, fundamental flaws. It would take significant effort (and ignorance) to duplicate the same degree of mistake and flaw.
- niggler 14y ago
  "I don't think any proper VM or runtime would ever end up as bad as JavaScript" Flash? Silverlight? ActiveX?
- criley 14y ago
  >"If JavaScript is already "fast", then why the need for something like this "to get better performance today"? This feels obtuse -- obviously JS today is faster than it's ever been, but we want native c performance out of it. Do you have a in-browser VM solution today that can do complex, GPU-powered full 3D on every platform? Then your VM solution is already inferior to javascript and will need significant time, money and development to even catch up to javascripts current level of "fast". (Using, of course, "game" performance as a benchmark for the vague term "fast") >"The market is speaking, and it's saying that JavaScript needs to go. What? How do you rationalize this? Every major browser supports it to their core and most are working on dramatic imporvements for their implementations. Every mobile device supports it natively. Every computer I've seen in the past decade supports it. The market is speaking? Where? Where is the market speaking? What devices are without javascript? What browsers don't support javascript? I think you are confusing the "market" for "a small subset of a-typical vocal developers".
- phpnode 14y ago
  1. speed is relative. it's possible for fast things to go faster. JavaScript as it stands is fast enough for a lot of tasks, ASM.js makes it faster in certain places. This can only be a good thing. 2. The market isn't saying JavaScript needs to go, JavaScript skills are high in demand, more so than ever. 3. This is the crux of your misunderstanding. I agree it would be nice if browsers supported e.g. LLVM out of the box. But they don't. And for political reasons they won't. If a company as large and powerful as Google cannot push NaCl adoption at all in other browsers (and NaCl was announced in 2008, so we're already half way to 10 years), how will you get them to adopt $YourVMofChoice? This is where ASM.js really wins - it is a subset of JavaScript, so it already works in other browsers, albeit without the performance boost and it is much easier for browser vendors to implement support for ASM.js than it is a whole new VM. Being backwards compatible means more web developers are likely to use it which will put pressure on other browser vendors to implement it. No one is arguing that ASM.js is a better technical solution to the problem, but it is a much better practical solution to the problem. 4. So this is another thing. Most of the people who are against ASM.js seem to dislike JavaScript the language. But ASM.js would free you from JavaScript almost entirely. The only time you'd see it is when you're debugging the "bytecode", and surely human readable bytecode is nicer than whatever something like LLVM spits out? Anyway, it seems like slightly curious reasoning.
nbevans 14y ago
ASM.js has nothing to do with performance. It's about abstracting away the utter pile of shit that is JavaScript so that we can start using the languages of real men on the web. There have been plenty of works done in this area already. See WebSharper, Script#... just two of the many available in the .NET ecosystem. ASM.js is about formalising a known-good subset of JS that can be guaranteed to be compatible across browsers and therefore prime territory for building compilers on top of. JS is nothing more than an intermediate language; it is similar to MSIL, JVM Bytecode, ASM. The only difference is that it happens to have a slightly C-style syntax. This is merely a coincidence and does not change the fact that is still an intermediate language designed for the web. It is utterly crazy the world has persisted writing code in it for so long. It is the modern web day equivalent of writing code in Assembly language.
camus 14y ago
saying that javascript is fast doesnt make sense. Is it faster than 5 years ago sure. But the amount of work on needs to do have good performances is just silly. Is it everywhere ? sure. But i've seen a lot of crazy JS demos , i'm running a decent machine ( Macbook pro) and sorry but most of the exemples i see have poor perfomances , and nothing close to native performances. So imagine a soft you need to use 6 hours a day , you'll feel the bad perfs , trust me. So please let's stop saying javascript is fast, it is a lie. Speed is not something absolute , it is relative. It is slower than native and will always be. Native will always be easier to optimize too. Doesnt mean we cant do anything in html5/js , just mean we cant do everything. And the more "special" feature one uses the less "compatible" the js app will be. Now is ASM a good thing sure. But let's not fool people just to promote JS.

by phpnode 14y ago

PommeDeTerre 14y ago

What you're saying is contradictory. If JavaScript is already "fast", then why the need for something like this "to get better performance today"? If JavaScript is "dominant", then why is technology like this needed, mainly to enable developers to use non-JavaScript languages? The market is speaking, and it's saying that JavaScript needs to go. Besides, there are numerous proven VMs and runtimes that could either be used directly, or at least used as a model if a new system is needed. NaCl and PNaCl have already shown one much better approach that is possible. Your "10 years" estimate is not based on reality. And frankly, no, I don't think any proper VM or runtime would ever end up as bad as JavaScript is today. No other language, aside from perhaps PHP, exhibits so many inherent, fundamental flaws. It would take significant effort (and ignorance) to duplicate the same degree of mistake and flaw.

niggler 14y ago
"I don't think any proper VM or runtime would ever end up as bad as JavaScript" Flash? Silverlight? ActiveX?
criley 14y ago
>"If JavaScript is already "fast", then why the need for something like this "to get better performance today"? This feels obtuse -- obviously JS today is faster than it's ever been, but we want native c performance out of it. Do you have a in-browser VM solution today that can do complex, GPU-powered full 3D on every platform? Then your VM solution is already inferior to javascript and will need significant time, money and development to even catch up to javascripts current level of "fast". (Using, of course, "game" performance as a benchmark for the vague term "fast") >"The market is speaking, and it's saying that JavaScript needs to go. What? How do you rationalize this? Every major browser supports it to their core and most are working on dramatic imporvements for their implementations. Every mobile device supports it natively. Every computer I've seen in the past decade supports it. The market is speaking? Where? Where is the market speaking? What devices are without javascript? What browsers don't support javascript? I think you are confusing the "market" for "a small subset of a-typical vocal developers".
phpnode 14y ago
1. speed is relative. it's possible for fast things to go faster. JavaScript as it stands is fast enough for a lot of tasks, ASM.js makes it faster in certain places. This can only be a good thing. 2. The market isn't saying JavaScript needs to go, JavaScript skills are high in demand, more so than ever. 3. This is the crux of your misunderstanding. I agree it would be nice if browsers supported e.g. LLVM out of the box. But they don't. And for political reasons they won't. If a company as large and powerful as Google cannot push NaCl adoption at all in other browsers (and NaCl was announced in 2008, so we're already half way to 10 years), how will you get them to adopt $YourVMofChoice? This is where ASM.js really wins - it is a subset of JavaScript, so it already works in other browsers, albeit without the performance boost and it is much easier for browser vendors to implement support for ASM.js than it is a whole new VM. Being backwards compatible means more web developers are likely to use it which will put pressure on other browser vendors to implement it. No one is arguing that ASM.js is a better technical solution to the problem, but it is a much better practical solution to the problem. 4. So this is another thing. Most of the people who are against ASM.js seem to dislike JavaScript the language. But ASM.js would free you from JavaScript almost entirely. The only time you'd see it is when you're debugging the "bytecode", and surely human readable bytecode is nicer than whatever something like LLVM spits out? Anyway, it seems like slightly curious reasoning.

nbevans 14y ago

ASM.js has nothing to do with performance. It's about abstracting away the utter pile of shit that is JavaScript so that we can start using the languages of real men on the web. There have been plenty of works done in this area already. See WebSharper, Script#... just two of the many available in the .NET ecosystem. ASM.js is about formalising a known-good subset of JS that can be guaranteed to be compatible across browsers and therefore prime territory for building compilers on top of. JS is nothing more than an intermediate language; it is similar to MSIL, JVM Bytecode, ASM. The only difference is that it happens to have a slightly C-style syntax. This is merely a coincidence and does not change the fact that is still an intermediate language designed for the web. It is utterly crazy the world has persisted writing code in it for so long. It is the modern web day equivalent of writing code in Assembly language.

camus 14y ago

saying that javascript is fast doesnt make sense. Is it faster than 5 years ago sure. But the amount of work on needs to do have good performances is just silly. Is it everywhere ? sure. But i've seen a lot of crazy JS demos , i'm running a decent machine ( Macbook pro) and sorry but most of the exemples i see have poor perfomances , and nothing close to native performances. So imagine a soft you need to use 6 hours a day , you'll feel the bad perfs , trust me. So please let's stop saying javascript is fast, it is a lie. Speed is not something absolute , it is relative. It is slower than native and will always be. Native will always be easier to optimize too. Doesnt mean we cant do anything in html5/js , just mean we cant do everything. And the more "special" feature one uses the less "compatible" the js app will be. Now is ASM a good thing sure. But let's not fool people just to promote JS.