Coding in web browsers

[andrewducker]

robhu has a good point over here.

At the moment we write Javascript in web pages, which is then compiled down by the various JIT methods that Firefox/IE/Webkit use to make it super fast.

Seeing as what's run clearly isn't the actual JS itself, but bytecode, why not have a standardised bytecode that all browsers would support, which would then mean you could write your code in any language you liked, providing there was a compiler to convert it to the standardised bytecode?

At the moment Google uses GWT to convert Java into Javascript that then gets converted into the running code, (And MS used to have something similar) wouldn't it be handy if the intermediate step wasn't necessary?

Comments

[momentsmusicaux.livejournal.com]

> developers can use whatever language they want and just compile it to the opcode language used by the browser.

Compile? What is this 'compile'?

[ciphergoth.livejournal.com]

How do you get there from here, though?

[khoth.livejournal.com]

And once we have standardised bytecode, the next logical step would presumably be to improve performance by creating CPUs that can execute it directly. In 20 years we'll all be back where we started.

[andlosers.livejournal.com]

Google have already proposed this, and I believe it's coming in Chrome. I'll see if I can dig out a link,

[drplokta]

The bytecode that each browser turns the Javascript into is obviously different for each browser, because each browser has different internals. So in your plan, each browser would still have to translate the bytecode into different bytecode in order to execute it. In which case, why not just call the existing Javascript language the bytecode, which also has the advantage of being human-readable, and make it the target for your compilers from other languages?

(The answer is because Javascript is lacking some functionality, not specified with sufficient rigour, in too many versions, with varying degrees of implementation in the browsers, and it takes too long to get changes into the spec, but I don't see how another spec for bytecode is going to be any different in this respect. You can only get round these problems by owning and implementing the spec yourself -- in which case you're re-inventing Flash or Silverlight.)

Native Client

[http://www.google.com/profiles/albzey (from livejournal.com)]

Exactly this exists already. Check out this:
http://code.google.com/p/nativeclient/

It probably will use LLVM bytecode at some point (I think it already supports that). Atm., it executes x86.

The hard part is the sandboxing. But it seems they have done well on this in the Natice Client.

[strawberryfrog.livejournal.com]

Reminds me of this recent rant: "we can write any program we like so long as it's in Javascript".

A bytecode standard is not a bad idea.

[lpetrazickis.livejournal.com]

I would imagine that browsers currently have no defences against malicious bytecode, since they generate it themselves and so don't expect it to be malicious. Their defences against forkbombs, buffer overflows, and the like are likely in the Javascript compiler, not the bytecode interpreter. There'd be huge security issues with giving third parties on the internet direct control of the browser internals as they are.

[robhu.livejournal.com]

This post is the top item on Hacker News atm btw :)

[figg.livejournal.com]

the problem here is not compiling to javascript but compiling to javascript *semantics*. if your lists, strings or dictionaries work differently, you have to re-implement them (in javascript)

llvm would be a nice idea but is still relatively young and unsuitable for jit compilation or mobile devices.

anything higher up (like an object system or datatypes like a string or a list or a hash) would present the same problems as compiling to javascript.