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

101–110 of 187 posts

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

#101

Post by [deleted] »

mascarenhas wrote: post #96
didip wrote: post #75

Earlier quoted context omitted.

If only Netscape just pick up Lua or Python instead of creating a language in a rush.

You have to compare Lua at 1995 (version 2) to JavaScript at 1995, as its development, at least inside the browser, would be arrested the same way JavaScript's was. Lua 2 was certainly had a much better implementation than the first JavaScript, but I would not call it a better language (didn't have JavaScript's annoying quirks, but also didn't have closures, for example). 2000's Lua (5.0 and 5.1) is quite different f…

[deleted]

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

#102

Post by silentbicycle »

alexmchale wrote: post #79

It's an interesting theory, but ultimately irrelevant. The thing is that there are SO MANY people working right now to make JavaScript incredibly fast. It's not hard to imagine a future where JavaScript is the fastest reasonable way to write software -- simply because it's the language that has the most R&D going for it. Did I say future? Oh, hello NodeJS. I don't envision that we'll be writing JavaScript itself fore…

And yet, for all the resources being thrown at improving Javascript, LuaJIT is still significantly faster. Oh, and it was written by one person.

The design of Javascript itself limits performance in various ways, unfortunately. See this discussion between Mike Pall (of LuaJIT) and Brendan Eich: http://lambda-the-ultimate.org/node/3851#comment-57671.

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

#103

Post by silentbicycle »

jules wrote: post #87
InclinedPlane wrote: post #80

Earlier quoted context omitted.

"Worst possible"? Sub-optimal perhaps, but Javascript is becoming very fast in the browser, perhaps it's not such a bad choice after all.

With enough effort you can put lipstick on a pig. But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you. Javascript is an historical accident. Let's look at some alternatives if history was different: - Scheme: this would have been…

Tcl would have been worse, probably.

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

#104

Post by bigmac »

hannibalhorn wrote: post #90
joelburget wrote: post #30

Earlier quoted context omitted.

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 w…

I think the change to PNaCl (LLVM) is largely responsible for this - after that decision was made and without much in the way of existing apps, there really isn't much incentive for them to invest more effort in the x86 specific version of NaCl. When PNaCl is ready and bundled with Chrome and Android, it's only going to take one killer app to really establish it.

I was at David Sehr's presentation at the LLVM conference. There are something like a dozen Googlers working on getting PNaCL working. They are able to get pretty close to the performance of native code, which is pretty enticing. There's still plenty of work left to do though.

One of the problems that needs to be fixed is that LLVM bitcode is kind of bloated, something like 6x as compared with native code. Another issue is that bitcode is not platform independent. Things like pointer sizes and exception handling are dependent on the target you are compiling to. Thus, they have to define a bunch of specifications for PNaCL programs so that they'll run everywhere.

It will definitely be interesting to see if anyone uses it. Like you said, one killer app will do the trick. I'd like to see Google Earth reimplemented for PNaCL, or any Google project for that matter. That would give more confidence that this is a project that is going to be taken seriously within Google.

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

#105

Post by klync »

Hoff wrote: post #59

Discussions of technical feasibility aside, getting a sufficiently large installed base to make this interesting is (as usual) the "fun" part; your plan for getting to critical mass against an available and "good enough" solution. As for previous bytecode approaches to consider, there are the Lisp Machines, or the Burroughs B5000 Algol box, or the EFI byte code (EBC) interpreter and the EBC I/O drivers, or UCSD pCode…

Congratulations on being the only person in this thread with two feet on the ground. Interesting discussion, nonetheless. But purely academic.

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

#106

Post by wmf »

jules wrote: post #29
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 alloc…

As a bytecode you wouldn't use a bytecode that is targeted at handling Javascript constructs.

So now you're asking the browsers to support two different VMs; one for JS and another one. Standardizing bytecode for JS (perhaps based on the existing Nitro or JagerMonkey bytecode) would be much less work.

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

#107

Post by wmf »

robhu wrote: post #74
pcarmichael wrote: post #39

Earlier quoted context omitted.

One difference is in compiler optimizations. For a given language, compilers can often make inferences based on the code and the semantics of the language, allowing for very targeted optimizations. If you go from LanguageFoo -> Javascript -> bytecode, then you may be limiting the range of optimizations possible (because Javascript may not be able to infer the same things about the code, be it because of program struc…

Why not make the 'byte code' the LLVM IF ? That way you leverage all the stuff from the LLVM project for making it go fast. The main thing to do then is just to have a front end for your favourite language the outputs LLVM IF.

Google's working on that: http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf

(Edit: I see that several other people already mentioned PNaCl further down in the thread. A hazard of HN's sorting, I guess.)

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

#108

Post by cpr »

No, it wouldn't help at all: let me point to the overwhelming success of standards (XML, HTML, Javascript, CSS, Postscript) that are character-based.

Think of Javascript as a (human-readable) virtual machine layer itself, below which the implementation is free to do as it pleases as long as it meets the JS standard semantics.

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

#109

Post by wmf »

silentbicycle wrote: post #100
Robin_Message wrote: post #88

Earlier quoted context omitted.

Just to note though: Javascript in fact doesn't require representing objects as hash tables. For example, the V8 javascript engine represents objects as instances of classes, more or less exactly how C++ would do it (the build the class definitions automatically in the background.) You are right on integers though, and other types of memory block in general, they are trickier to fix in a javascript engine. Surely the…

> Just to note though: Javascript in fact doesn't require representing objects as hash tables. For example, the V8 javascript engine represents objects as instances of classes, more or less exactly how C++ would do it (the build the class definitions automatically in the background.) That sounds like what Self does, too. See the excellent paper, "An Efficient Implementation of SELF" ( http://selflanguage.org/document…

Self and V8 are connected through Lars Bak. http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)

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

#110

Post by cpr »

jules wrote: post #87
InclinedPlane wrote: post #80

Earlier quoted context omitted.

"Worst possible"? Sub-optimal perhaps, but Javascript is becoming very fast in the browser, perhaps it's not such a bad choice after all.

With enough effort you can put lipstick on a pig. But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you. Javascript is an historical accident. Let's look at some alternatives if history was different: - Scheme: this would have been…

"Worse is better." (Google it.)

Javascript is a good enough (New Jersey-style) solution.

Why "fix" it?

Post reply on HN