4 ms·

And, once again, this is why WE NEED A BROWSER BYTECODE STANDARD. Let us all go to hell in our own way. There is no reason to lock the browser in a cage half-

And, once again, this is why WE NEED A BROWSER BYTECODE STANDARD. Let us all go to hell in our own way. There is no reason to lock the browser in a cage half-designed and half-implemented by an engineer under a tight deadline over a decade ago.

mratzloff 14y ago
Or at least a JavaScript AST standard, like this one proposed in 2010: http://research.microsoft.com/apps/mobile/publication.aspx?id=120832 http://research.microsoft.com/apps/mobile/publication.aspx?i...
- ZenPsycho 14y ago
  There are problems with this idea in that- every js engine will have a different AST structure for optimisation reasons, and making the AST a standard rather constrains optimisation efforts- or forces implementors to include two seperate parsers.
rwallace 14y ago
We need a standard wire format for code to be run on browsers. Fortunately we have one: it's called JavaScript. If you look at the internals of that format, it happens to be designed to be written directly by humans, but if you find that design suboptimal (and it would be surprising if it wasn't, considering it was put together on a ten day deadline with contradictory requirements) you can ignore it and just treat it as object code to which your favorite language can be compiled. Doesn't Google make some internal use of a tool chain that compiles Java to JavaScript? And then of course there's Dart and CoffeeScript. I'm sure there'll be more.
- tibbe 14y ago
  Using JavaScript as object code is particularly efficient though.
  - riffraff 14y ago
    I'm 99% you're missing "not". 0.9% it could be an "in".
    - ZenPsycho 14y ago
      You would be quite wrong about that.
- carsongross 14y ago
  You can compile anything into anything, but for the vast majority of languages, the easiest thing to target with sane semantics is a virtual machine, not a crazy half-baked language (that I end up coding in for about 40% of my day.) A bytecode standard would free us from the crazy design decisions of javascript, give us source-level debugging, etc. And it wouldn't be that hard, given all the fine examples of VMs sitting around. My sense is that the people that suggest javascript as a compilation target really don't want competition for javascript in the browser.
  - rwallace 14y ago
    > A bytecode standard would free us from the crazy design decisions of javascript Not really, because most of the complication and mess is in the document object model, not the language syntax. How do you propose to solve that problem? > My sense is that the people that suggest javascript as a compilation target really don't want competition for javascript in the browser. You sense incorrectly. I'm not working in that area, I don't have a dog in that fight. I just think it's a good idea to point out problems with a proposed solution before somebody goes off and puts a lot of work into trying to implement it.
ZenPsycho 14y ago
There are a thousand really good reasons why this is a terrible idea. Just do a search of the ecmascript mailing list for bytecode . https://encrypted.google.com/search?hl=en&q=site%3Ahttps%3A%2F%2Fmail.mozilla.org%2Fpipermail%2Fes-discuss%2F%20bytecode https://encrypted.google.com/search?hl=en&q=site%3Ahttps...
- carsongross 14y ago
  No, there aren't. There is an entrenched bureaucracy and a load of fanboys who can't see past what is to what could easily be, all attempting to justify the current sorry state of affairs or ignorant of what's what. Look, if javascript, with all it's insanity, can be standardized across browsers, for the love of pete, a simple stack-based VM can be too. And then everyone can go to hell in their own way. Admittedly, people will stop using Javascript the second there is a viable alternative. I regard that as a feature.
  - ZenPsycho 14y ago
    Ignore reality if you want to. It's just never going to happen. Java had its chance. Java had every possible chance. Java had the advantage of making a deal with Netscape to purposefully cripple javascript to help promote Java. Sun tried for a decade, trying and trying to make Java the defacto web application language. Sun tried and tried to put its java VM in the browsers. And it lost. Java lost. Javascript won. End game. Being in denial about it won't change it. Trying it again isn't going to change the undeniable reasons that Java did in fact lose. Insisting that a VM is the best way to make web apps won't change the reality that we explored for years and years that it just simply isn't. It didn't work. It can't work. Get over it already.
    - ZenPsycho 14y ago
      here is what is more likely to happen. Brendan Eich: "If I wanted a safe intermediate form, I would look at arithmetic coding techniques that self-verify (so that you can't express other than well-formed programs), not bytecode and not JS source. It's IMHO very unlikely that TC39 will standardize a bytecode for JS. An AST encoding has better chances and better properties including self- verification and view-source-ry."
repsilat 14y ago
A bytecode standard is a decent idea, but I worry that it would be "good enough" for nearly everyone. What I think we really want is something more akin to what we have for native development: choice. We should have things like JVMs for the browser (cached on the client-side, no doubt), but we should also have non-portable code for people who want to do things that cannot be done portably. A bytecode standard cannot be all things to all people, because some people need to do things that can't be done on some platforms. If you really want everything to move to the web you need to expose vector math instructions for video encoding, you need to expose CUDA for scientific applications and so on. You need to be able to ship machine-code to the client where it can run (properly sandboxed, no doubt). Of course, if you want everything to move to the web there are bigger problems to overcome - HTML and CSS aren't really suited to application development, the filesystem APIs are not sufficient, and there's still the problem of getting GUI applications to compose well...

mratzloff 14y ago

Or at least a JavaScript AST standard, like this one proposed in 2010: http://research.microsoft.com/apps/mobile/publication.aspx?id=120832 http://research.microsoft.com/apps/mobile/publication.aspx?i...

ZenPsycho 14y ago
There are problems with this idea in that- every js engine will have a different AST structure for optimisation reasons, and making the AST a standard rather constrains optimisation efforts- or forces implementors to include two seperate parsers.

rwallace 14y ago

We need a standard wire format for code to be run on browsers. Fortunately we have one: it's called JavaScript. If you look at the internals of that format, it happens to be designed to be written directly by humans, but if you find that design suboptimal (and it would be surprising if it wasn't, considering it was put together on a ten day deadline with contradictory requirements) you can ignore it and just treat it as object code to which your favorite language can be compiled. Doesn't Google make some internal use of a tool chain that compiles Java to JavaScript? And then of course there's Dart and CoffeeScript. I'm sure there'll be more.

tibbe 14y ago
Using JavaScript as object code is particularly efficient though.
- riffraff 14y ago
  I'm 99% you're missing "not". 0.9% it could be an "in".
  - ZenPsycho 14y ago
    You would be quite wrong about that.
carsongross 14y ago
You can compile anything into anything, but for the vast majority of languages, the easiest thing to target with sane semantics is a virtual machine, not a crazy half-baked language (that I end up coding in for about 40% of my day.) A bytecode standard would free us from the crazy design decisions of javascript, give us source-level debugging, etc. And it wouldn't be that hard, given all the fine examples of VMs sitting around. My sense is that the people that suggest javascript as a compilation target really don't want competition for javascript in the browser.
- rwallace 14y ago
  > A bytecode standard would free us from the crazy design decisions of javascript Not really, because most of the complication and mess is in the document object model, not the language syntax. How do you propose to solve that problem? > My sense is that the people that suggest javascript as a compilation target really don't want competition for javascript in the browser. You sense incorrectly. I'm not working in that area, I don't have a dog in that fight. I just think it's a good idea to point out problems with a proposed solution before somebody goes off and puts a lot of work into trying to implement it.

ZenPsycho 14y ago

There are a thousand really good reasons why this is a terrible idea. Just do a search of the ecmascript mailing list for bytecode . https://encrypted.google.com/search?hl=en&q=site%3Ahttps%3A%2F%2Fmail.mozilla.org%2Fpipermail%2Fes-discuss%2F%20bytecode https://encrypted.google.com/search?hl=en&q=site%3Ahttps...

carsongross 14y ago
No, there aren't. There is an entrenched bureaucracy and a load of fanboys who can't see past what is to what could easily be, all attempting to justify the current sorry state of affairs or ignorant of what's what. Look, if javascript, with all it's insanity, can be standardized across browsers, for the love of pete, a simple stack-based VM can be too. And then everyone can go to hell in their own way. Admittedly, people will stop using Javascript the second there is a viable alternative. I regard that as a feature.
- ZenPsycho 14y ago
  Ignore reality if you want to. It's just never going to happen. Java had its chance. Java had every possible chance. Java had the advantage of making a deal with Netscape to purposefully cripple javascript to help promote Java. Sun tried for a decade, trying and trying to make Java the defacto web application language. Sun tried and tried to put its java VM in the browsers. And it lost. Java lost. Javascript won. End game. Being in denial about it won't change it. Trying it again isn't going to change the undeniable reasons that Java did in fact lose. Insisting that a VM is the best way to make web apps won't change the reality that we explored for years and years that it just simply isn't. It didn't work. It can't work. Get over it already.
  - ZenPsycho 14y ago
    here is what is more likely to happen. Brendan Eich: "If I wanted a safe intermediate form, I would look at arithmetic coding techniques that self-verify (so that you can't express other than well-formed programs), not bytecode and not JS source. It's IMHO very unlikely that TC39 will standardize a bytecode for JS. An AST encoding has better chances and better properties including self- verification and view-source-ry."

repsilat 14y ago

A bytecode standard is a decent idea, but I worry that it would be "good enough" for nearly everyone. What I think we really want is something more akin to what we have for native development: choice. We should have things like JVMs for the browser (cached on the client-side, no doubt), but we should also have non-portable code for people who want to do things that cannot be done portably. A bytecode standard cannot be all things to all people, because some people need to do things that can't be done on some platforms. If you really want everything to move to the web you need to expose vector math instructions for video encoding, you need to expose CUDA for scientific applications and so on. You need to be able to ship machine-code to the client where it can run (properly sandboxed, no doubt). Of course, if you want everything to move to the web there are bigger problems to overcome - HTML and CSS aren't really suited to application development, the filesystem APIs are not sufficient, and there's still the problem of getting GUI applications to compose well...