I feel like PNaCl is the technically superior approach - define a stable set of LLVM bytecode and build an interface to run it in the browser. But the uptake is a problem, no other browser maker wants to adopt a big chunk of code controlled by Google, tailored to run optimally in Chrome.
So asm.js took a beeline - leveraging existing Javascript machinery for security/JIT and shoehorning a way to run executable LLVM on top of it. The fact that it's Javascript is just a detail, a legacy of the days when one vendor (Netscape) was able to push through a standard for running code in the browser.
In today's fragmented browser landscape I find it hard to believe a consensus could be reached again. Most of the major browser makers (Google, Microsoft, Apple) have their own platform agenda to push - in that context asm.js's compatibility with existing Javascript engines gives it the best chance of adoption.
But I agree, the hoops that had to be jumped through are a damned shame.
> I feel like PNaCl is the technically superior approach - define a stable set of LLVM bytecode and build an interface to run it in the browser.
I don't agree. I think that LLVM bitcode was not really designed for this either [1]. Google has not succeeded in eliminating all of the undefined behavior from LLVM [2]. At least asm.js has a fully defined semantics as specified by ECMA-262. For any hope of interoperability between browsers, that's critical. Things like order of iteration of properties were once left undefined by ECMA-262, but pages began to rely on Netscape's behavior and other browsers had to reverse engineer what Netscape did. Eventually they were added to the standard. Likewise, without all the undefined behavior removed from PNaCl, anyone who wanted a separate implementation of PNaCl would have to reverse engineer what Chrome did.
There is also the issue of compilation speed: asm.js was designed to compile quickly by a backend that doesn't do much optimization. LLVM, on the other hand, was optimized for -O2, which compiles much less quickly. PNaCl at -O0 is far worse than either V8 or OdinMonkey. On the Web, compilation speed matters a lot.
I think an actually technically superior approach, if backwards compatibility were not a concern, would involve:
1. A from-scratch, untyped, non-SSA bytecode, basically an isomorphism to asm.js. All operations would have fully defined semantics. This would yield fast compilation without the JavaScript syntax and would be amenable to multiple backends, like LLVM or V8.
2. A mechanism for providing a C binding to WebIDL-based Web APIs. This would eliminate the necessity of Pepper and would mean that any new Web APIs would instantly be available to native code.
PNaCl, unfortunately, is neither of these. asm.js isn't either, but I think it's closer to this ideal than PNaCl is.
> So asm.js took a beeline - leveraging existing Javascript machinery for security/JIT and shoehorning a way to run executable LLVM on top of it.
A big advantage of asm.js over PNaCl is that it's not LLVM.
On the other hand PNaCl is very tightly coupled to LLVM. Any time I find myself checking if a some $feature is available in PNaCl, the discussion revolves around what LLVM can or can't do and how LLVM does it, see [1] for most recent example.
I just can't see how PNaCl could be meaningfully reimplemented. Reimplementing it from scratch would require implementing something bug-for-bug compatible with LLVM. That's a gargantuan task. On the other end of the spectrum, why not just use the original implementation? Then it would work very much like any other plugin. I don't think it's a good solution. It seems the only remaining option is implementing it on top of LLVM. But then you still share all potential limitations (e.g. in portability) and all security issues with all other LLVM-based implementations. It could end up being not that bad -- it means more work on LLVM itself, making it better -- but I'm not sure if that would offset the other problems. How many features that appeared first in chrome or webkit were then reimplemented elsewhere in a different, better way? Do we want to end up with only one browser? No, there are lots of things we wouldn't have if Firefox didn't happen, there are lots of things we wouldn't have if Chrome didn't happen. Do we want to end up with only one PNaCl runtime?
From a developer's perspective PNaCl and emscripten is almost the same to work with, the difference is just a couple of hundred lines of wrapper code (less then the differences betwenn iOS and Android wrapper code) and you need to find a higher abstraction layer for threaded code. And if the differences on the surface are so small, and the performance difference is acceptable as well (it is IMHO), I don't really care how the goal is achieved under the hood. Asm.js or PNaCl are not platform-lock-ins like DirectX or Flash. It's just POSIX + OpenGL with a handful of platform-specific functions, and practically the same code compiles on any other POSIXish + OpenGLish platform.
The other big advantage of PNaCl is that you have the option of distributing it as a signed application that the user downloads once. This is critical for doing in-browser encryption or manipulating sensitive data. You need there to be a trusted runtime that makes this possible, but this can't be done in pure Javascript (where it's too easy to insert malicious code that leaks your keys). It's not enough to simply use a crypto API in the browser either---you don't want the Javascript to touch the data at all (otherwise, it could leak the plaintext). Moreover, unlike Java and Flash, PNaCl code is compiled in such a way that the browser can do just-in-time static analysis to verify that the code cannot escape the runtime. These two features---signed code that's trust-on-first-use and JIT static analysis---make PNaCl a much more desirable runtime than asm.js in my opinion.
What I miss in all those discussions regarding JS, asm.js and PNaCl is that the web is the best software distribution platform we have by a huge margin, this is really its overwhelming killer-feature. All the user needs is an URL. No "downloading", no installation, no special user permissions, no app shops, no gate keepers, no walled gardens, and everything is automatically multi-OS and multi-CPU-architecture. The web as a runtime platform may not be ideal, but the web as a "software distribution platform" rocks. For this I'm even happy to give up a few CPU cycles. And no platform should be tied to a specific language. The more choices there are, the better.
Have you actually shipped a complex codebase to the web? There are a TON of major issues which are just as bad:
Old problem: Downloading
New problem: Downloading. Large JS apps have to asynchronously load potentially very large codebases, every time the app is loaded
Old problem: Installation
New problem: Installation. What if the user has NoScript? AdBlock? Mobile Opera vs. Mobile Safari vs. Chromium vs. IE.
Old problem: Special User Permissions; gate keepers
New problem: Proxies. Websockets. Anti-virus software. On-machine firewalls. Corporate firewalls. "Special" toolbars and plugins that redirect the browser.
The web is not a "software distribution platform". It is not a "distribution platform", because code is retrieved on-demand and run, and there is no simple way to "cache" that locally and re-run it. (Chrome App Store does not count, because it is antithetical to the model you've described). It is not even software in the traditional sense that you mean, because everything is inherently client-server, so most of the app lives on the server or in the cloud.
> All the user needs is an URL. No "downloading", no installation, no special user permissions, no app shops, no gate keepers, no walled gardens...
Exactly. The humble hyperlink is the most amazing thing about the web. It's simple yet devastatingly powerful.
I'm not a snob about the programming languages of the web. I don't care what language I need to learn to create content for the web, or what tools I need to use. The language and the tools will always be a means to an end — that is, the radical ability to provide free and instant access to any content for everyone on the Internet.
The browser, html/css/js, is the most ubiquitous common runtime that has ever existed.
A lot of services have an iPhone app, an android app, and sometimes even a desktop program. But if you have a website, you get all of those platforms at once.
Sure you have to do things differently, usually more slowly, but you can do whatever you do on any device with a browser.
Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java.
Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care that the webkit codebase got, this would no longer be an issue.
Many people remember java to be sloooow. When I first came into contact with it in school, that was certainly the case, but since a couple of years it has had a modern JIT that could easily rival native code.
Java applets are ugly, sure, but that is largely due to the decades old AWT, and the poor font support it used to have. With SWT, you can have native widgets (dunno if they work in Applets, but they are nice on the Desktop), and with antialiased drawing you can get the same results as with HTML5 canvas.
Java applets (and Flash, and Silverlight) died for marketing reasons, and political reasons. There were no unsurmountable technical issues. The outcome is that we are stuck with "worse is better" for the foreseeable future, only max. 50% to 1% of the possible native performance, and a bunch of restrictions we only slowly realize what they mean (no sockets, no signed applications, no anonymous/serverless mashups, less hardware access than we used to have, suboptimal caching, suboptimal tooling like languages, debuggers, content creation tools (I haven't seen anything that can replace Flash for simple vector animations yet) and so on.
This discussion is missing the simple point that the web is rapidly gaining all the flaws that Flash used to have, without the nice (for some) editing environment.
The web really isn't suited for app development at all, as the native mobile markets have demonstrated, while the viability of it as a document delivery platform diminishes every time the content gets hidden behind a massive layer of scripts.
It's very simple - there is no magic here. asm.js is just a "pidgin instruction set architecture", to allow communication between an emerging set of VMs - the browser runtimes - and a compiler backend. (The front-ends are the LLVM front-ends.)
The article is exactly right in saying that it's a way to route around JS. Javascript fanboys should not be praising asm.js, because it's a way to route around them. (Which is fine by me; JS is an abortion of a language that cannot die fast enough.)
I see asm.js as the Revenge of Compiled Languages. Coupled with generic interfaces for accessing underlying graphics and audio hardware, we're just right back where we started with Java applets. Write your apps in whatever language; run in the browser.
This article neatly sums up my thoughts on asm.js. On the one hand, I really like the fact that Mozilla is doing a lot to promote Javascript (which I usually enjoy programming in). On the other, asm.js basically destroys any reason to write Javascript.
For someone interested in web-based gaming, it really discourages me from investing in Javascript-based tools, since the future _won't_ be hand-written Javascript. It's only a matter of time before a tool like Unity includes an asm.js export target.
asm.js is brilliant because of the current situation we are in. However, the current situation we are in is silly, and can correctly be called a "tragedy of the commons."
Why? Well, for example, is JavaScript truly the best language we'd be able to create for browser scripting, or did it win by historical accident? (And I'm actually a fan of Javascript programming!)
And beyond that, we'd all like something that gives us safe native-speed rendering control in the "sandbox". Silverlight was meant to, as was Flash/Flex. But those were proprietary, and we didn't want one company to have "control of the web." HTML 5 hasn't been what we hoped for.
So basically, we're one big, divided bureaucracy that is not making rational decisions (what big divided bureaucracy does?).
I guess what might happen is something new will eventually come along (who knows how long it will be) that actually displaces the web as we know it. It will be an adoption-tsunami, similar to what the web itself was, and therefore it will be able to ignore this series of historical accidents that we're chained to today.
I agree, an Unreal Engine compiled to javascript doesn't make sense. It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc.
However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm compiled to javascript. Maybe that is the sweet spot for asm.js: You are still able to support Safari and IE though native javascript, but it's faster on Chrome and Firefox.
> It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc.
Bytecode doesn't mean smaller download or faster startup, or necessarily better performance. It might, but you need numbers to show that.
In practice, right now startup is faster on asm.js than PNaCl, and vice versa for execution speed, but in both cases the differences are not large. Compare for yourself:
"It would make much more sense if it were compiled to some kind of bytecode (like NaCl)."
asm.js is a bytecode. The ".js" is misleading; it's not wrong, but it's misleading. asm.js is actually a bytecode specification that has a syntax that overlaps (but is not a superset of) Javascript, and the semantics of the bytecode overlaps (but is not a superset of) Javascript, but it is not Javascript. It's a bytecode that happens to have a serialization to a Javascript-compatible syntax.
Do not be fooled by the surface appearance and the name. Look at what it does. It is a bytecode, just one with a bizarre serialization. (And as a result of that serialization, the most literal interpretation of "bytecode" admittedly doesn't quite work, but it's a bytecode in every way except for a literal fixed-length code of bytes.)
> I agree, an Unreal Engine compiled to javascript doesn't make sense.
That demo runs at 60 FPS in my browser, allowing me to casually spend more money on more video games. Your objections seem ideological, as opposed to perf benchmarks, distribution improvements or other quantifiable terms.
Original Java bytecode was actually worse than compiling to some real language - all the value lifetime and other optimization information was lost, even conversion to native asm produced unoptimized code. Is NaCl any different? I imagine javascript that is jit-compiled could create a pretty good binary?
>It means JavaScript has nothing to do with it, it's just the poison we ended up with, the bitter pill we supposedly have to swallow.
Yeah. That's right. If we could remake the web from the ground up, and had 100% buy-in from all the major parties (corps and devs) to implement and use the new common standard, JavaScript would not be the central language. But we can't. So welcome to reality.
The article seems pretty doomy regarding asm.js - is it really going to take off and become an unweildy/frozen standard? Or is it of interest only to people writing game engines in pure JS / vanilla browser technologies?
So Asm.js is a strict subset of Javascript, and the author is saying that Asm.js is only useful when you want to compile a C/C++/Whatever library into Javascript, and that it's not interesting for Javascript developers themselves. Then I wonder: why? Can't you write Asm.js code directly (instead of compiling to it)?
You can but it's a bit like writing inline assembly code. The code doesn't look very nice and you lose LLVM's optimizer passes which kick in before the JS code generation.
Yes, asm.js shouldn't be making JS devs too excited, because you shouldn't write asm.js code directly. It's best to take a strongly typed languages and then run it through an asm.js compiler. JS isn't strongly typed and many of the optimizations are unavailable to JS devs. I am happy that V8 is continuing to focus on optimizations that serve the JS writers and I hope the language survives because I really love writing it.
> "And this is really the biggest contradiction of them all. Tons of people have invested countless hours to build these VMs, these new languages, these compilers, these optimizations. Yet somehow, they all seem to agree that it is impossible for them to sit down and define the most basic glue that binds their platforms, and implement a shared baseline for their many innovations. We really should aim higher than a language frozen after 10 days, thawing slowly over 20 years."
It's kind of hard to redesign an airplane in flight, and because of the way the web works, that's a problem that applies to browsers a lot more than some other pieces of software.
> It's kind of hard to redesign an airplane in flight
It is true that IE6 was 5 years in flight. However that has changed. Google replaces Chrome plane each 6 weeks.
JavaScript it is new IE6.
I really would like to see Dart in Chrome stable release. Sometime ago I thought that pure VM, like JVM, would be better. Now I think it is safer to leave scripts loaded as plain text. Just like HTML, CSS. It is hard to guess how whole web ecosystem would work with scripts loaded as bytecode.
hot swapping and migration are extremely well solved problems in software... the reason you see it screwed up so much as that few people actually care about it at all.
i'm convinced that fear and lack of understanding are the genuine problems here...
browsers and the webstack are fantastically shoddy and poorly engineered though and that is a serious obstacle... but it doesn't make the problem intractable or hard. 'just' effort.
Compile some non-Javascript code.
Create a package containing the native code.
Serve ASM.js and the native web library.
This package is then installed in the browser and the browser switches to it when it detects code that is about to be used that matches the installed web library signature.
If the browser supports native web libraries, it uses that.
Otherwise it falls back to ASM.js.
Either way, we gain performance and we can compile code natively AND to ASM.js.
Please don't get me wrong, I was just looking for confirmation of the same error. I love Firefox. Even I never switch to Chrome for common office work.
I know microsoft will stop supporting XP, but hopefully Mozlla don't [1].
Unfortunately, in some third world companies (like where I work), IT guys prefer not to change what works until it is absolutely necessary.
I am surprised that Dart is not mentioned as a comparison in any of the comments. It is also heralded as a better and more performant Javascript. Is it because the use-case of ASM more limited? I would imagine that DOM integration in ASM would be tricky so that would set Dart apart.
[+] [-] safetydank|12 years ago|reply
So asm.js took a beeline - leveraging existing Javascript machinery for security/JIT and shoehorning a way to run executable LLVM on top of it. The fact that it's Javascript is just a detail, a legacy of the days when one vendor (Netscape) was able to push through a standard for running code in the browser.
In today's fragmented browser landscape I find it hard to believe a consensus could be reached again. Most of the major browser makers (Google, Microsoft, Apple) have their own platform agenda to push - in that context asm.js's compatibility with existing Javascript engines gives it the best chance of adoption.
But I agree, the hoops that had to be jumped through are a damned shame.
[+] [-] pcwalton|12 years ago|reply
I don't agree. I think that LLVM bitcode was not really designed for this either [1]. Google has not succeeded in eliminating all of the undefined behavior from LLVM [2]. At least asm.js has a fully defined semantics as specified by ECMA-262. For any hope of interoperability between browsers, that's critical. Things like order of iteration of properties were once left undefined by ECMA-262, but pages began to rely on Netscape's behavior and other browsers had to reverse engineer what Netscape did. Eventually they were added to the standard. Likewise, without all the undefined behavior removed from PNaCl, anyone who wanted a separate implementation of PNaCl would have to reverse engineer what Chrome did.
There is also the issue of compilation speed: asm.js was designed to compile quickly by a backend that doesn't do much optimization. LLVM, on the other hand, was optimized for -O2, which compiles much less quickly. PNaCl at -O0 is far worse than either V8 or OdinMonkey. On the Web, compilation speed matters a lot.
I think an actually technically superior approach, if backwards compatibility were not a concern, would involve:
1. A from-scratch, untyped, non-SSA bytecode, basically an isomorphism to asm.js. All operations would have fully defined semantics. This would yield fast compilation without the JavaScript syntax and would be amenable to multiple backends, like LLVM or V8.
2. A mechanism for providing a C binding to WebIDL-based Web APIs. This would eliminate the necessity of Pepper and would mean that any new Web APIs would instantly be available to native code.
PNaCl, unfortunately, is neither of these. asm.js isn't either, but I think it's closer to this ideal than PNaCl is.
[1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...
[2]: http://www.chromium.org/nativeclient/pnacl/stability-of-the-...
[+] [-] phaker|12 years ago|reply
A big advantage of asm.js over PNaCl is that it's not LLVM.
On the other hand PNaCl is very tightly coupled to LLVM. Any time I find myself checking if a some $feature is available in PNaCl, the discussion revolves around what LLVM can or can't do and how LLVM does it, see [1] for most recent example.
I just can't see how PNaCl could be meaningfully reimplemented. Reimplementing it from scratch would require implementing something bug-for-bug compatible with LLVM. That's a gargantuan task. On the other end of the spectrum, why not just use the original implementation? Then it would work very much like any other plugin. I don't think it's a good solution. It seems the only remaining option is implementing it on top of LLVM. But then you still share all potential limitations (e.g. in portability) and all security issues with all other LLVM-based implementations. It could end up being not that bad -- it means more work on LLVM itself, making it better -- but I'm not sure if that would offset the other problems. How many features that appeared first in chrome or webkit were then reimplemented elsewhere in a different, better way? Do we want to end up with only one browser? No, there are lots of things we wouldn't have if Firefox didn't happen, there are lots of things we wouldn't have if Chrome didn't happen. Do we want to end up with only one PNaCl runtime?
[1]: https://code.google.com/p/nativeclient/issues/detail?id=3475
[+] [-] flohofwoe|12 years ago|reply
[+] [-] jude-|12 years ago|reply
[+] [-] thatthatis|12 years ago|reply
This is the key. With asm.js the worst case is slow, not totally broken.
[+] [-] flohofwoe|12 years ago|reply
[+] [-] pwang|12 years ago|reply
Old problem: Downloading
New problem: Downloading. Large JS apps have to asynchronously load potentially very large codebases, every time the app is loaded
Old problem: Installation
New problem: Installation. What if the user has NoScript? AdBlock? Mobile Opera vs. Mobile Safari vs. Chromium vs. IE.
Old problem: Special User Permissions; gate keepers
New problem: Proxies. Websockets. Anti-virus software. On-machine firewalls. Corporate firewalls. "Special" toolbars and plugins that redirect the browser.
The web is not a "software distribution platform". It is not a "distribution platform", because code is retrieved on-demand and run, and there is no simple way to "cache" that locally and re-run it. (Chrome App Store does not count, because it is antithetical to the model you've described). It is not even software in the traditional sense that you mean, because everything is inherently client-server, so most of the app lives on the server or in the cloud.
[+] [-] neave|12 years ago|reply
Exactly. The humble hyperlink is the most amazing thing about the web. It's simple yet devastatingly powerful.
I'm not a snob about the programming languages of the web. I don't care what language I need to learn to create content for the web, or what tools I need to use. The language and the tools will always be a means to an end — that is, the radical ability to provide free and instant access to any content for everyone on the Internet.
(from a blog post I wrote "why I create for the web": http://blog.neave.com/post/64669185529/why-i-create-for-the-... )
[+] [-] thatthatis|12 years ago|reply
The browser, html/css/js, is the most ubiquitous common runtime that has ever existed.
A lot of services have an iPhone app, an android app, and sometimes even a desktop program. But if you have a website, you get all of those platforms at once.
Sure you have to do things differently, usually more slowly, but you can do whatever you do on any device with a browser.
[+] [-] captainmuon|12 years ago|reply
Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care that the webkit codebase got, this would no longer be an issue.
Many people remember java to be sloooow. When I first came into contact with it in school, that was certainly the case, but since a couple of years it has had a modern JIT that could easily rival native code.
Java applets are ugly, sure, but that is largely due to the decades old AWT, and the poor font support it used to have. With SWT, you can have native widgets (dunno if they work in Applets, but they are nice on the Desktop), and with antialiased drawing you can get the same results as with HTML5 canvas.
Java applets (and Flash, and Silverlight) died for marketing reasons, and political reasons. There were no unsurmountable technical issues. The outcome is that we are stuck with "worse is better" for the foreseeable future, only max. 50% to 1% of the possible native performance, and a bunch of restrictions we only slowly realize what they mean (no sockets, no signed applications, no anonymous/serverless mashups, less hardware access than we used to have, suboptimal caching, suboptimal tooling like languages, debuggers, content creation tools (I haven't seen anything that can replace Flash for simple vector animations yet) and so on.
[+] [-] fidotron|12 years ago|reply
The web really isn't suited for app development at all, as the native mobile markets have demonstrated, while the viability of it as a document delivery platform diminishes every time the content gets hidden behind a massive layer of scripts.
[+] [-] pwang|12 years ago|reply
The article is exactly right in saying that it's a way to route around JS. Javascript fanboys should not be praising asm.js, because it's a way to route around them. (Which is fine by me; JS is an abortion of a language that cannot die fast enough.)
I see asm.js as the Revenge of Compiled Languages. Coupled with generic interfaces for accessing underlying graphics and audio hardware, we're just right back where we started with Java applets. Write your apps in whatever language; run in the browser.
[+] [-] endemic|12 years ago|reply
For someone interested in web-based gaming, it really discourages me from investing in Javascript-based tools, since the future _won't_ be hand-written Javascript. It's only a matter of time before a tool like Unity includes an asm.js export target.
[+] [-] andyjohnson0|12 years ago|reply
[+] [-] charlieflowers|12 years ago|reply
Why? Well, for example, is JavaScript truly the best language we'd be able to create for browser scripting, or did it win by historical accident? (And I'm actually a fan of Javascript programming!)
And beyond that, we'd all like something that gives us safe native-speed rendering control in the "sandbox". Silverlight was meant to, as was Flash/Flex. But those were proprietary, and we didn't want one company to have "control of the web." HTML 5 hasn't been what we hoped for.
So basically, we're one big, divided bureaucracy that is not making rational decisions (what big divided bureaucracy does?).
I guess what might happen is something new will eventually come along (who knows how long it will be) that actually displaces the web as we know it. It will be an adoption-tsunami, similar to what the web itself was, and therefore it will be able to ignore this series of historical accidents that we're chained to today.
[+] [-] ma2rten|12 years ago|reply
However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm compiled to javascript. Maybe that is the sweet spot for asm.js: You are still able to support Safari and IE though native javascript, but it's faster on Chrome and Firefox.
[+] [-] azakai|12 years ago|reply
Bytecode doesn't mean smaller download or faster startup, or necessarily better performance. It might, but you need numbers to show that.
In practice, right now startup is faster on asm.js than PNaCl, and vice versa for execution speed, but in both cases the differences are not large. Compare for yourself:
http://www.flohofwoe.net/demos.html
http://trypepperjs.appspot.com/examples.html
[+] [-] jerf|12 years ago|reply
asm.js is a bytecode. The ".js" is misleading; it's not wrong, but it's misleading. asm.js is actually a bytecode specification that has a syntax that overlaps (but is not a superset of) Javascript, and the semantics of the bytecode overlaps (but is not a superset of) Javascript, but it is not Javascript. It's a bytecode that happens to have a serialization to a Javascript-compatible syntax.
Do not be fooled by the surface appearance and the name. Look at what it does. It is a bytecode, just one with a bizarre serialization. (And as a result of that serialization, the most literal interpretation of "bytecode" admittedly doesn't quite work, but it's a bytecode in every way except for a literal fixed-length code of bytes.)
[+] [-] ozten|12 years ago|reply
That demo runs at 60 FPS in my browser, allowing me to casually spend more money on more video games. Your objections seem ideological, as opposed to perf benchmarks, distribution improvements or other quantifiable terms.
Can you expand on why it doesn't make sense?
[+] [-] JoeAltmaier|12 years ago|reply
[+] [-] macspoofing|12 years ago|reply
Yeah. That's right. If we could remake the web from the ground up, and had 100% buy-in from all the major parties (corps and devs) to implement and use the new common standard, JavaScript would not be the central language. But we can't. So welcome to reality.
[+] [-] haberman|12 years ago|reply
[+] [-] Torn|12 years ago|reply
The article seems pretty doomy regarding asm.js - is it really going to take off and become an unweildy/frozen standard? Or is it of interest only to people writing game engines in pure JS / vanilla browser technologies?
[+] [-] gitaarik|12 years ago|reply
[+] [-] flohofwoe|12 years ago|reply
[+] [-] logn|12 years ago|reply
[+] [-] vanderZwan|12 years ago|reply
It's kind of hard to redesign an airplane in flight, and because of the way the web works, that's a problem that applies to browsers a lot more than some other pieces of software.
[+] [-] dgregd|12 years ago|reply
It is true that IE6 was 5 years in flight. However that has changed. Google replaces Chrome plane each 6 weeks.
JavaScript it is new IE6.
I really would like to see Dart in Chrome stable release. Sometime ago I thought that pure VM, like JVM, would be better. Now I think it is safer to leave scripts loaded as plain text. Just like HTML, CSS. It is hard to guess how whole web ecosystem would work with scripts loaded as bytecode.
[+] [-] jheriko|12 years ago|reply
i'm convinced that fear and lack of understanding are the genuine problems here...
browsers and the webstack are fantastically shoddy and poorly engineered though and that is a serious obstacle... but it doesn't make the problem intractable or hard. 'just' effort.
[+] [-] samsquire|12 years ago|reply
Compile some non-Javascript code. Create a package containing the native code. Serve ASM.js and the native web library.
This package is then installed in the browser and the browser switches to it when it detects code that is about to be used that matches the installed web library signature.
If the browser supports native web libraries, it uses that. Otherwise it falls back to ASM.js.
Either way, we gain performance and we can compile code natively AND to ASM.js.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] franole|12 years ago|reply
[+] [-] melling|12 years ago|reply
http://www.microsoft.com/en-us/windows/enterprise/endofsuppo...
[+] [-] franole|12 years ago|reply
Please don't get me wrong, I was just looking for confirmation of the same error. I love Firefox. Even I never switch to Chrome for common office work. I know microsoft will stop supporting XP, but hopefully Mozlla don't [1]. Unfortunately, in some third world companies (like where I work), IT guys prefer not to change what works until it is absolutely necessary.
Sorry for my English. PS: I'm not that IT gut.
[1] http://www.neowin.net/news/mozilla-to-support-firefox-on-win...
[+] [-] theallan|12 years ago|reply
[+] [-] sanxiyn|12 years ago|reply
JavaScript engines can be run using asm.js. https://github.com/jterrace/js.js is a SpiderMonkey port to Emscripten (with JIT disabled).
[+] [-] gotofritz|12 years ago|reply
It doesn't require requires a plugin install like NaCl
[+] [-] snrip|12 years ago|reply