4 ms·
Prior to asm.js I spoke out against Mozilla's hard stance that making JS faster was the only option -as opposed to making a whole new VM or at least working to
by corysama 12y ago
Prior to asm.js I spoke out against Mozilla's hard stance that making JS faster was the only option -as opposed to making a whole new VM or at least working to make PNACL more portable.
But, this here is exactly why I changed my tune. The primary advantage of asm.js is not technical. It's political. It would work without requiring Apple or Microsoft to take any stance at all. The big, slow, stubborn players did not need to be convinced to make any investment of any form. And once it worked, it would not be embarrassing or risky for them to join the party late.
And, here is the evidence that asm.js is working where no other option would. I look forward to the day when we can move on from JS to a better-designed VM. But while I wait, I'll be satisfied for a while with asm.js (once the SIMD support goes mainline).
- runeks 12y ago> The primary advantage of asm.js is not technical. It's political. One could also argue that asm.js's advantage is technical, and it's called "backward compatibility" :).
- camgunz 12y agoI have doubts about asm.js. I'm not super informed so I might be wrong, feel free to correct me :) 1. I don't know how helpful open source is if that source is inscrutable. The JS generated by Emscripten isn't super useful. 2. The only reasonable way to use a non-JS language with asm.js is to use Emscripten to compile its runtime or compile a "native" binary. One of the arguments against PNaCl is that you basically need to use Google's implementation. While the tie-in with asm.js is for developers, whereas the tie-in with PNaCl is for users, I think it's tie-in nonetheless. 3. asm.js is billed as an 'open platform', but it's still limited to platforms that can run browsers with asm.js optimizations implemented. The number of these platforms, when you consider phones, consoles, appliances, and legacy platforms, is pretty small. They can also ill-afford a 50% speed decrease. Since this is basically Windows, Mac OS X, and Linux, your native applications are going to work just fine on those platforms. Sure you might have to do some platform abstracting, but not tons, and especially little if using something like Unity.
- tree_of_item 12y ago> 1. I don't know how helpful open source is if that source is inscrutable. The JS generated by Emscripten isn't super useful. People ship nonfree, minified JavaScript all the time, and "open source" doesn't mean "only distributed in the form preferred for modification". I don't see how this is unique to asm.js, or even that important: you can just put a link back to the "real" (e.g. C++) source in a comment on the page you serve.
- camgunz 12y agoI agree. I've seen asm.js proponents argue that, compared with PNaCl for example, asm.js isn't a binary blob. Maybe not technically, but I think it's hard enough to work with Emscripten-generated asm.js that it may as well be, and it's hard enough to write a large application in asm.js that you probably want to use C/C++ and transpile it to JS with Emscripten. That's the only point I was trying to make. I do think you've hit on something though: > People ship nonfree, minified JavaScript all the time I know, and I think it's dangerous for software freedom if the apps we start depending on are all closed-source web services, where we're at the mercy of the owners. Vendor lock-in is vendor lock-in, no matter the distribution channel, and zero-install isn't worth it.
- tree_of_item 12y agoI am getting the sense that you think asm.js has some troubling interaction with software freedom and I just don't agree with that at all. Whether or not the code you receive is free software is orthogonal to whether or not it's been run through a compiler. Emacs is free software and people typically download a binary to use it. Is that dangerous somehow? The source code is in a well known location. I agree that it is troubling that nonfree JavaScript is shipped all the time, but again, that happens every day without asm.js being involved, and asm.js does not help or hinder this.
- camgunz 12y agoI get what you're saying. My counter-argument is that because asm.js is being pushed as a distribution platform for "desktop" apps, and web services are so rarely open source, software freedom stands to take a hit. The main reason free software saw such adoption was that it was very high quality software available for free. Most people aren't even aware of the philosophy and history behind it, nor would they base their decision on what software to use on that philosophy and history. Web services aren't covered by free software licenses, but they generally have no cost, are sandboxed, and you don't have to install them (even though you're actually "installing" them a lot, just in the background). For almost all users, that's a huge win, but for free software, that's a huge loss. asm.js enabled many more classes of software to run in this environment, and I think that's a big looming negative for software freedom. I love Mozilla and I think what they do is amazing on almost every level. But the web is more than just a browser and JavaScript. There's 65k ports and dozens (hundreds?) of protocols. There's no need for the battle for the open web to take place only in the browser space.
- fryguy 12y agoI still feel like the better alternative to asm.js's approach is a VM with a static javascript interpreter/transpiler. It would have worked just as well politically, and been a much more direct benefit.
- frik 12y agoIt's great that MS works on asm.js support. Now that most syntax ideas from TypeScript have been added to ES6. It will come handy for Skype and Office web libraries. Suggestion: WebGL 2 and better WebGL support - Vote in the "IE Suggestion Box": https://wpdev.uservoice.com/forums/257854-internet-explorer-platform?query=WebGL https://wpdev.uservoice.com/forums/257854-internet-explorer-...
- gsnedders 12y ago> Now that most syntax ideas from TypeScript have been added to ES6. By 2012, most of what's in ES6 had rough consensus on; TypeScript was just implementing what was going to be in ES6, rather than ES6 taking it from TypeScript.