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.
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.
http://research.microsoft.com/apps/mobile/publication.aspx?i...
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...
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.
Get over it already.
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."
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.
My sense is that the people that suggest javascript as a compilation target really don't want competition for javascript in the browser.
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.