4 ms·

You're mistaken. It is not that people "just did not want to let JS go," but that "let JS go" is so immensely hard at this point in time that it is sitting near

by chc 14y ago

You're mistaken. It is not that people "just did not want to let JS go," but that "let JS go" is so immensely hard at this point in time that it is sitting near "boil the ocean" on the practicality scale. We don't know how to do it, so it's not a meaningful suggestion. In order to convince people that it's even worth trying, you need to enunciate a) a practical plan for "letting JS go," and b) a case for why the advantages of that plan in the context of the modern browser landscape outweigh the advantages of the plan the Mozilla devs are going with. You didn't do that. To put it another way: If we were implementing Web browser scripting completely from scratch with no history to lean on, this is not how I would do it and probably not how Dave Herman would do it either. But we aren't in that situation. As it stands, there are lots of existing JavaScript implementations that browser makers are heavily invested in — and they are not going to throw that all out and implement a new, incompatible and much more restrictive standard just because I wave my magic wand. The idea behind asm.js is that it is the smallest change you can make to still get the desired effect, because change is hard. Even if you don't think asm.js is perfect, it's a huge step in the direction you want to go. Complaining that it doesn't teleport us all the way there seems like missing the point.

adamnemecek 14y ago
I mean I get it but not acknowledging that sometime in the future, the band-aid will have to be torn off, and not talking about what would is the best way to do so is not helping either.
- chc 14y ago
  Sure, that would be an interesting conversation to have. But that's not what anyone's doing. Complaining that asm.js piggybacks off JavaScript instead of being a bytecode for which no interpreters currently exist — which is what you and fijal seem to be doing — is not "talking about what would be the best way to do that." In case you've forgotten, your suggestion in the other thread was literally just "a standardized VM in the browser." When I tried to get you to elaborate on what that meant in practical terms, you couldn't explain how it would be any different from what we have with asm.js except that you want a bytecode syntax for the input instead of the syntax asm.js uses. If you want to talk about practical ways we might move beyond JavaScript someday, feel free. I think that's an interesting topic. That's why I think it's unfortunate that so far, people just seem to be complaining that asm.js doesn't involve bytecode. Personally, I think asm.js is an important step in the direction of a post-JavaScript world. It moves us away from dependence on JavaScript by helping to better enable alternative languages in the browser.
  - adamnemecek 14y ago
    I'm not complaining about asm.js, it's more that I feel like the hole we (and I don't mean I personally) are digging is getting deeper and deeper and switching is only getting less and less likely. When you say that I could not explain how would it be different, maybe I just did not notice your response which is why I did not respond (and the last response is where you asked how is having JS as bytecode that different from any other bytecode). How would it be different? I mean it's not that I insist on the bytecode for the sake of having bytecode (I kind of hint at that several times in the last thread, but I guess I could have been more explicit). It's more that I feel that some sort of fundamental change in the way that web applications are built is necessary. Why? I don't think that JS & DOM scripting can be pushed that much further, like I'm having a hard time imagining that say 5-10 years down the line JS applications will be able to compete with native, somewhat computationally heavy applications (which is what I assumed was the direction in which this whole web thing was going). Today, when I open some site which is written as a SPA (e.g. HootSuite) in Chrome, within a couple of minutes, the CPU goes to 100% (on i7). And that is an application that is not really doing anything that computationally expensive. And it's not just HootSuite. So yeah, I don't really care that much about bytecode, and I realize that some change would not happen overnight. Do I have concrete steps how to achieve this? Can't say that I do.
    - nnethercote 14y ago
      > I don't think that JS & DOM scripting can be pushed that much further, like I'm having a hard time imagining that say 5-10 years down the line JS applications will be able to compete with native, somewhat computationally heavy applications (which is what I assumed was the direction in which this whole web thing was going). You're still not getting it. Native (i.e. compiled from C/C++) computationally-heavy applications is exactly what asm.js allows! The fact that it's a subset of JS is a clever hack that gets over the backwards-compatibility problems, but don't let that fool you -- asm.js really is a low-level compilation target.
      - adamnemecek 14y ago
        What exactly is there not to get? It's more that I'm not sure I believe the claims and that it seems like putting lipstick on a pig.
fijal 14y ago
Someone has to break it at some point. Making it live longer is not serving us any good. We would still be using primarily ALGOL, COBOL and Fortran 68 with this attitude
- chc 14y ago
  I agree that someone has to break it someday, but that's similar to how someday I'll buy a house — that doesn't mean I'm ready today! They aren't making JavaScript live longer — that will happen regardless. There simply isn't the will among browser-makers to break it all at once, so all you're doing by breaking it is making something that no one can use because it's completely incompatible with everything on earth. I feel like people are misunderstanding the challenge here. The challenge is absolutely not creating a proposed standard or creating a virtual machine. Those are relatively easy. The challenge is herding browser-makers to whatever solution you propose. The nice thing about asm.js is that it automatically works everywhere and it's easy for browser-makers to transition their existing products to it. Because it takes the path of least resistance, has a better chance of living up to the real challenge — gaining acceptance — than any other plan I've heard. There are already lots of virtual machines out there. Throwing another one at the wall isn't going to suddenly bring us into a post-JavaScript world. It reminds me of the xkcd about standards: [Situation: There are 14 competing standards.] Guy: "14?! Ridiculous! We need to develop one universal standard that covers everyone's use cases!" [SOON:] [Situation: There are 15 competing standards.]
- pcwalton 14y ago
  Algol, Cobol, and Fortran are languages—but new languages are precisely what asm.js enables.

by chc 14y ago

adamnemecek 14y ago

I mean I get it but not acknowledging that sometime in the future, the band-aid will have to be torn off, and not talking about what would is the best way to do so is not helping either.

chc 14y ago
Sure, that would be an interesting conversation to have. But that's not what anyone's doing. Complaining that asm.js piggybacks off JavaScript instead of being a bytecode for which no interpreters currently exist — which is what you and fijal seem to be doing — is not "talking about what would be the best way to do that." In case you've forgotten, your suggestion in the other thread was literally just "a standardized VM in the browser." When I tried to get you to elaborate on what that meant in practical terms, you couldn't explain how it would be any different from what we have with asm.js except that you want a bytecode syntax for the input instead of the syntax asm.js uses. If you want to talk about practical ways we might move beyond JavaScript someday, feel free. I think that's an interesting topic. That's why I think it's unfortunate that so far, people just seem to be complaining that asm.js doesn't involve bytecode. Personally, I think asm.js is an important step in the direction of a post-JavaScript world. It moves us away from dependence on JavaScript by helping to better enable alternative languages in the browser.
- adamnemecek 14y ago
  I'm not complaining about asm.js, it's more that I feel like the hole we (and I don't mean I personally) are digging is getting deeper and deeper and switching is only getting less and less likely. When you say that I could not explain how would it be different, maybe I just did not notice your response which is why I did not respond (and the last response is where you asked how is having JS as bytecode that different from any other bytecode). How would it be different? I mean it's not that I insist on the bytecode for the sake of having bytecode (I kind of hint at that several times in the last thread, but I guess I could have been more explicit). It's more that I feel that some sort of fundamental change in the way that web applications are built is necessary. Why? I don't think that JS & DOM scripting can be pushed that much further, like I'm having a hard time imagining that say 5-10 years down the line JS applications will be able to compete with native, somewhat computationally heavy applications (which is what I assumed was the direction in which this whole web thing was going). Today, when I open some site which is written as a SPA (e.g. HootSuite) in Chrome, within a couple of minutes, the CPU goes to 100% (on i7). And that is an application that is not really doing anything that computationally expensive. And it's not just HootSuite. So yeah, I don't really care that much about bytecode, and I realize that some change would not happen overnight. Do I have concrete steps how to achieve this? Can't say that I do.
  - nnethercote 14y ago
    > I don't think that JS & DOM scripting can be pushed that much further, like I'm having a hard time imagining that say 5-10 years down the line JS applications will be able to compete with native, somewhat computationally heavy applications (which is what I assumed was the direction in which this whole web thing was going). You're still not getting it. Native (i.e. compiled from C/C++) computationally-heavy applications is exactly what asm.js allows! The fact that it's a subset of JS is a clever hack that gets over the backwards-compatibility problems, but don't let that fool you -- asm.js really is a low-level compilation target.
    - adamnemecek 14y ago
      What exactly is there not to get? It's more that I'm not sure I believe the claims and that it seems like putting lipstick on a pig.

fijal 14y ago

Someone has to break it at some point. Making it live longer is not serving us any good. We would still be using primarily ALGOL, COBOL and Fortran 68 with this attitude

chc 14y ago
I agree that someone has to break it someday, but that's similar to how someday I'll buy a house — that doesn't mean I'm ready today! They aren't making JavaScript live longer — that will happen regardless. There simply isn't the will among browser-makers to break it all at once, so all you're doing by breaking it is making something that no one can use because it's completely incompatible with everything on earth. I feel like people are misunderstanding the challenge here. The challenge is absolutely not creating a proposed standard or creating a virtual machine. Those are relatively easy. The challenge is herding browser-makers to whatever solution you propose. The nice thing about asm.js is that it automatically works everywhere and it's easy for browser-makers to transition their existing products to it. Because it takes the path of least resistance, has a better chance of living up to the real challenge — gaining acceptance — than any other plan I've heard. There are already lots of virtual machines out there. Throwing another one at the wall isn't going to suddenly bring us into a post-JavaScript world. It reminds me of the xkcd about standards: [Situation: There are 14 competing standards.] Guy: "14?! Ridiculous! We need to develop one universal standard that covers everyone's use cases!" [SOON:] [Situation: There are 15 competing standards.]
pcwalton 14y ago
Algol, Cobol, and Fortran are languages—but new languages are precisely what asm.js enables.