Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why are we limited to JS in browsers - would a bytecode standard help?

andrewducker.livejournal.com

Post reply on HN
Print view View original

11–20 of 187 posts

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#11

Post by AndrewDucker »

hannibalhorn wrote: post #7

Google is already heading there with native client. They're changing the approach to serving up LLVM bytecode on the server, which is translated to x86 or ARM by the browser prior to execution. For future apps that require performance, it should work well and with Google's weight behind the tech I think it'll be widely adopted. There's already a version of python that runs in native client, and pretty much anything c…

Oooh, LLVM bytecode. I hadn't thought of that, but it's a perfect choice!

I hope it does get picked up by other people.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#12

Post by stevecooperorg »

I'd be really interested in seeing this develop. Define a bytecode interpreter (JSVM?) and push bytecode into it. Performance may be god-awful, but you'd be free to use whatever language you fancy.

Parchment is an example of the approach, implementing the z-machine VM in javascript. http://code.google.com/p/parchment/

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#13

Post by siddhant »

joubert wrote: post #5

Google nativeclient might be a start... http://code.google.com/p/nativeclient/

There was a session about it, this time in the Google Developer Day at Munich. Interesting stuff. Right now they're stressing on C/C++, but probably C# is up next.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#14

Post by mattmanser »

pedrocr wrote: post #4

I tried to make this point in this submission: http://news.ycombinator.com/item?id=1790311 The fact that it also ranted about Javascript shifted the discussion though

Just keep on saying it! I've also been coming to the same conclusion and saying it, though just like you ranting about other stuff brought negative reactions:

http://news.ycombinator.com/item?id=1860623 http://news.ycombinator.com/item?id=1815214

But I'm glad to see more and more people are starting to argue for a pro-choice stance on languages in the browser.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#15

Post by stevecooperorg »

AndrewDucker wrote: post #6
[deleted] wrote: post #3

[deleted]

Is JS a good bytecode? Is compiling to it from Java about as efficient as compiling to a bytecode would be? If so (within an order of magnitude, I'm not fussy), then that's awesome - I hadn't realised that things were so efficient.

I'd also be interested in knowing. AFAIK, things like coffeescript compile to readable, plain JS. Can a relatively efficient system be made which interprets something more 'bytecodey' than readable JS;

eg,

interpret(['.maxstack 8', 'ldstr "Hello World!"', 'call void window.alert', 'ret']);

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#16

Post by iwr »

AndrewDucker wrote: post #10
CodeMage wrote: post #9

I really liked this comment (by khoth): "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."

I believe some work went on to produce a Java-running chip at one point. It proved better to compile down to whatever suited the chip best.

In that sense, Intel is just making CPUs on top of x86 bytecode that runs natively. I wonder if a little extra firmware can eliminate the need for an OS altogether.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#17

Post by TorKlingberg »

hannibalhorn wrote: post #7

Google is already heading there with native client. They're changing the approach to serving up LLVM bytecode on the server, which is translated to x86 or ARM by the browser prior to execution. For future apps that require performance, it should work well and with Google's weight behind the tech I think it'll be widely adopted. There's already a version of python that runs in native client, and pretty much anything c…

How do you get it properly sandboxed, while still able to interact with the browser document model?

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#18

Post by stcredzero »

siddhant wrote: post #13
joubert wrote: post #5

Google nativeclient might be a start... http://code.google.com/p/nativeclient/

There was a session about it, this time in the Google Developer Day at Munich. Interesting stuff. Right now they're stressing on C/C++, but probably C# is up next.

Go! Go is the cool lang for NaCl!

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#19

Post by gvb »

AndrewDucker wrote: post #10
CodeMage wrote: post #9

I really liked this comment (by khoth): "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."

I believe some work went on to produce a Java-running chip at one point. It proved better to compile down to whatever suited the chip best.

There have been several JVM (without the "V") created[1]. None of them really caught on other than the ARM Jazelle[2], which isn't really a JM, it is more of a JVM accelerator: it has support for direct execution of many of the JVM opcodes.

After investing lots of time and money into creating a JM, the companies were chagrined to find a general purpose processor with a good JVM (especially with JIT) could run circles around a direct-execution processor.

[1] http://en.wikipedia.org/wiki/Java_processor

[2] http://en.wikipedia.org/wiki/Jazelle

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#20

Post by stcredzero »

TorKlingberg wrote: post #17
hannibalhorn wrote: post #7

Google is already heading there with native client. They're changing the approach to serving up LLVM bytecode on the server, which is translated to x86 or ARM by the browser prior to execution. For future apps that require performance, it should work well and with Google's weight behind the tech I think it'll be widely adopted. There's already a version of python that runs in native client, and pretty much anything c…

How do you get it properly sandboxed, while still able to interact with the browser document model?

Limiting the translation and also through binary inspection. That's kinda the whole point of NaCl!
Post reply on HN