7 ms·

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 intere

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.)
    - reissbaker 12y ago
      Depends on how JS evolves. It got a pretty serious setback when ES4 blew up and everyone went back to the drawing board on ES5 and ES6; the ES6 launch makes it (I think) better for most use cases than Python/Ruby/et al, because the VM is an order-of-magnitude faster than most of the popular choices and ES6 is a reasonably usable language even for someone unused to Javascript's current quirks: it has a real module system, the class syntax is sane and similar to how every other lang does it, the confusing `this` binding is fixed with arrow-functions, generators and Promises get rid of deeply-nested callback chains, `let` and `const` get rid of confusing variable hoisting, etc. Google and Microsoft are both very seriously experimenting with typed variants of JS (TypeScript from Microsoft and SoundScript from the V8 team), and Mozilla had in fact already proposed adding static typing back in the ES4 days, so I wouldn't be surprised if the next couple of versions of the ES spec include static types. The future for JS is brighter than you think — although it's brighter only because it looks like JS will become a better language, not because of JS in its current, mostly-still-ES5 state.
- deleted 12y ago
  [deleted]
- adamnemecek 12y ago
  I think that eventually we might ditch DOM and use WebGL or canvas or something instead of it, like on the desktop.
  - RussianCow 12y ago
    You use WebGL to create standard GUI applications on the desktop? WebGL and canvas are in no way replacements for the DOM.
    - coldtea 12y ago
      >You use WebGL to create standard GUI applications on the desktop? Increasinly high end apps do.
      - RussianCow 12y ago
        Graphically intensive apps do it for performance. But the tradeoff is you lose all the native UI controls that the OS gives you--form fields, text selection, animation, etc. So I don't think replacing the DOM with OpenGL or similar is a good solution for general-purpose apps.
        adamnemecek 12y ago
        All of those would be implemented in a framework.
        bzbarsky 12y ago
        Yes, they already are. That framework is called the DOM. People keep complaining about it and trying to come up with replacement frameworks that end up slower and less capable... The DOM definitely has its problems, mind you. Investing some time in designing a proper replacement for it is worth it, as long as people understand going in that the project might well fail.
        12y ago
- Fiahil 12y ago
  I share your vision. However, I think getting asm.js a good DOM access definitively coming on 2), because it's an easy way to get visual feedback from anything running in a browser. Oh, and thanks for the very enjoyable link :)
- ndesaulniers 12y ago
  Hey, you're good at this. ;) It's funny to see that people so opposed to JS are too short sighted to see that asm.js could enable what they've wanted all along. Look at that!
  - cpeterso 12y ago
    asm.js is a cross-platform bytecode; it just happens to be ASCII and look like JS. :) Arguments against asm.js as a bytecode are mostly about aesthetics and "elegance". http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
- seanmcdirmid 12y ago
  Shared memory multi threading will still be a big barrier to porting over many native applications, like games. Unless asm.js fixes that?
  - AgentME 12y ago
    There are plans for that: https://bugzilla.mozilla.org/show_bug.cgi?id=933001 https://bugzilla.mozilla.org/show_bug.cgi?id=933001
    - seanmcdirmid 12y ago
      Nice! I'll finally be able to implement Glitch for the web (glitch is like react but uses replay to shake out data races).
- beagle3 12y ago
  > Observe that asm.js is very verbose, define a simple binary bytecode for it. I suspect that is never going to happen, for two reasons: 1) verbosity, on its own, does not make a difference on the web - HTML and Javascript are both generally super verbose, and haven't had any accepted "simple binary encoding" designed for them in those 20 years. What does get implemented is minifiers and compressors (gzip encoding or otherwise), both of which will provide benefits to asm.js comparable to what a bytecode would, and would not require any buy-in from browser maker (the same attribute that has made asm.js successful and PNaCL unsuccessful so far). 2) Historically, anything that is not backwards compatible and does not degrade gracefully is NOT easily adopted by Browser makers, or by websites, unless it provides something that cannot be achieved without it (e.g. WebGL gets some adoption because there is no alternative; but ES6 will get little to non in the next 3 years except as a source language translated to ES5)
  - comex 12y ago
    Well, if such a bytecode were being standardized, someone would surely write a shim JS library to convert it to JavaScript on browsers that didn't have native support yet. And I think the idea of making a binary format would be more popular for a sublanguage which is essentially guaranteed to be machine-generated and inscrutable, especially given that I've seen a lot of commenters here and elsewhere have a knee-jerk reaction against the idea of using JavaScript syntax, than for HTML/CSS/JavaScript, which have a long history of being written and read manually without any (de)compilation steps, even if most big webapps are minified.
    - beagle3 12y ago
      But it works the other way around: it will not be standardized before there's an implementation. If it ever happens (which I think is unlikely), the standardization will follow the shim. And the knee jerk reactions are meaningless. The people who ship stuff don't seem to mind, and they are the ones who make things matter.
bad_user 12y ago
> 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. Asm.js is meant for low level code, i.e. the kind of code that doesn't do garbage collection. High-level languages are better off compiling straight into Javascript. Solid examples that I know about: - http://www.scala-js.org/ http://www.scala-js.org/ (we are actually using this one) - https://github.com/clojure/clojurescript https://github.com/clojure/clojurescript - http://funscript.info/ http://funscript.info/ And there are other implementations as well.

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.)
  - reissbaker 12y ago
    Depends on how JS evolves. It got a pretty serious setback when ES4 blew up and everyone went back to the drawing board on ES5 and ES6; the ES6 launch makes it (I think) better for most use cases than Python/Ruby/et al, because the VM is an order-of-magnitude faster than most of the popular choices and ES6 is a reasonably usable language even for someone unused to Javascript's current quirks: it has a real module system, the class syntax is sane and similar to how every other lang does it, the confusing `this` binding is fixed with arrow-functions, generators and Promises get rid of deeply-nested callback chains, `let` and `const` get rid of confusing variable hoisting, etc. Google and Microsoft are both very seriously experimenting with typed variants of JS (TypeScript from Microsoft and SoundScript from the V8 team), and Mozilla had in fact already proposed adding static typing back in the ES4 days, so I wouldn't be surprised if the next couple of versions of the ES spec include static types. The future for JS is brighter than you think — although it's brighter only because it looks like JS will become a better language, not because of JS in its current, mostly-still-ES5 state.
deleted 12y ago
[deleted]
adamnemecek 12y ago
I think that eventually we might ditch DOM and use WebGL or canvas or something instead of it, like on the desktop.
- RussianCow 12y ago
  You use WebGL to create standard GUI applications on the desktop? WebGL and canvas are in no way replacements for the DOM.
  - coldtea 12y ago
    >You use WebGL to create standard GUI applications on the desktop? Increasinly high end apps do.
    - RussianCow 12y ago
      Graphically intensive apps do it for performance. But the tradeoff is you lose all the native UI controls that the OS gives you--form fields, text selection, animation, etc. So I don't think replacing the DOM with OpenGL or similar is a good solution for general-purpose apps.
      - adamnemecek 12y ago
        All of those would be implemented in a framework.
        bzbarsky 12y ago
        Yes, they already are. That framework is called the DOM. People keep complaining about it and trying to come up with replacement frameworks that end up slower and less capable... The DOM definitely has its problems, mind you. Investing some time in designing a proper replacement for it is worth it, as long as people understand going in that the project might well fail.
        12y ago
Fiahil 12y ago
I share your vision. However, I think getting asm.js a good DOM access definitively coming on 2), because it's an easy way to get visual feedback from anything running in a browser. Oh, and thanks for the very enjoyable link :)
ndesaulniers 12y ago
Hey, you're good at this. ;) It's funny to see that people so opposed to JS are too short sighted to see that asm.js could enable what they've wanted all along. Look at that!
- cpeterso 12y ago
  asm.js is a cross-platform bytecode; it just happens to be ASCII and look like JS. :) Arguments against asm.js as a bytecode are mostly about aesthetics and "elegance". http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
seanmcdirmid 12y ago
Shared memory multi threading will still be a big barrier to porting over many native applications, like games. Unless asm.js fixes that?
- AgentME 12y ago
  There are plans for that: https://bugzilla.mozilla.org/show_bug.cgi?id=933001 https://bugzilla.mozilla.org/show_bug.cgi?id=933001
  - seanmcdirmid 12y ago
    Nice! I'll finally be able to implement Glitch for the web (glitch is like react but uses replay to shake out data races).
beagle3 12y ago
> Observe that asm.js is very verbose, define a simple binary bytecode for it. I suspect that is never going to happen, for two reasons: 1) verbosity, on its own, does not make a difference on the web - HTML and Javascript are both generally super verbose, and haven't had any accepted "simple binary encoding" designed for them in those 20 years. What does get implemented is minifiers and compressors (gzip encoding or otherwise), both of which will provide benefits to asm.js comparable to what a bytecode would, and would not require any buy-in from browser maker (the same attribute that has made asm.js successful and PNaCL unsuccessful so far). 2) Historically, anything that is not backwards compatible and does not degrade gracefully is NOT easily adopted by Browser makers, or by websites, unless it provides something that cannot be achieved without it (e.g. WebGL gets some adoption because there is no alternative; but ES6 will get little to non in the next 3 years except as a source language translated to ES5)
- comex 12y ago
  Well, if such a bytecode were being standardized, someone would surely write a shim JS library to convert it to JavaScript on browsers that didn't have native support yet. And I think the idea of making a binary format would be more popular for a sublanguage which is essentially guaranteed to be machine-generated and inscrutable, especially given that I've seen a lot of commenters here and elsewhere have a knee-jerk reaction against the idea of using JavaScript syntax, than for HTML/CSS/JavaScript, which have a long history of being written and read manually without any (de)compilation steps, even if most big webapps are minified.
  - beagle3 12y ago
    But it works the other way around: it will not be standardized before there's an implementation. If it ever happens (which I think is unlikely), the standardization will follow the shim. And the knee jerk reactions are meaningless. The people who ship stuff don't seem to mind, and they are the ones who make things matter.

bad_user 12y ago

> 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. Asm.js is meant for low level code, i.e. the kind of code that doesn't do garbage collection. High-level languages are better off compiling straight into Javascript. Solid examples that I know about: - http://www.scala-js.org/ http://www.scala-js.org/ (we are actually using this one) - https://github.com/clojure/clojurescript https://github.com/clojure/clojurescript - http://funscript.info/ http://funscript.info/ And there are other implementations as well.