16 ms·

On Asm.js

240 points by scribu 13y ago

gotofritz 13y ago
I don't see the problem with asm. It appears that Chrome and Opera support them too. It can only be a good thing. https://blog.mozilla.org/futurereleases/2013/11/26/chrome-and-opera-optimize-for-mozilla-pioneered-asm-js/ https://blog.mozilla.org/futurereleases/2013/11/26/chrome-an... It doesn't require requires a plugin install like NaCl
- JetSpiegel 13y ago
  The article links to that article, come on! Don't people read stuff anymore?
  - waterflame 13y ago
    no.
  - frik 13y ago
    The linked website has an horrible animated background picture. Reading the text is almost impossible with IE 11. Screenshot: http://postimg.org/image/46p2krx95/ http://postimg.org/image/46p2krx95/
    - omeid2 13y ago
      I hate to be that guy, but you're using IE. On a serious note, you can't really blame people for not supporting a browser that needs hack for every single version. Related: http://www.paulirish.com/2011/browser-market-pollution-iex-is-the-new-ie6/ http://www.paulirish.com/2011/browser-market-pollution-iex-i...
      - frik 13y ago
        Ask the JQuery devs, Chrome causes them more troubles than all other modern browsers combined (IE9+, FF, Safari, etc). I am well aware of the history and I hate IE < 10 too. I use FF as main development browser, and beside others of course Chrome and IE 11. The trouble comes when people only test their website with Chrome. I am using IE 11 as I have to at my workplace and it has by far the best UX (IMHO). FF still uses only one process and cannot handle my habit of using dozens or even hundreds of tabs in an optimal way.
      - ben0x539 13y ago
        Meh, delivering a bunch of text with some images and hyperlinks inbetween was pretty much a solved problem twenty years ago. It's nice that there's still progress being made towards doing more interesting things on the web, but if you have trouble pushing text and images to IE the problem might not lie with IE.
    - Jare 13y ago
      IE11 is a very promising alpha release of the next "good" IE.
- coldtea 13y ago
  >I don't see the problem with asm. That's because you didn't read the article. Which among other things, already points to that blog post.
franole 13y ago
Windowx XP give me the blue screen of death, with Firefox 25.0.1
- melling 13y ago
  XP is end of life in 5 months so I would expect a lot more problems in the not so near future. http://www.microsoft.com/en-us/windows/enterprise/endofsupport.aspx http://www.microsoft.com/en-us/windows/enterprise/endofsuppo...
  - camus2 13y ago
    like gigantic botnets due to unpatched zero day exploits.
- franole 13y ago
  My first comment and I get down votes :( 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-windows-xp-after-microsoft-ends-support-for-the-os http://www.neowin.net/news/mozilla-to-support-firefox-on-win...
  - binarycrusader 13y ago
    After Microsoft stops providing security updates, it will no longer effectively work. You really, really need to upgrade somehow. It really is necessary. If you can't upgrade Windows, you need to consider moving to a different operating system.
deleted 13y ago
[deleted]
Torn 13y ago
The citadel demo, if anyone's looking for it: http://www.unrealengine.com/html5/ http://www.unrealengine.com/html5/ 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?
- girvo 13y ago
  Honestly, I've got no idea what the OP was trying to say... I think they are implying that asm.js is cool, but they're annoyed that it's being built on top of JS rather than from-scratch.
  - sp332 13y ago
    It's ignoring history. The author is saying that browser developers should get together and agree on something better than JavaScript. At first this seems quite possible, since browsers come out with new features all the time. But people have been trying to replace js for a long time and it has never ever worked.
  - Ygg2 13y ago
    Second this. I get that they are saying - asm.js is cool, but it's on JS, so eugh. Personally I'd love for a really low level language (statically typed, little if any magic, no-GC, multi-threaded) to work across all browsers, but I don't think browser vendors can just sit and say - here is the perfect cross browser language that will make all of net easy. Perhaps the best strategy is to have low level strict language on top of which you build more easier to use constructs - which describes IMO both asm.js and PNaCl.
    - acqq 13y ago
      As the writer of the native compilers, I read the article as written from the kind of the developer who always developed in interpretative languages, who sees asm.js as "wrong" because "it's not the JavaScript he would write by hand. And again. as the writer of the native compilers, I'm absolutely pro asm.js. I believe it's the best direction that JavaScript optimization can take, solving more hard problems elegantly. Including the fact that asm.js is a better representation than most of bytecodes (or even all). Seriously.
felxh 13y ago
I definitely recommend poking around the console on this site!
safetydank 13y ago
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.
- flohofwoe 13y ago
  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.
  - CmonDev 13y ago
    Good enough for C++, but with JVM/CLR languages running them right in the browser would be more ideal.
  - hsivonen 13y ago
    How is PNaCl not Chromium lock-in? Pepper is defined by the Chromium implementation.
    - 13y ago
andyjohnson0 13y ago
I'm very impressed by the Epic Citadel demo. But how do you debug a C/C++ program that has been converted to asm.js? Whats the current tooling like?
- flohofwoe 13y ago
  Usually I'm debugging a native "desktop build" of the code in VStudio or XCode since 99% of the bugs are not emscripten specific. But having said that: browsers are becoming a really good debugging platform as well. emscripten can emit source maps, which kinda lets you directly debug the C++ code in the browser (not as fluent as in a native debugger yet, since only code lines are mapped, not variables, but the potential is clear). Some WebGL related debugging tools are really good in the browser (e.g. Firefox' WebGL shader debugger or the WebGL inspector browser extension). Especially on OSX which doesn't have very good debugging tools for desktop GL the browser WebGL debugging tools are actually better then what's available as native tools (not as good as PIX or NVIDIA's NSight tool on Windows though).
  - andyjohnson0 13y ago
    Thanks! I was thinking specifically of bugs that occur in the browser target but not the native build. Given your experience that "99% of the bugs are not emscripten specific", I'm very impressed with how emscripten can retain the semantics of the native code across the conversion and optimisation process. Obviously thats what any compiler does, but in this case the target environment seems to me to be much more complex than a physical cpu: threads, memory management, etc.
    - masklinn 13y ago
      > in this case the target environment seems to me to be much more complex than a physical cpu: threads, memory management, etc. It compiles for a restricted subset of javascript. There are no threads (there are no threads in javascript itself in the first place), and it works around memory management (it sets up big typed arrays, and memory allocations are slices of that)
flohofwoe 13y ago
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.
- pwang 13y ago
  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.
  - flohofwoe 13y ago
    http://www.flohofwoe.net/demos.html http://www.flohofwoe.net/demos.html, these demos are about 150k to 250k lines of C++ code, and are about 700k to 1.5MB downloads, the same as zipped native executables. I'm also on the team which does a web-based MMO which is running for 3 years now (not done with emscripten though), so I'm aware of the problems :) It's still miles better then closed platforms.
  - 13y ago
theallan 13y ago
Is it possible to compile Blink and run it using asm.js in Firefox? Then you could run Firefox inside of the Blink renderer, also in asm.js, and ...
- sanxiyn 13y ago
  One problem is that you can't do runtime code generation with Emscripten. V8 has no interpreter, so you would need a different JavaScript engine. JavaScript engines can be run using asm.js. https://github.com/jterrace/js.js https://github.com/jterrace/js.js is a SpiderMonkey port to Emscripten (with JIT disabled).
  - kevingadd 13y ago
    You can absolutely do runtime code generation, you'll just be generating javascript. If you generate asm.js compatible javascript you'll be effectively JITting native code on the fly (you're just jumping through some absurd hoops to do it). There are some proof-of-concept projects out there that do runtime generation of JS on the fly for things like recompilation and such in the browser right now. I believe Shumway [1] does it (recompiling ActionScript VM bytecode to JS on the fly) and PyPy.js has an experimental JIT too [2]. The runtime library for my compiler JSIL also does a significant amount of runtime code generation to improve performance and reduce executable sizes [3]. [1] https://blog.mozilla.org/research/2012/11/12/introducing-the-shumway-open-swf-runtime-project/ https://blog.mozilla.org/research/2012/11/12/introducing-the... [2] http://www.rfk.id.au/blog/entry/pypy-js-poc-jit/ http://www.rfk.id.au/blog/entry/pypy-js-poc-jit/ [3] http://jsil.org/ http://jsil.org/ ; https://github.com/sq/JSIL/blob/master/Libraries/JSIL.Unsafe.js#L1254 https://github.com/sq/JSIL/blob/master/Libraries/JSIL.Unsafe... and others
pwang 13y ago
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.
- soapdog 13y ago
  pwang, there are some people who actually enjoy coding in JS, believe me I am one of them. One cool thing about JS is that you have runtimes for it in computers, tablets, phones, TVs and most current videogames so you can experiment and build stuff for a variety of hardware that no other language can reach as easily (of course you can reach anything with C but it is not easier). Remember all that could be done in JS two years ago and all we could do now. Imagine by the end of the next year what we'll be able to. I don't care if people are using LLVM to cross-compile other languages to the JS runtime, this kind of approach and research makes better runtimes and both camps benefit, the people who hate JS can use their fav language and those that enjoy JS end up with a better runtime.
  - m0a0t0 13y ago
    I (not pwang) think it's an abortion of a language because the syntax, scoping and the language as are a whole is a pain to use. Sure, it runs on pretty much everything but that doesn't mean it's suddenly enjoyable to use. The only outstanding feature of JS is that it runs on lots of stuff but it need not be the only one. As you say getting other languages to run is a good thing because those who don't like JS don't have to use it (or indirectly use it with stuff like Coffeescript).
    - wwweston 13y ago
fidotron 13y ago
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.
- leokun 13y ago
  > the web is rapidly gaining all the flaws that Flash used to have False. 1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. 2. It's nearly all open standards and open source, not proprietary closed source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium, blink, webkit. 3. It works on mobile devices, flash doesn't. 4. The tools are out there. Check out appcelerator or unity's tools. 5. Flash never had the native performance or hardware acceleration that modern JavaScript has. 6. Don't think Flash ever had the kind of momentum JavaScript has. Like has anyone ever made a derby.js for Flash? A sharejs? Compiled other languages to ActionScript? With source maps to help? 7. Flash avoids all kinds of privacy settings and plugins in your browser. Flash gives you less control. 8. Even Adobe has moved past Flash, these arguments are all done, why haven't you moved on?
  - sanxiyn 13y ago
    > Compiled other languages to ActionScript? For the interest of historical accuracy, I must point out that Adobe Alchemy predates Emscripten by years.
    - kevingadd 13y ago
      Alchemy didn't compile to ActionScript, it compiled to the underlying VM bytecode and it relied on special bytecodes added to the runtime specifically for Alchemy. A more direct comparison in this case is NaCL - Alchemy-compiled outputs would not work on an old ActionScript VM, while one of asm.js's benefits is that the generated code will work on any javascript runtime, because it's just JS.
gitaarik 13y ago
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)?
- flohofwoe 13y ago
  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.
  - dirkk0 13y ago
    But you could take Brython or Pythonium and make a Python2asmjs compiler (as I suggested in their forum: https://groups.google.com/forum/#!topic/brython/I7VoZNCiphI https://groups.google.com/forum/#!topic/brython/I7VoZNCiphI) This could be a chance to skip JS altogether.
    - acjohnson55 13y ago
      That's the great hope. Instead of bringing Javascript to the server side to have a single-language workflow, you'll be able to bring the non-JS language of your choice to the client side.
- logn 13y ago
  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.
ma2rten 13y ago
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.
- JoeAltmaier 13y ago
  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?
  - ma2rten 13y ago
    NaCl is just native machine code with some additional restrictions, AFAIK. It can make use of existing compilers and optimizers. I agree that the binary is probably relatively efficient, but a) only if your code deals with 32bit floating point numbers, b) the binary (erm js file) is probably going to be bigger (hence increased download times) c) the compilation does not come for free.
    - sanxiyn 13y ago
      For file size, see http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... Summary: it's comparable, not bigger.
- azakai 13y ago
  > 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: http://www.flohofwoe.net/demos.html http://www.flohofwoe.net/demos.html http://trypepperjs.appspot.com/examples.html http://trypepperjs.appspot.com/examples.html
endemic 13y ago
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.
- agentultra 13y ago
  That's a good thing. We spend too much time developing languages instead of environments. Unity is a good environment for developing games. If your goal is to make a game you should use Unity (or whatever... GameMaker has an HTML5 export module; use that). Javascript has nothing to offer you to enhance your productivity and develop your game.
- azakai 13y ago
  I disagree, I think the future will be all kinds of things, both on the web and elsewhere. On the web, it will be both handwritten JS as well as compiled JS from various languages like C/C++ (into asm.js), TypeScript, etc. Each of those is good for some use cases, but none is good enough for everything. Just like we have many languages for native development and web servers and so forth.
- CmonDev 13y ago
  Pick a language you like (on its merits), not the one that is ubiquitous.
captainmuon 13y ago
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.
- saosebastiao 13y ago
  I can fully recognize that Java is a fast and powerful language, but it also makes me want to shove huge wooden slivers up my fingernails. That doesn't change despite the truth of your statements.
  - calt 13y ago
    But what the poster is really thinking of is the JVM. We now have Scala, Clojure, and others that target the JVM as a platform.
    - Touche 13y ago
      The JVM doesn't run on Android or iOS, and never will. That's a huge chunk of users they can't touch, but the web can.
haberman 13y ago
On an unrelated note, I absolutely love that site's header animation (like what you see if you scroll up and/or click "play").
- ohazi 13y ago
  Is that why mobile Firefox kept crashing? Dammit, don't send that stuff to my phone if I didn't ask for it.
macspoofing 13y ago
>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.
ben0x539 13y ago
UTF-8 is a legacy mechanism now?
samsquire 13y ago
Could we combine ASM.js and "native web libraries?" (see https://github.com/samsquire/ideas#51-native-web-libraries https://github.com/samsquire/ideas#51-native-web-libraries) 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.
snrip 13y ago
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.
- ubernostrum 13y ago
  asm.js is not "a better JavaScript". It's not "JavaScript with better performance". In most senses that people would use, it's not even JavaScript, really. asm.js is not a faster jQuery. It's not for doing yellow-flash alerts, or for more quickly selecting and manipulating DOM elements. asm.js is a way to ship traditionally desktop-type software, including software which was originally written in a language like C or C++ and compiled into asm.js from that source, to a web browser, to be run in the web browser. asm.js is (a subset of) JavaScript's syntax, used as a transport/intermediate representation for that code. It will execute just fine as JavaScript, and well-optimized JavaScript engines can do quite well with it (hence it is fully backwards-compatible, if not as fast, in a browser which supports JavaScript but not asm.js), but the intent is primarily to treat it as an IR, with the browser performing the final step of compiling that IR to native code before executing it as native code, rather than executing it as JavaScript.
vanderZwan 13y ago
> "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.
- dgregd 13y ago
  > 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.
- jheriko 13y ago
  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.
charlieflowers 13y ago
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.
goggles99 13y ago
What would it take to get a standards board to approve a common VM for browsers? I don't see this ever happening. They would in effect be eliminating themselves. They would have to find new jobs or even careers. Once the VM is standardized, what about HTML/JS/CSS. Well who the hell wants to use those slow moving legacy technologies? So the standardization now becomes for python, for C#, for scala and lisp ETC.(and their associated UI frameworks). Not controlled by the W3C at all - thus their extinction. It's more than this though. The W3C has an agenda and it is not to advance technology, it is to slow it down. They want everything moving so slowly that standards can be followed across the board. They want JS/CSS/HTML to be the end all not just in the browser, but everywhere. I think that this should be pretty clear if you follow their trail going back 10-15 years. It is like a socialist government in a way. The promise is to keep everything stable and let everyone be on equal footing (equal here because the technology moves so slowly that nobody can be left behind by it.) They have to kill and silence many revolutionists who want freedom along the way to do so but consider themselves justified in doing so. Meanwhile, in a neighboring free government with limited govt, people flourish. They have more ups and downs true, and mistakes are made along the way, but after 10 years the free country is wealthy and flourishing, while the socialist one is stagnant and poor. Think of the mere opportunity of innovation that would exist if a language creator could sit down and create a new language and UI framework universally for browsers in a well established and supported way. This lack of freedom is stagnating innovation. Let the people decide. Make a standardized VM and your HTML/JS/CSS stack and let the people vote with their choice of options that appear.
- siddboots 13y ago
  You are overestimating the power that the standards board has over what browser vendors choose to include in their software. What you are asking of them is not really in their power. Besides, if VMs can make the W3C irrelevant, then they will do so regardless of W3C's approval of any particular standard. For what it's worth, we're already very close to the point where "a language creator can sit down and create a new language and UI framework universally for browsers".
  - goggles99 13y ago

240 points by scribu 13y ago

I don't see the problem with asm. It appears that Chrome and Opera support them too. It can only be a good thing. https://blog.mozilla.org/futurereleases/2013/11/26/chrome-and-opera-optimize-for-mozilla-pioneered-asm-js/ https://blog.mozilla.org/futurereleases/2013/11/26/chrome-an... It doesn't require requires a plugin install like NaCl

JetSpiegel 13y ago
The article links to that article, come on! Don't people read stuff anymore?
- waterflame 13y ago
  no.
- frik 13y ago
  The linked website has an horrible animated background picture. Reading the text is almost impossible with IE 11. Screenshot: http://postimg.org/image/46p2krx95/ http://postimg.org/image/46p2krx95/
  - omeid2 13y ago
    I hate to be that guy, but you're using IE. On a serious note, you can't really blame people for not supporting a browser that needs hack for every single version. Related: http://www.paulirish.com/2011/browser-market-pollution-iex-is-the-new-ie6/ http://www.paulirish.com/2011/browser-market-pollution-iex-i...
    - frik 13y ago
      Ask the JQuery devs, Chrome causes them more troubles than all other modern browsers combined (IE9+, FF, Safari, etc). I am well aware of the history and I hate IE < 10 too. I use FF as main development browser, and beside others of course Chrome and IE 11. The trouble comes when people only test their website with Chrome. I am using IE 11 as I have to at my workplace and it has by far the best UX (IMHO). FF still uses only one process and cannot handle my habit of using dozens or even hundreds of tabs in an optimal way.
    - ben0x539 13y ago
      Meh, delivering a bunch of text with some images and hyperlinks inbetween was pretty much a solved problem twenty years ago. It's nice that there's still progress being made towards doing more interesting things on the web, but if you have trouble pushing text and images to IE the problem might not lie with IE.
  - Jare 13y ago
    IE11 is a very promising alpha release of the next "good" IE.
coldtea 13y ago
>I don't see the problem with asm. That's because you didn't read the article. Which among other things, already points to that blog post.

franole 13y ago

Windowx XP give me the blue screen of death, with Firefox 25.0.1

melling 13y ago
XP is end of life in 5 months so I would expect a lot more problems in the not so near future. http://www.microsoft.com/en-us/windows/enterprise/endofsupport.aspx http://www.microsoft.com/en-us/windows/enterprise/endofsuppo...
- camus2 13y ago
  like gigantic botnets due to unpatched zero day exploits.
franole 13y ago
My first comment and I get down votes :( 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-windows-xp-after-microsoft-ends-support-for-the-os http://www.neowin.net/news/mozilla-to-support-firefox-on-win...
- binarycrusader 13y ago
  After Microsoft stops providing security updates, it will no longer effectively work. You really, really need to upgrade somehow. It really is necessary. If you can't upgrade Windows, you need to consider moving to a different operating system.

deleted 13y ago

[deleted]

Torn 13y ago

The citadel demo, if anyone's looking for it: http://www.unrealengine.com/html5/ http://www.unrealengine.com/html5/ 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?

girvo 13y ago
Honestly, I've got no idea what the OP was trying to say... I think they are implying that asm.js is cool, but they're annoyed that it's being built on top of JS rather than from-scratch.
- sp332 13y ago
  It's ignoring history. The author is saying that browser developers should get together and agree on something better than JavaScript. At first this seems quite possible, since browsers come out with new features all the time. But people have been trying to replace js for a long time and it has never ever worked.
- Ygg2 13y ago
  Second this. I get that they are saying - asm.js is cool, but it's on JS, so eugh. Personally I'd love for a really low level language (statically typed, little if any magic, no-GC, multi-threaded) to work across all browsers, but I don't think browser vendors can just sit and say - here is the perfect cross browser language that will make all of net easy. Perhaps the best strategy is to have low level strict language on top of which you build more easier to use constructs - which describes IMO both asm.js and PNaCl.
  - acqq 13y ago
    As the writer of the native compilers, I read the article as written from the kind of the developer who always developed in interpretative languages, who sees asm.js as "wrong" because "it's not the JavaScript he would write by hand. And again. as the writer of the native compilers, I'm absolutely pro asm.js. I believe it's the best direction that JavaScript optimization can take, solving more hard problems elegantly. Including the fact that asm.js is a better representation than most of bytecodes (or even all). Seriously.

felxh 13y ago

I definitely recommend poking around the console on this site!

safetydank 13y ago

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.

flohofwoe 13y ago
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.
- CmonDev 13y ago
  Good enough for C++, but with JVM/CLR languages running them right in the browser would be more ideal.
- hsivonen 13y ago
  How is PNaCl not Chromium lock-in? Pepper is defined by the Chromium implementation.
  - 13y ago

andyjohnson0 13y ago

I'm very impressed by the Epic Citadel demo. But how do you debug a C/C++ program that has been converted to asm.js? Whats the current tooling like?

flohofwoe 13y ago
Usually I'm debugging a native "desktop build" of the code in VStudio or XCode since 99% of the bugs are not emscripten specific. But having said that: browsers are becoming a really good debugging platform as well. emscripten can emit source maps, which kinda lets you directly debug the C++ code in the browser (not as fluent as in a native debugger yet, since only code lines are mapped, not variables, but the potential is clear). Some WebGL related debugging tools are really good in the browser (e.g. Firefox' WebGL shader debugger or the WebGL inspector browser extension). Especially on OSX which doesn't have very good debugging tools for desktop GL the browser WebGL debugging tools are actually better then what's available as native tools (not as good as PIX or NVIDIA's NSight tool on Windows though).
- andyjohnson0 13y ago
  Thanks! I was thinking specifically of bugs that occur in the browser target but not the native build. Given your experience that "99% of the bugs are not emscripten specific", I'm very impressed with how emscripten can retain the semantics of the native code across the conversion and optimisation process. Obviously thats what any compiler does, but in this case the target environment seems to me to be much more complex than a physical cpu: threads, memory management, etc.
  - masklinn 13y ago
    > in this case the target environment seems to me to be much more complex than a physical cpu: threads, memory management, etc. It compiles for a restricted subset of javascript. There are no threads (there are no threads in javascript itself in the first place), and it works around memory management (it sets up big typed arrays, and memory allocations are slices of that)

flohofwoe 13y ago

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.

pwang 13y ago
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.
- flohofwoe 13y ago
  http://www.flohofwoe.net/demos.html http://www.flohofwoe.net/demos.html, these demos are about 150k to 250k lines of C++ code, and are about 700k to 1.5MB downloads, the same as zipped native executables. I'm also on the team which does a web-based MMO which is running for 3 years now (not done with emscripten though), so I'm aware of the problems :) It's still miles better then closed platforms.
- 13y ago

theallan 13y ago

Is it possible to compile Blink and run it using asm.js in Firefox? Then you could run Firefox inside of the Blink renderer, also in asm.js, and ...

sanxiyn 13y ago
One problem is that you can't do runtime code generation with Emscripten. V8 has no interpreter, so you would need a different JavaScript engine. JavaScript engines can be run using asm.js. https://github.com/jterrace/js.js https://github.com/jterrace/js.js is a SpiderMonkey port to Emscripten (with JIT disabled).
- kevingadd 13y ago
  You can absolutely do runtime code generation, you'll just be generating javascript. If you generate asm.js compatible javascript you'll be effectively JITting native code on the fly (you're just jumping through some absurd hoops to do it). There are some proof-of-concept projects out there that do runtime generation of JS on the fly for things like recompilation and such in the browser right now. I believe Shumway [1] does it (recompiling ActionScript VM bytecode to JS on the fly) and PyPy.js has an experimental JIT too [2]. The runtime library for my compiler JSIL also does a significant amount of runtime code generation to improve performance and reduce executable sizes [3]. [1] https://blog.mozilla.org/research/2012/11/12/introducing-the-shumway-open-swf-runtime-project/ https://blog.mozilla.org/research/2012/11/12/introducing-the... [2] http://www.rfk.id.au/blog/entry/pypy-js-poc-jit/ http://www.rfk.id.au/blog/entry/pypy-js-poc-jit/ [3] http://jsil.org/ http://jsil.org/ ; https://github.com/sq/JSIL/blob/master/Libraries/JSIL.Unsafe.js#L1254 https://github.com/sq/JSIL/blob/master/Libraries/JSIL.Unsafe... and others

pwang 13y ago

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.

soapdog 13y ago
pwang, there are some people who actually enjoy coding in JS, believe me I am one of them. One cool thing about JS is that you have runtimes for it in computers, tablets, phones, TVs and most current videogames so you can experiment and build stuff for a variety of hardware that no other language can reach as easily (of course you can reach anything with C but it is not easier). Remember all that could be done in JS two years ago and all we could do now. Imagine by the end of the next year what we'll be able to. I don't care if people are using LLVM to cross-compile other languages to the JS runtime, this kind of approach and research makes better runtimes and both camps benefit, the people who hate JS can use their fav language and those that enjoy JS end up with a better runtime.
- m0a0t0 13y ago
  I (not pwang) think it's an abortion of a language because the syntax, scoping and the language as are a whole is a pain to use. Sure, it runs on pretty much everything but that doesn't mean it's suddenly enjoyable to use. The only outstanding feature of JS is that it runs on lots of stuff but it need not be the only one. As you say getting other languages to run is a good thing because those who don't like JS don't have to use it (or indirectly use it with stuff like Coffeescript).
  - wwweston 13y ago

fidotron 13y ago

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.

leokun 13y ago
> the web is rapidly gaining all the flaws that Flash used to have False. 1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. 2. It's nearly all open standards and open source, not proprietary closed source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium, blink, webkit. 3. It works on mobile devices, flash doesn't. 4. The tools are out there. Check out appcelerator or unity's tools. 5. Flash never had the native performance or hardware acceleration that modern JavaScript has. 6. Don't think Flash ever had the kind of momentum JavaScript has. Like has anyone ever made a derby.js for Flash? A sharejs? Compiled other languages to ActionScript? With source maps to help? 7. Flash avoids all kinds of privacy settings and plugins in your browser. Flash gives you less control. 8. Even Adobe has moved past Flash, these arguments are all done, why haven't you moved on?
- sanxiyn 13y ago
  > Compiled other languages to ActionScript? For the interest of historical accuracy, I must point out that Adobe Alchemy predates Emscripten by years.
  - kevingadd 13y ago
    Alchemy didn't compile to ActionScript, it compiled to the underlying VM bytecode and it relied on special bytecodes added to the runtime specifically for Alchemy. A more direct comparison in this case is NaCL - Alchemy-compiled outputs would not work on an old ActionScript VM, while one of asm.js's benefits is that the generated code will work on any javascript runtime, because it's just JS.

gitaarik 13y ago

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)?

flohofwoe 13y ago
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.
- dirkk0 13y ago
  But you could take Brython or Pythonium and make a Python2asmjs compiler (as I suggested in their forum: https://groups.google.com/forum/#!topic/brython/I7VoZNCiphI https://groups.google.com/forum/#!topic/brython/I7VoZNCiphI) This could be a chance to skip JS altogether.
  - acjohnson55 13y ago
    That's the great hope. Instead of bringing Javascript to the server side to have a single-language workflow, you'll be able to bring the non-JS language of your choice to the client side.
logn 13y ago
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.

ma2rten 13y ago

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.

JoeAltmaier 13y ago
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?
- ma2rten 13y ago
  NaCl is just native machine code with some additional restrictions, AFAIK. It can make use of existing compilers and optimizers. I agree that the binary is probably relatively efficient, but a) only if your code deals with 32bit floating point numbers, b) the binary (erm js file) is probably going to be bigger (hence increased download times) c) the compilation does not come for free.
  - sanxiyn 13y ago
    For file size, see http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... Summary: it's comparable, not bigger.
azakai 13y ago
> 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: http://www.flohofwoe.net/demos.html http://www.flohofwoe.net/demos.html http://trypepperjs.appspot.com/examples.html http://trypepperjs.appspot.com/examples.html

endemic 13y ago

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.

agentultra 13y ago
That's a good thing. We spend too much time developing languages instead of environments. Unity is a good environment for developing games. If your goal is to make a game you should use Unity (or whatever... GameMaker has an HTML5 export module; use that). Javascript has nothing to offer you to enhance your productivity and develop your game.
azakai 13y ago
I disagree, I think the future will be all kinds of things, both on the web and elsewhere. On the web, it will be both handwritten JS as well as compiled JS from various languages like C/C++ (into asm.js), TypeScript, etc. Each of those is good for some use cases, but none is good enough for everything. Just like we have many languages for native development and web servers and so forth.
CmonDev 13y ago
Pick a language you like (on its merits), not the one that is ubiquitous.

captainmuon 13y ago

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.

saosebastiao 13y ago
I can fully recognize that Java is a fast and powerful language, but it also makes me want to shove huge wooden slivers up my fingernails. That doesn't change despite the truth of your statements.
- calt 13y ago
  But what the poster is really thinking of is the JVM. We now have Scala, Clojure, and others that target the JVM as a platform.
  - Touche 13y ago
    The JVM doesn't run on Android or iOS, and never will. That's a huge chunk of users they can't touch, but the web can.

haberman 13y ago

On an unrelated note, I absolutely love that site's header animation (like what you see if you scroll up and/or click "play").

ohazi 13y ago
Is that why mobile Firefox kept crashing? Dammit, don't send that stuff to my phone if I didn't ask for it.

macspoofing 13y ago

>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.

ben0x539 13y ago

UTF-8 is a legacy mechanism now?

samsquire 13y ago

Could we combine ASM.js and "native web libraries?" (see https://github.com/samsquire/ideas#51-native-web-libraries https://github.com/samsquire/ideas#51-native-web-libraries) 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.

snrip 13y ago

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.

ubernostrum 13y ago
asm.js is not "a better JavaScript". It's not "JavaScript with better performance". In most senses that people would use, it's not even JavaScript, really. asm.js is not a faster jQuery. It's not for doing yellow-flash alerts, or for more quickly selecting and manipulating DOM elements. asm.js is a way to ship traditionally desktop-type software, including software which was originally written in a language like C or C++ and compiled into asm.js from that source, to a web browser, to be run in the web browser. asm.js is (a subset of) JavaScript's syntax, used as a transport/intermediate representation for that code. It will execute just fine as JavaScript, and well-optimized JavaScript engines can do quite well with it (hence it is fully backwards-compatible, if not as fast, in a browser which supports JavaScript but not asm.js), but the intent is primarily to treat it as an IR, with the browser performing the final step of compiling that IR to native code before executing it as native code, rather than executing it as JavaScript.

vanderZwan 13y ago

> "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.

dgregd 13y ago
> 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.
jheriko 13y ago
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.

charlieflowers 13y ago

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.

goggles99 13y ago

What would it take to get a standards board to approve a common VM for browsers? I don't see this ever happening. They would in effect be eliminating themselves. They would have to find new jobs or even careers. Once the VM is standardized, what about HTML/JS/CSS. Well who the hell wants to use those slow moving legacy technologies? So the standardization now becomes for python, for C#, for scala and lisp ETC.(and their associated UI frameworks). Not controlled by the W3C at all - thus their extinction. It's more than this though. The W3C has an agenda and it is not to advance technology, it is to slow it down. They want everything moving so slowly that standards can be followed across the board. They want JS/CSS/HTML to be the end all not just in the browser, but everywhere. I think that this should be pretty clear if you follow their trail going back 10-15 years. It is like a socialist government in a way. The promise is to keep everything stable and let everyone be on equal footing (equal here because the technology moves so slowly that nobody can be left behind by it.) They have to kill and silence many revolutionists who want freedom along the way to do so but consider themselves justified in doing so. Meanwhile, in a neighboring free government with limited govt, people flourish. They have more ups and downs true, and mistakes are made along the way, but after 10 years the free country is wealthy and flourishing, while the socialist one is stagnant and poor. Think of the mere opportunity of innovation that would exist if a language creator could sit down and create a new language and UI framework universally for browsers in a well established and supported way. This lack of freedom is stagnating innovation. Let the people decide. Make a standardized VM and your HTML/JS/CSS stack and let the people vote with their choice of options that appear.

siddboots 13y ago
You are overestimating the power that the standards board has over what browser vendors choose to include in their software. What you are asking of them is not really in their power. Besides, if VMs can make the W3C irrelevant, then they will do so regardless of W3C's approval of any particular standard. For what it's worth, we're already very close to the point where "a language creator can sit down and create a new language and UI framework universally for browsers".
- goggles99 13y ago