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

21–30 of 187 posts

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

#21

Post by tav »

AndrewDucker wrote: post #11
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.

http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf

^ Overview of the LLVM-based Portable Native Client (PNaCl) architecture.

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

#22

Post by stcredzero »

stevecooperorg wrote: post #12

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/

Performance may be god-awful

Why, after decades of JIT bytecode VMs, do we still have this misconception? Many of the widespread JVM implementations are faster than V8. LuaJIT and C# Mono are also VM implementations that JIT bytecode and are faster than V8! Is this a troll?

http://shootout.alioth.debian.org/u32/which-programming-lang...

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

#23

Post by Groxx »

In all honesty... what's the difference?

Turing complete language ≈ Turing complete language. Just make something to compile your language of choice into JavaScript, or make a new one (CoffeeScript). Bytecode is just a little more dense, little faster executing, far harder to investigate language than JavaScript, which the browser can compile for added speed anyway.

I prefer my language-of-the-web to be readable, thanks. Then I can find out wtf it's doing. And where you really need speed, native client is just about your only option.

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

#24

Post by mvgoogler »

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.

I think you're thinking of Azul (http://www.azulsystems.com/products/vega/arch).

They've been slowly withering away for the past couple of years (at least judging by the number of cars in their parking lot - I work in the building they are in). They just announced a cloud-based product based on their systems, so maybe there's still some life there.

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

#25

Post by praptak »

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

Everything old is new again: http://en.wikipedia.org/wiki/Lisp_machine

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

#26

Post by tomjen3 »

Groxx wrote: post #23

In all honesty... what's the difference? Turing complete language ≈ Turing complete language. Just make something to compile your language of choice into JavaScript, or make a new one (CoffeeScript). Bytecode is just a little more dense, little faster executing, far harder to investigate language than JavaScript, which the browser can compile for added speed anyway. I prefer my language-of-the-web to be readable, tha…

The difference is that Javascript is a crappy language and I resent having to write in it. In addition, it lacks types and is therefore slower and does not execute the same way on all platforms.

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

#27

Post by AndrewDucker »

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.

Well, Mono supports LLVM, so it sounds feasible.

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

#28

Post by Groxx »

tomjen3 wrote: post #26
Groxx wrote: post #23

In all honesty... what's the difference? Turing complete language ≈ Turing complete language. Just make something to compile your language of choice into JavaScript, or make a new one (CoffeeScript). Bytecode is just a little more dense, little faster executing, far harder to investigate language than JavaScript, which the browser can compile for added speed anyway. I prefer my language-of-the-web to be readable, tha…

The difference is that Javascript is a crappy language and I resent having to write in it. In addition, it lacks types and is therefore slower and does not execute the same way on all platforms.

Not the same on all platforms is a wholly legitimate complaint. It's frickin' annoying that browsers don't all implement the same language.

But bytecode won't solve that. IE will still refuse to implement subset-X, WebKit will still prefix their CSS with -webkit, etc. Until everything settles down and decides on one implementation, in which case I'd still prefer to be able to read what the web is sending to me.

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

#29

Post by jules »

Groxx wrote: post #23

In all honesty... what's the difference? Turing complete language ≈ Turing complete language. Just make something to compile your language of choice into JavaScript, or make a new one (CoffeeScript). Bytecode is just a little more dense, little faster executing, far harder to investigate language than JavaScript, which the browser can compile for added speed anyway. I prefer my language-of-the-web to be readable, tha…

The difference is that Javascript is about the worst possible IL for a compiler to compile down to. Yeah you can recover some of the speed by spending man years on making Javascript execute somewhat fast.

As a bytecode you wouldn't use a bytecode that is targeted at handling Javascript constructs. You'd use a bytecode that, for example, supports machine integers (unlike Javascript). Something that allows you to allocate objects, rather than string indexed hash tables. Something that allows you to allocate an array of floats, rather than an array of boxed floats.

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

#30

Post by joelburget »

joubert wrote: post #5

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

In my experience NaCl is not a viable platform at this time.

My friend and I spent a couple weeks just trying to get the developer tools to work. We tried on Ubuntu, OS X, Windows, and Arch Linux. We weren't able to get started on a single platform. In the process we came across bugs that were several months old that haven't been fixed, even on their supported platforms.

Another thing to worry about is whether NaCl will take off. We can't know how committed Google is and how many users will install the plugin. It was supposed to be enabled by default in Chrome 6 (I believe) but it still isn't enabled in 7.

NaCl is still promising (especially Portable Native Client) but Google has to get it working first.

Post reply on HN