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'?

[andrewducker]

For stuff that's included in the HTML you wouldn't, obviously.

But for stuff that's linked in there's no reason that the equivalent of:
<script type="byte/code" language="bytecode" src="http://myserver/somecode.byt"></script>

[momentsmusicaux.livejournal.com]

Heh if the server can handle compiling it, fine. I'm not going to fart around with an extra level of stuff every time I want to change one line in my JS!

[strawberryfrog.livejournal.com]

What is compile? For languages like Java or C# that use a bytecode, there are two things that you can call "compile".

First is turning the source into platform-independent bytecode, this happens upfront.

Second is "Just in Time compilation" during execution, when the runtime needs to use a method that has not been used before, and so needs to turn the bytecode for it into something that can actually execute on whatever cpu.

I'd say that Andrew is referring to the first of these.

[momentsmusicaux.livejournal.com]

Yes I know - I'm being facetious and saying that web developers won't put up with the faffiness of it.

[ciphergoth.livejournal.com]

How do you get there from here, though?

[andrewducker]

W3C?

It'd need to be part of HTML6, obviously :->

[ciphergoth.livejournal.com]

But what would web developers target?

[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.

[robhu.livejournal.com]

Hey we could do this now - just implement the VM in Javascript ;-)

[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,

[andrewducker]

They have their "Native Client" stuff, but I don't believe they've proposed it as a standard.

[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.)

[andrewducker]

The bytecode each browser sues for javascript is obviously going to be different - but I wasn't suggesting that they use these same engines for whatever standardises version came about.

Heck, I'd be happy with either Java bytecode or IL if they were suitable.

Compiling Java into JS seems terribly suboptimal to me, although I'm prepared to be told that actually it's a good fit. Having something that can be implemented in a standard way by the big 3 would be good.

[strawberryfrog.livejournal.com]

The bytecode that each browser turns the Javascript into is obviously different for each browser

Currently yes. But there's no reason why that should be so. In fact, isn't that the proposal?

Something like how The Java and .Net bytecodes are standardised and designed to be platform-independent, which is kinda the point. They can be executed by different engines. Those engines may have different internals, but executing that standard bytecode is their entire purpose.

.Net bytecode is less obviously "platform-independent" than Java. But there are 32 and 64 bit windows runtimes that work with the same bytecode. And mono/Linux run that same bytecode.

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.

Re: Native Client

[andrewducker]

Yup, thanks. I hope it gets picked up by other browsers.

[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.

[andrewducker]

Which is where Google's Native Client stuff comes in - which does sandbox things.

[strawberryfrog.livejournal.com]

The defence against forkbombs is that that Javascipt has little-to-no threading ability. Long-running scripts get shut down within a minute.

Security in bytecode systems is a problem that has been solved more than once, so it doesn't appear to be that hard. JS has no pointers, hence no buffer overflows, and I'd expect the bytecode to be likewise. In Java or .Net bytecode, security is mainly about gating access to the system API by untrusted bytecode.

[robhu.livejournal.com]

Why give it access to browser internals? Just provide access to the things JS already has access to, like the DOM.

[robhu.livejournal.com]

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

[andrewducker]

Yeah - I submitted it, and I've been astounded at its popularity. I've never posted my own journal there before, so I'm pretty happy :->

[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.