3 ms·

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

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.

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.