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

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