11 ms·

Bringing asm.js to the Chakra JavaScript engine in Windows 10

299 points by bpierre 12y ago

realityking 12y ago
Apparently Google's toying with the idea of using "use asm" as a signal to opt into TurboFan[1]. While not the AOT compilation envisioned by the asm.js creators, it speaks to the importance asm.js has already gained. That said, personally I'd rather see time spend optimising the new ES6 features so they can be used without a big performance hit. [1] https://code.google.com/p/v8/issues/detail?id=2599#c77 https://code.google.com/p/v8/issues/detail?id=2599#c77
- cpeterso 12y ago
  Mozilla tracks TurboFan performance on its "Are We Fast Yet?" benchmarks. TurboFan is clearly a work-in-progress because it is not scoring well on the common JS benchmarks: http://arewefastyet.com/ http://arewefastyet.com/
  - reissbaker 12y ago
    To be fair, the arewefastyet benchmarks are intentionally very broad, and stress test many different parts of a JS engine. It may be the case that TurboFan has a very fast sweet spot for numeric code (which would explain why they'd want to use it for asm.js), but is slower for the more general cases. I'd be interested to see how TurboFan performs on individual test cases; for example, Octane has several asm-specific tests, and based on their planning I wonder whether TurboFan is faster than Crankshaft for those individual tests even if it's slower for the rest of them.
    - bzbarsky 12y ago
      You can see breakdowns for various subtests on awfy. Of possible interest are http://arewefastyet.com/#machine=28&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=28&view=breakdown&suite=asm... and http://arewefastyet.com/#machine=28&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=28&view=breakdown&suite=asm... as well as http://arewefastyet.com/#machine=28&view=breakdown&suite=octane http://arewefastyet.com/#machine=28&view=breakdown&suite=oct...
      - reissbaker 12y ago
        Huh super interesting. It looks like currently TurboFan is competitive w/Crankshaft on the asm.js benchmarks, and much, much slower on everything else. I wonder if the V8 team expects TurboFan to someday beat Crankshaft on the asm benchmarks, given current perf differences.
gitaarik 12y ago
Nice, now that Firefox, Chrome and IE will support it, I think asm.js will become available in most serious browsers, which is a great thing. It will be interesting to see what kind of impact it will have. For example, will asm.js eventually take over traditional web development? Theoretically, you can compile any compiled language to asm.js, so you'll have a lot more choice for the language you want to use to create your webapps. It won't really be web though: no markup, no links, but yeah, with the current heavily based javascript apps that's also debatable. Also asm.js still has a lot of limitations and disadvantages that won't make it just as easy yet.
- jerf 12y ago
  "For example, will asm.js eventually take over traditional web development? Theoretically, you can compile any compiled language to asm.js, so you'll have a lot more choice for the language you want to use to create your webapps." I've outlined this progression before, which seems obvious to me, but I haven't seen anyone else discuss it. 1. Get asm.js into every browser. 2 or 3. Observe that asm.js is very verbose, define a simple binary bytecode for it. 3 or 2. Figure out how to get asm.js decent DOM access. The last two can come in either order. And the end result is the language-independent bytecode that so many people have asked for over the years. We just won't get there in one leap, it'll come in phases. We in fact won't be using Javascript for everything in 20 years [1], but those of you still around will be explaining to the young bucks why certain stupid quirks of their web browser's bytecode execution environment can be traced back to "Javascript", even when they're not using the increasingly-deprecated Javascript programming language. [1]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - woah 12y ago
    JS seems to actually be picking up a lot of speed outside the browser?
    - jerf 12y ago
      First, that's not particularly relevant to the question of what happens to the browser itself. Second, the field of "things you can run that is not Javascript" when not in the browser is already incredibly rich, so we already live in a flexible world. Third, frankly I'm not particularly overwhelmed by the prospect of Javascript's longevity in the server space being a long-term phenomenon... an awful lot of what gets linked on HN is less "cool things to do with JS" and "how to deal with the problems that come up when trying to use JS on the server". And fourthly, and why this reply is worth making, bear in mind that if the browser becomes feasibly able to run any language, rather than having Javascript occupy a privileged position by virtue of being the only language, the biggest putative advantage that Javascript-on-the-server has goes poof in a puff of smoke. If Javascript has to compete on equal footing, it really doesn't have a heck of a lot to offer; every other 1990s-style dynamically typed scripting language (Perl, Python, Ruby, etc) is far more polished by virtue of being able to be moved forward without getting two or three actively fractious browser vendors to agree on whatever the change is (just look at how slow the ES6 has been to roll out, when I'd rate to contain roughly as much change as your choice of any two 2.x Python releases). And it has no answer to the ever-growing crop of next-gen languages like Clojure or Rust. Without its impregnable foothold in the browser, Javascript's future is pretty dim. (In fact I consider the entire language catagory of "1990s-style dynamic scripting language" to be cresting right about now in general, so Javascript's going to be fighting for a slowly-but-surely ever-shrinking portion of pie.)
deleted 12y ago
[deleted]
MisterWebz 12y ago
Does this mean we'll soon have mobile web apps that rival native apps in terms of performance or will DOM manipulation still slow everything down?
- realityking 12y ago
  The latter. asm.js is interesting if a part of your app is computationally intensive. For example, if you want to create ZIP files in the browser asm.js is awesome.
- aikah 12y ago
  > Does this mean we'll soon have mobile web apps that rival native apps in terms of performance or will DOM manipulation still slow everything down? asm.js has nothing to do with the DOM.So if the browser engine is slow, a fast javascript engine won't make any difference. It only make a difference with pure javascript computation as asmjs basically recreate an "assembly" on top of javascript, which allows to execute compiled C/C++ code.
- untog 12y ago
  JS is already plenty fast, it's just the DOM manipulation that screws it up. But asm.js with direct access to a <canvas> tag, WebGL or not, would probably be interesting.
  - natmaster 12y ago
    Which is why ReactJS native is so compelling.
    - untog 12y ago
      And React Canvas: https://github.com/Flipboard/react-canvas https://github.com/Flipboard/react-canvas
h43k3r 12y ago
I don't know why but I am starting to like Microsoft. Things seems to have changed quite a lot in the past 6-12 months. .Net going open source ,new web browser spartan, CM acquisition are some of the things.
- vezzy-fnord 12y ago
  Microsoft are reportedly investing in Cyanogen, Inc. They have not acquired them to the best of my knowledge. Is there a source that confirms it?
  - higherpurpose 12y ago
    Cyanogen, the commercial version of the OS is not open source, like at all I think. And I bet that if Cyanogen becomes much more successful, within 5 years they'll completely give up on officially supporting the open source version for other phones, too. They'll just see it as an extra cost that gives them little benefit (in comparison to their success then) and as harming of their "exclusivity" for certain phones. So they'll kill it. Cyanogen seems like a very self-interested company to me, and is willing to backstab anyone as long as it puts them at a higher level in the market.
- aikah 12y ago
  Never forget that the core product of Microsoft is Windows, and most of people are forced paying a new license with each new computer. So any decision MS makes is,as an ultimate goal to sell windows licenses. Today there is a consensus on Open Web Techs. Nobody can tell if it will still be the case 5 years from now.
  - Richicoder 12y ago
    I think this is far less true. Many of Microsoft's recent decisions arguably have no net benifit to Windows, and in some cases could be seen as counter productive. The lockin is no longer for Windows, but Azure and Microsoft's tools.
  - outside2344 12y ago
ethana 12y ago
Who's putting their bets on Microsoft going open source with Trident and Chakra next? Spartan is an opportunity for them to clean up the mess before releasing the codes I think.
- quonn 12y ago
  At least for Chakra, this would make a lot of sense - I can't think of a downside for them. For Trident there is the theoretical downside that IE becomes fully independent of Windows. This currently doesn't matter, but might decrease lock-in in the future.
  - higherpurpose 12y ago
    Windows dependency of IE is one of the worst things about IE - like having to restart your PC to update your browser. What year is this again?
    - integraton 12y ago
      The fact that it was stagnant, ubiquitous, limited to Windows, and encouraged ActiveX were the major issues, since it made it more difficult and expensive to develop and transition to web applications for about a decade.
    - wmf 12y ago
      Windows will automatically reboot every 6 weeks anyway once evergreen Windows 365 comes out.
  - MLR 12y ago
    I've been thinking that Spartan will probably go cross platform at some point, an opportunity for them to get a few more Microsoft accounts created and it's not like it being Windows only is going to convince people to switch.
- ndesaulniers 12y ago
  I like IE's dev tools, but my main platform is OSX. Their memory profiler stuff is pretty sweet. If the community could help them maintain builds for other platforms, I would rock that.
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 ago
  I 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
nwienert 12y ago
Would be cool to see TypeScript compile to asm.js, would open up some cool optimizations for hybrid development. Seems like there was some discussion[1]. [1] http://typescript.codeplex.com/discussions/438243 http://typescript.codeplex.com/discussions/438243
- ndesaulniers 12y ago
  I've been playing around with compiling small subsets of JS to C++, then running it back through emscripten. It works, but you have to keep the subset small, otherwise you end up implementing a meta circular interpreter. The problem will be that the subset is never the subset that pleases everyone. When your implementation doesn't support one person's code, it's labeled 'crap', and the negative cheerleading begins.
munificent 12y ago
I feel like I must be missing something but I fundamentally don't get why people are so excited about asm.js. Does the web really need more people manually managing their memory? Do they not get that that's what asm.js is? It has no GC.
- maga 12y ago
  It opens a way to the Web Platform for the developers programming in compiled languages. For example, those developing casual games in Unity or Unreal Engine, can simply compile their games for the Web with as little effort and penalty in performance as possible.
- tree_of_item 12y ago
  I mean, you must know that applications with particularly high performance requirements can't afford a GC. asm.js is really about trying to turn the "web" in to a true runtime for applications and a direct competitor to "closed" ecosystems like iOS.
- spyder 12y ago
  Yes.
itsbits 12y ago
Would be cool to see TypeScript compile to asm.js, would open up some cool optimizations for hybrid development. Seems like there was some discussion[1]. [1] http://typescript.codeplex.com/discussions/438243 http://typescript.codeplex.com/discussions/438243
elcct 12y ago
I think since IE6 Microsoft should be banned from touching anything related to the internet.
riquito 12y ago
Other languages compilers/interpreters may be compiled in asm.js and let us program in something different than Javascript (e.g. https://github.com/replit/empythoned https://github.com/replit/empythoned ). Is this realistic?
josteink 12y ago
Nice to see Mozilla provide some good, portable standards, as opposed to Google with their own "native client" ActiveX-like nonsense. I honestly just see Google retiring NPAPI-plugins as a way to push their own non-standard, at the cost of all other browsers. I'm glad to to see that's not winning them any wars.
- camgunz 12y ago
  All of Google's development of NaCl and PNaCl is open source. The only thing stopping other browser vendors from working on it is themselves. It's also worth pointing out (being maybe just a bit too pedantic) that asm.js isn't a standard. It's a subset of ECMAScript, which is a standard, and Mozilla has published a spec for it. The spec is more how to use asm.js, not how to implement asm.js optimizations. I'm not saying this is bad, but if you're arguing that Google's stance is, "hey here's the code for PNaCl and how to use it, good luck!", you can't argue that Mozilla's stance is any different.
  - josteink 12y ago
    While what you're saying can't be said to be "incorrect", it isn't the full story either. What Google did was in-house, behind closed doors, develop a solution, embed it in Chrome, push it out in production, and start using it according to their own specs right away. Then they told other browser makers "Hey. Here's a neat ActiveX-like idea, which kinda makes the web platform-specific again, which you will have no say in how is implemented, because it's already in production, and unless you implement it as we see fit (and will continue to in the future), exactly as fits our browser-model and code (although it may not fit yours). Take it as is or we will be discriminating your browser on our web-services". And so they did. It may not be proprietary by definition, but it's not "open" by a mile either. Counter that with what Mozilla did: They proposed a way to make highly optimizable code-sections even faster, machine-code fast, in a backwards-compatible, web-friendly and portable way and invited people to join in. Those who didn't, would not suffer a lock-out, but those who joined could benefit from the work already done. I don't think there's any point even pretending that these two actors are playing on the same moral level here. Google is acting scumbaggy and everyone but apologists knows it.
perdunov 12y ago
asm.js + WebGL allow to completely skip the web stack making the browser just another platform of execution. Strangely or not, C/C++ strike back.

299 points by bpierre 12y ago

Apparently Google's toying with the idea of using "use asm" as a signal to opt into TurboFan[1]. While not the AOT compilation envisioned by the asm.js creators, it speaks to the importance asm.js has already gained. That said, personally I'd rather see time spend optimising the new ES6 features so they can be used without a big performance hit. [1] https://code.google.com/p/v8/issues/detail?id=2599#c77 https://code.google.com/p/v8/issues/detail?id=2599#c77

cpeterso 12y ago
Mozilla tracks TurboFan performance on its "Are We Fast Yet?" benchmarks. TurboFan is clearly a work-in-progress because it is not scoring well on the common JS benchmarks: http://arewefastyet.com/ http://arewefastyet.com/
- reissbaker 12y ago
  To be fair, the arewefastyet benchmarks are intentionally very broad, and stress test many different parts of a JS engine. It may be the case that TurboFan has a very fast sweet spot for numeric code (which would explain why they'd want to use it for asm.js), but is slower for the more general cases. I'd be interested to see how TurboFan performs on individual test cases; for example, Octane has several asm-specific tests, and based on their planning I wonder whether TurboFan is faster than Crankshaft for those individual tests even if it's slower for the rest of them.
  - bzbarsky 12y ago
    You can see breakdowns for various subtests on awfy. Of possible interest are http://arewefastyet.com/#machine=28&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=28&view=breakdown&suite=asm... and http://arewefastyet.com/#machine=28&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=28&view=breakdown&suite=asm... as well as http://arewefastyet.com/#machine=28&view=breakdown&suite=octane http://arewefastyet.com/#machine=28&view=breakdown&suite=oct...
    - reissbaker 12y ago
      Huh super interesting. It looks like currently TurboFan is competitive w/Crankshaft on the asm.js benchmarks, and much, much slower on everything else. I wonder if the V8 team expects TurboFan to someday beat Crankshaft on the asm benchmarks, given current perf differences.

gitaarik 12y ago

Nice, now that Firefox, Chrome and IE will support it, I think asm.js will become available in most serious browsers, which is a great thing. It will be interesting to see what kind of impact it will have. For example, will asm.js eventually take over traditional web development? Theoretically, you can compile any compiled language to asm.js, so you'll have a lot more choice for the language you want to use to create your webapps. It won't really be web though: no markup, no links, but yeah, with the current heavily based javascript apps that's also debatable. Also asm.js still has a lot of limitations and disadvantages that won't make it just as easy yet.

jerf 12y ago
"For example, will asm.js eventually take over traditional web development? Theoretically, you can compile any compiled language to asm.js, so you'll have a lot more choice for the language you want to use to create your webapps." I've outlined this progression before, which seems obvious to me, but I haven't seen anyone else discuss it. 1. Get asm.js into every browser. 2 or 3. Observe that asm.js is very verbose, define a simple binary bytecode for it. 3 or 2. Figure out how to get asm.js decent DOM access. The last two can come in either order. And the end result is the language-independent bytecode that so many people have asked for over the years. We just won't get there in one leap, it'll come in phases. We in fact won't be using Javascript for everything in 20 years [1], but those of you still around will be explaining to the young bucks why certain stupid quirks of their web browser's bytecode execution environment can be traced back to "Javascript", even when they're not using the increasingly-deprecated Javascript programming language. [1]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- woah 12y ago
  JS seems to actually be picking up a lot of speed outside the browser?
  - jerf 12y ago
    First, that's not particularly relevant to the question of what happens to the browser itself. Second, the field of "things you can run that is not Javascript" when not in the browser is already incredibly rich, so we already live in a flexible world. Third, frankly I'm not particularly overwhelmed by the prospect of Javascript's longevity in the server space being a long-term phenomenon... an awful lot of what gets linked on HN is less "cool things to do with JS" and "how to deal with the problems that come up when trying to use JS on the server". And fourthly, and why this reply is worth making, bear in mind that if the browser becomes feasibly able to run any language, rather than having Javascript occupy a privileged position by virtue of being the only language, the biggest putative advantage that Javascript-on-the-server has goes poof in a puff of smoke. If Javascript has to compete on equal footing, it really doesn't have a heck of a lot to offer; every other 1990s-style dynamically typed scripting language (Perl, Python, Ruby, etc) is far more polished by virtue of being able to be moved forward without getting two or three actively fractious browser vendors to agree on whatever the change is (just look at how slow the ES6 has been to roll out, when I'd rate to contain roughly as much change as your choice of any two 2.x Python releases). And it has no answer to the ever-growing crop of next-gen languages like Clojure or Rust. Without its impregnable foothold in the browser, Javascript's future is pretty dim. (In fact I consider the entire language catagory of "1990s-style dynamic scripting language" to be cresting right about now in general, so Javascript's going to be fighting for a slowly-but-surely ever-shrinking portion of pie.)

deleted 12y ago

[deleted]

MisterWebz 12y ago

Does this mean we'll soon have mobile web apps that rival native apps in terms of performance or will DOM manipulation still slow everything down?

realityking 12y ago
The latter. asm.js is interesting if a part of your app is computationally intensive. For example, if you want to create ZIP files in the browser asm.js is awesome.
aikah 12y ago
> Does this mean we'll soon have mobile web apps that rival native apps in terms of performance or will DOM manipulation still slow everything down? asm.js has nothing to do with the DOM.So if the browser engine is slow, a fast javascript engine won't make any difference. It only make a difference with pure javascript computation as asmjs basically recreate an "assembly" on top of javascript, which allows to execute compiled C/C++ code.
untog 12y ago
JS is already plenty fast, it's just the DOM manipulation that screws it up. But asm.js with direct access to a <canvas> tag, WebGL or not, would probably be interesting.
- natmaster 12y ago
  Which is why ReactJS native is so compelling.
  - untog 12y ago
    And React Canvas: https://github.com/Flipboard/react-canvas https://github.com/Flipboard/react-canvas

h43k3r 12y ago

I don't know why but I am starting to like Microsoft. Things seems to have changed quite a lot in the past 6-12 months. .Net going open source ,new web browser spartan, CM acquisition are some of the things.

vezzy-fnord 12y ago
Microsoft are reportedly investing in Cyanogen, Inc. They have not acquired them to the best of my knowledge. Is there a source that confirms it?
- higherpurpose 12y ago
  Cyanogen, the commercial version of the OS is not open source, like at all I think. And I bet that if Cyanogen becomes much more successful, within 5 years they'll completely give up on officially supporting the open source version for other phones, too. They'll just see it as an extra cost that gives them little benefit (in comparison to their success then) and as harming of their "exclusivity" for certain phones. So they'll kill it. Cyanogen seems like a very self-interested company to me, and is willing to backstab anyone as long as it puts them at a higher level in the market.
aikah 12y ago
Never forget that the core product of Microsoft is Windows, and most of people are forced paying a new license with each new computer. So any decision MS makes is,as an ultimate goal to sell windows licenses. Today there is a consensus on Open Web Techs. Nobody can tell if it will still be the case 5 years from now.
- Richicoder 12y ago
  I think this is far less true. Many of Microsoft's recent decisions arguably have no net benifit to Windows, and in some cases could be seen as counter productive. The lockin is no longer for Windows, but Azure and Microsoft's tools.
- outside2344 12y ago

ethana 12y ago

Who's putting their bets on Microsoft going open source with Trident and Chakra next? Spartan is an opportunity for them to clean up the mess before releasing the codes I think.

quonn 12y ago
At least for Chakra, this would make a lot of sense - I can't think of a downside for them. For Trident there is the theoretical downside that IE becomes fully independent of Windows. This currently doesn't matter, but might decrease lock-in in the future.
- higherpurpose 12y ago
  Windows dependency of IE is one of the worst things about IE - like having to restart your PC to update your browser. What year is this again?
  - integraton 12y ago
    The fact that it was stagnant, ubiquitous, limited to Windows, and encouraged ActiveX were the major issues, since it made it more difficult and expensive to develop and transition to web applications for about a decade.
  - wmf 12y ago
    Windows will automatically reboot every 6 weeks anyway once evergreen Windows 365 comes out.
- MLR 12y ago
  I've been thinking that Spartan will probably go cross platform at some point, an opportunity for them to get a few more Microsoft accounts created and it's not like it being Windows only is going to convince people to switch.
ndesaulniers 12y ago
I like IE's dev tools, but my main platform is OSX. Their memory profiler stuff is pretty sweet. If the community could help them maintain builds for other platforms, I would rock that.

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 ago
I 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

nwienert 12y ago

Would be cool to see TypeScript compile to asm.js, would open up some cool optimizations for hybrid development. Seems like there was some discussion[1]. [1] http://typescript.codeplex.com/discussions/438243 http://typescript.codeplex.com/discussions/438243

ndesaulniers 12y ago
I've been playing around with compiling small subsets of JS to C++, then running it back through emscripten. It works, but you have to keep the subset small, otherwise you end up implementing a meta circular interpreter. The problem will be that the subset is never the subset that pleases everyone. When your implementation doesn't support one person's code, it's labeled 'crap', and the negative cheerleading begins.

munificent 12y ago

I feel like I must be missing something but I fundamentally don't get why people are so excited about asm.js. Does the web really need more people manually managing their memory? Do they not get that that's what asm.js is? It has no GC.

maga 12y ago
It opens a way to the Web Platform for the developers programming in compiled languages. For example, those developing casual games in Unity or Unreal Engine, can simply compile their games for the Web with as little effort and penalty in performance as possible.
tree_of_item 12y ago
I mean, you must know that applications with particularly high performance requirements can't afford a GC. asm.js is really about trying to turn the "web" in to a true runtime for applications and a direct competitor to "closed" ecosystems like iOS.
spyder 12y ago
Yes.

itsbits 12y ago

elcct 12y ago

I think since IE6 Microsoft should be banned from touching anything related to the internet.

riquito 12y ago

Other languages compilers/interpreters may be compiled in asm.js and let us program in something different than Javascript (e.g. https://github.com/replit/empythoned https://github.com/replit/empythoned ). Is this realistic?

josteink 12y ago

Nice to see Mozilla provide some good, portable standards, as opposed to Google with their own "native client" ActiveX-like nonsense. I honestly just see Google retiring NPAPI-plugins as a way to push their own non-standard, at the cost of all other browsers. I'm glad to to see that's not winning them any wars.

camgunz 12y ago
All of Google's development of NaCl and PNaCl is open source. The only thing stopping other browser vendors from working on it is themselves. It's also worth pointing out (being maybe just a bit too pedantic) that asm.js isn't a standard. It's a subset of ECMAScript, which is a standard, and Mozilla has published a spec for it. The spec is more how to use asm.js, not how to implement asm.js optimizations. I'm not saying this is bad, but if you're arguing that Google's stance is, "hey here's the code for PNaCl and how to use it, good luck!", you can't argue that Mozilla's stance is any different.
- josteink 12y ago
  While what you're saying can't be said to be "incorrect", it isn't the full story either. What Google did was in-house, behind closed doors, develop a solution, embed it in Chrome, push it out in production, and start using it according to their own specs right away. Then they told other browser makers "Hey. Here's a neat ActiveX-like idea, which kinda makes the web platform-specific again, which you will have no say in how is implemented, because it's already in production, and unless you implement it as we see fit (and will continue to in the future), exactly as fits our browser-model and code (although it may not fit yours). Take it as is or we will be discriminating your browser on our web-services". And so they did. It may not be proprietary by definition, but it's not "open" by a mile either. Counter that with what Mozilla did: They proposed a way to make highly optimizable code-sections even faster, machine-code fast, in a backwards-compatible, web-friendly and portable way and invited people to join in. Those who didn't, would not suffer a lock-out, but those who joined could benefit from the work already done. I don't think there's any point even pretending that these two actors are playing on the same moral level here. Google is acting scumbaggy and everyone but apologists knows it.

perdunov 12y ago

asm.js + WebGL allow to completely skip the web stack making the browser just another platform of execution. Strangely or not, C/C++ strike back.