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!

[andrewducker]

Well, absolutely. Your stuff would be marked as being JS, and would continue to use the existing JS compiler/interpreter that's getting lots of attention at the moment.

[momentsmusicaux.livejournal.com]

That would mean Apache etc having to know how to serve JS files...

[andrewducker]

I'm confused by what you mean there.

Apache does serve JS files - that line from earleir was taken from one of our reports here, and was importing a .js file from an apache server before I changed it...

[momentsmusicaux.livejournal.com]

Yes, but who would do the compiling?

I'm not doing it, the browser isn't doing it, so it's got to be the server....

[andrewducker]

I'm clearly being unclear here. The JS stuff would work _exactly_ the same way it does at the moment - it would be compiled by the browser's JS engine.

[momentsmusicaux.livejournal.com]

Yeah, you've lost me. How is that different to what happens now? What's the benefit if it is -- the browser is still doing the work.

[andrewducker]

When it encounters:
<script type="byte/code" language="bytecode" src="http://myserver/somecode.byt"></script>
it will pass it to the bytecode interpreter to run.
When it encounters:
<script type="text/javascript" language="javascript" src="http://myserver/media/js/jquery.js"></script>
it will run it as it currently does through the JS interpreter.

The browser continues to do the work _for JS_, but allows you to write code in other languages if you so desire.

[momentsmusicaux.livejournal.com]

Right, so we are on the same page. So my question was -- who's going to make the bytecode?

[andrewducker]

Coders not using JS will make it with whatever tools they use.

Same as currently happens if you're using GWT or anything else which compiles into JS.

[figg.livejournal.com]

So,

people who write js can just write js

and people who write in something that compiles to js can compile to a different format instead

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

[robhu.livejournal.com]

Well, you'll get the choice. You can continue to use JS if you like, but people that want to use other languages (and I suspect there are A LOT of those) can use the byte code system. Think for example how many Ruby or Python web developers there are who are good with that language but not so great with JS.

There's no good reason why they shouldn't be able to write in Ruby/Python for the browser just like they do on the server end.

[figg.livejournal.com]

and yet they do already without a bytecode but compiling to javascript

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

[andrewducker]

Same as with all transitions, you target the stuff that's available now.

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

[robhu.livejournal.com]

Also - native client is not the same sort of thing. It's a way of running native code 'safely'. But we're not talking about running native code.

[andrewducker]

Native Client now supports LLVM bytecode :->

[robhu.livejournal.com]

Interesting. So I can compile some Ruby or whatever to LLVM byte code, then the native client will safely run it in Chrome (and hopefully in the future in other browsers)?

Is native client stuff allowed to interact with the DOM etc, or is it just like a plugin that operates inside an object tag?

[andrewducker]

Can't find out much about DOM interaction. I was assuming you could, but now I'm not so sure.

If not then that would be an obvious next step.

[robhu.livejournal.com]

DOM interaction is the main thing here :)

[andrewducker]

Absolutely. A bit more searching turns up that DOM interaction from plugins (like Flash or Java) is slow, because it's crossing a process boundary.

So we probably want it built in. Which, let's face it, it will be if it takes off...

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

[drplokta]

It's the big 4, I'm afraid. Safari and Chrome have not dissimilar usage figures (especially when you include all the people using Safari on iPhones, iPod Touches and iPads).

But my point is that it's not possible to have the same bytecode run natively in multiple browsers, or indeed in the same browser on different OS platforms. It will have to be run through a VM that translates the bytecode into actual native code in any case, so why not just call the Javascript interpreter the VM?

[andrewducker]

I was including Safari and Chrome as Webkit. Would that be erroneous?

It will have to be run through a VM that translates the bytecode into actual native code in any case, so why not just call the Javascript interpreter the VM?

I'm fine with that if JS is expressive enough and powerful enough for that. And the speed losses are within an order of magnitude. I really should play with something like GWT and see how long it takes to spit out the JS for a page.

Because if it's fast and powerful then, yes, absolutely.

[drplokta]

As I said upthread, Javascript probably isn't expressive and powerful enough, but I don't see how your new thing is going to avoid the standard-defining/implementing processes that have bollixed Javascript up. If you do have some new way to avoid the bollixisation of web standards, then simply apply this process to fixing Javascript.

[andrewducker]

Well, things seem to be progressing better now, with HTML5, than they have in the past. And according to Mr Bisson here it sounds like the major reason for not improving JS greatly is that it would break old code.

Starting over might just be easier than trying to improve JS.

(Or it might lead to ten years in committees arguing over it.)

[andrewducker]

Aha! Looks like Chrome's Native Client stuff might be what I'm looking for. It's LLVM based, and Mono now supports that as a back-end, as do lots of other languages. That'd make me happy.

Of course, it'd need to get picked up as a standard first...

[strawberryfrog.livejournal.com]

Javascript can't be fixed without breaking existing javascript code. It was like that from the start.

[skington.livejournal.com]

Don't Safari and Chrome have different JS engines? Irrespective of whether they share a rendering engine.

[andrewducker]

You're right - V8 for Chrome, Nitro for Safari. I forgot about that.

[call-waiting.livejournal.com]

In what way is it suboptimal? There's a slight time penalty in the translation from the higher-level language than bytecode, and there's a bit of a semantic gap between java and javascript, but it isn't necessarily terribly inefficient. If the javascript emitted is low-level enough, all the potential optimisation in the original source code can be exposed and there's almost no work for the host JIT to do.

Similarly, it's possible to write C code that's low-level enough that it's virtually impossible to do better by writing in assembly.

[drplokta]

Actually, I believe that C code tends to be faster than assembly these days, because the compiler is better than you are at ordering opcodes to take best advantage of modern CPU architectures and allow simultaneous execution of instructions in nominally single-threaded code while minimising waits.

[andrewducker]

Yes - I'd be surprised if it was worth handcrafting assembly more than once in a blue moon, especially if you're running on multiple generations of processors.

[call-waiting.livejournal.com]

In general, absolutely. Certainly on a modern superscalar CPU. But in the DSP space, assembly programmers have the edge when they have sufficient time to spend on an inner loop (and they're allowed to make assumptions that compilers aren't)

[jouni osmala (from livejournal.com)]

In 90's the assembly programming book simply stated, that if you hand translate your C code to assembler you loose. But if you solve the problem directly in assembler you could get ~6X performance improvement.
Another thing to consider is that assembler really requires LOTS of knowledge to actually be better than writing same in C.
Assembly acts as a leverage of your knowledge base, by giving you direct control over constraints that you do not have access to in C.
The amount of knowledge required for assembly to win over C is couple thousand pages worth of knowledge that isn't much use outside assembler programming how many programmers have read it?

[andrewducker]

It's how big the time penalty is, and how easy it is to bridge that semantic gap. If the answer is "not very" and "dead easy" then that's awesome and I'll shut up :->

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

[lpetrazickis.livejournal.com]

Historically, Javascript used to be capable of things like opening a new window which recursively opens two copies of itself.

The new Javascript worker threads are indeed incapable of fork-bombs due to the low limit on how many can be spawned.

I agree that adding a bytecode interpreter would be feasible, but I see it as a non-trivial task. Also, at least two browser vendors would have to forge ahead with it for the others to follow.

[strawberryfrog.livejournal.com]

I agree that bytecode interpreters aren't trivial, but are they much harder than the things currently being done to JavaScript in V8, tracemonkey, etc?

[figg.livejournal.com]

heh


bytecode intepreters are trivial, but that is their nature.

meanwhile effective just intime compilation as in v8, tracemonkey etc are a little more than a switch() statement.

lua is a bytecode interpreter and it is pretty simple to see how it works

meanwhile v8 uses jit to assembly + polymorphic inline caches + hidden classes to implement speedy dynamic dispatch

meanwhile nitro (or whatever apple is calling it) uses a technique of context threading, a simplified jit/bytecode hybrid that works by ensuring that the virtual machine doesn't get out of whack with the physical machine (i.e cache stalls, pipelining problems...)


you've got the wrong end of the stick: bytecode interpreters are easy, jit efforts like v8 are mammoth projects

[strawberryfrog.livejournal.com]

you've got the wrong end of the stick: bytecode interpreters are easy

My mistake was to go along with the parent poster, lpetrazickis's word usage, which was: I agree that adding a bytecode interpreter would be feasible, but I see it as a non-trivial task

Clearly, in the pedantic sense he is wrong. Bytecode interpreters are pretty simple. Equally clearly, a simple bytecode interpreter would not be sufficient for a theoretical layer under javascript, just as it is not for the JVM or .Net CLR. Jit is needed. I think we can agree that this is not trivial, and probably bears some comparison to V8 or Tracemonkey.

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