Live data from Hacker News

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

andrewducker.livejournal.com

121–130 of 187 posts

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

#121
post #87

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…

x86 was a historical accident, and yet it has become the most popular architecture for personal computers and servers in history.

There are plenty of examples of languages that are worse than Javascript for the web. Java being a perfect example. Java and Javascript co-existed on the web for quite some time (in theory they still do). Java is based on a "proper" IL. And yet here we are, talking about some hypothetical new IL to replace Javascript, despite the fact that there is no guarantee it would actually be better, as the historical example of Java has shown us.

You need to get more than just the VM "right", there's a billion other factors, Java screwed up, Javascript hit the mark (despite its many other flaws). Perhaps LLVM is the future of web applications, it's too soon to tell. What I do know is that Javascript may not be perfect but it's still fundamentally good, and powerful enough (largely through closures and prototypes) to allow for robust workarounds to its flaws (jQuery, coffeescript, etc.)

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

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

In 20 years we'll all be back where we started.

Only if people forget the past. If the past is any indication, people will forget. What were we talking about again?

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

#123

I might be missing something here, but this implicates a few things: You won't be writing code in the browser anymore. Otherwise you'd have fragmentation where the user doesn't have the proper interpreter installed, and a never ending stream of "language downloads" which might be cool to devs but horribly impractical for end users. Because we're not writing in the browser anymore, we'd be back to offline compilation…

> You won't be writing code in the browser anymore You could be. Impement a URL like http://mydomain/scripts/MyScript.bytecode . This is a page which compiles, say MyScript.rb into bytecode and delivers it back to the client. You get a new copy by saving a file on the server and hitting refresh, and there's only one interpreter to download.

That just moves the bytecode compilation to the server -- so you're back to my original point of generating the code statically. In fact it'd probably be worse, since there is no reason to compile MyScript.rb to bytecode more than once. It's like generating a dynamic page with Rails when all you really need is static, cacheable HTML.

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

#124
post #26

Earlier quoted context omitted.

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.

Crappy is subjective. I actually like JavaScript. JavaScript, although dynamic and loosely typed, does have types: string, number, object (including array, function and date), null and undefined are all JavaScript types.

IMO, the issue isn't if you like Javascript or not. It is is Javascript a reasonable language for compilers to target.

I think the core proposal is that Javascript stays the defacto language of the web, but you build a standardized IL that all browsers target. Of course Javascript would be one of the core languages that would guide the design of the IL, because you don't want this new IL and Javascript to incompatible.

The nice thing though is after you do that, other people can write new languages that target that IL, and they're not second-class citizens. It allows there to be real language innovation on the IL, just as there is language innovation on x86.

The problem today is that JS is not a great language to target, and it relegates anything that targets it to second-class status (why are you using XYZ, why not just use Javascript?).

I think its a great idea. IMO, this would be a far more important development than HTML5 for the life of the web.

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

#125
post #84

My admittedly biased view: I spent two years of my life trying to make the JVM communicate gracefully with Javascript - there were plenty of us at Netscape who thought that bytecode was a better foundation for mobile code. But Sun made it very difficult, building their complete bloated software stack from scratch. They didn't want Java to cooperate with anything else, let alone make it embeddable into another piece o…

x86 is a perfect comparative example. An architecture that is a patch on a patch on a patch (add several more layers here until you're tired) going back to the 8086 a kajillion years ago (a processor which was less sophisticated and powerful than an arduino). Intel tried to kill the architecture (replacing it with IA64) but AMD patched it yet again and the result was successful.

Nobody sane would design an architecture like x86 (or event x86-64) from the ground up today. Yet here we are.

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

#126
Maybe browser makers could expose a few lower level constructs in JS to make efforts like CoffeeScript, Objective-J and GWT easier?

That could be a short term solution. Long term we have to hope that LLVM and NaCl pick up steam.

But many languages for the same tasks will create fragmentation. Right now there is a big pool of developers proficient in JS. They even use the same libraries! The libraries are where a lot of productivity gains come from. The web became an "easy" platform to develop for. With fragmentation that could be lost.

CoffeeScript is interoperable with JS, easy to pick up because it's mainly a cleanup, but Objective-J and GWT are too far out. GWT needs a reworked JQuery, called GQuery.

So there are these economic considerations that are probably more important than language preference.

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

#128
post #43

Am I missing something, or did we all have a browser bytecode standard that everyone hopped on board with, and it turned out nobody really liked feeding browsers compiled programs after all?

The performance characteristics of the JVM didn't match the web IMHO. Javascript wasn't fast in a raw sense, but it didn't trade startup time for running time, didn't trade memory for performance, etc. The basis of Javascript is one that made sense for the web, for pages, for transient code. Since then they've done stuff to improve it, to make those issues less of a tradeoff, but when they started and had to make those tradeoffs Javascript made them correctly. The JVM didn't make them correctly for a web page. But I'm not sure the JVM was every really meant for that purpose.

In general though I think this demonstrates the environment and language mismatch problem. Retrofitting existing languages onto the web won't be very satisfying. There might be room for new languages (CoffeeScript is cool, for instance), and bytecodes could make that process more elegant, but ultimately those languages need to be different takes on Javascript or else it will feel ugly and awkward.

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

#129

Before speculating too much about "a bytecode standard", etc., it would probably be helpful to understand virtual machines and instruction sets. I know web programmers generally aren't big on assembly or writing virtual machines, but an instruction set (group of bytecodes) design and implementation predisposes a processor/VM to certain operations. A VM for an OO language is going to have bytecodes (and other infrastr…

I think having a byte code standard is totally possible. Webkit js engine Nitro/Squirrelfish already has bytecode. Spec is here http://webkit.org/specs/squirrelfish-bytecode.html

Nitro follows lot of luajit methods and techniques some are outlined here by Mike Pall - http://article.gmane.org/gmane.comp.lang.lua.general/58908 Some adopted by Nitro - http://webkit.org/blog/189/announcing-squirrelfish/ Nitro does the js-code -> bytecode -> jit-optimization.

However the more beneficial question is how long does it take it to convert js-code -> bytecode and how much it boosts overall performance. Seems like it is very small compared to execution times. https://lists.webkit.org/pipermail/squirrelfish-dev/2009-May...

On the contrary V8 does the direct compile yet following jvm/jit techniques. More details by Lars Bak here http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-E... and here http://www.youtube.com/watch?v=hWhMKalEicY V8 does some more non traditional things like snapshotting, hidden classes, etc which give incremental performance boost. If there was a bytecode standard some V8 techniques might not be applicable but it is possible to maintain the performance boost.

I would love to see bytecode getting as a standard so that people prefer to stick to whatever language they are comfortable with. For instance I like both js and python but if there was an option, I would stick to python for all my needs.

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

#130
post #84

My admittedly biased view: I spent two years of my life trying to make the JVM communicate gracefully with Javascript - there were plenty of us at Netscape who thought that bytecode was a better foundation for mobile code. But Sun made it very difficult, building their complete bloated software stack from scratch. They didn't want Java to cooperate with anything else, let alone make it embeddable into another piece o…

x86 is a perfect comparative example. An architecture that is a patch on a patch on a patch (add several more layers here until you're tired) going back to the 8086 a kajillion years ago (a processor which was less sophisticated and powerful than an arduino). Intel tried to kill the architecture (replacing it with IA64) but AMD patched it yet again and the result was successful. Nobody sane would design an architectu…

We build our computer systems the way we build our cities: over time, without a plan, on top of ruins.

-- Ellen Ullman

Post reply on HN