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

111–120 of 187 posts

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

#111

Post by cpr »

silentbicycle wrote: post #44
brainlock wrote: post #42

Earlier quoted context omitted.

I'd add that it has functions as first-class citizens and closures. Javascript has for sure some crappy parts, but there is also a lot of good in it.

I find Javascript depressing. If it had a few more years to develop, it could have been a really great language. I understand why it wound up that way, but, sigh. If you want to see a much better language with the same general design, look at Lua. It's made for scripting C programs rather than web pages, and it has had over a decade longer to mature.

I find Lua depressing and Javascript exciting. So where does that leave us?

If it's all a matter of taste as to what's desirable in a "mature" language, your argument doesn't go very far.

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

#112

Post by wmf »

mvgoogler wrote: post #24
AndrewDucker wrote: post #10

Earlier quoted context omitted.

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.

Azul's Vega isn't really a Java processor; it's a generic RISC with a hardware-assisted read barrier.

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

#113

Post by silentbicycle »

wmf wrote: post #109
silentbicycle wrote: post #100

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

He worked on Beta / Mjølner, too. Neat!

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

#115

Post by _b8r0 »

narag wrote: post #67
rlpb wrote: post #58

Earlier quoted context omitted.

From the first hit: "Java applets may need to perform Java to JavaScript communication to access the Document Object Model (DOM)..." So it seems that it is hardly an alternative. > ...or is every link on the first SERP wrong in some way? What I don't expect to find quickly is exactly how long this has been possible in which browsers since when. Was it possible back in the days of IE4 and Netscape 4 or 4.5 or whatever…

IIRC, possible in Netscape 4.0x, but not easy or pretty.

Nothing was easy or pretty with Netscape 4. Zarro boogs found my arse!

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

#116

Post by silentbicycle »

cpr wrote: post #111
silentbicycle wrote: post #44

Earlier quoted context omitted.

I find Javascript depressing. If it had a few more years to develop, it could have been a really great language. I understand why it wound up that way, but, sigh. If you want to see a much better language with the same general design, look at Lua. It's made for scripting C programs rather than web pages, and it has had over a decade longer to mature.

I find Lua depressing and Javascript exciting. So where does that leave us? If it's all a matter of taste as to what's desirable in a "mature" language, your argument doesn't go very far.

I'm mostly thinking about how many of the problems highlighted in "Javscript: The Good Parts" have been fixed in Lua, while Javascript can't be fixed. Not a matter of design and taste, but outright bugs.

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

#117

Post by jules »

Robin_Message wrote: post #88
jules wrote: post #87

Earlier quoted context omitted.

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…

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…

Yep, sophisticated implementations try to infer the patterns in which objects occur and then dynamically generate classes for them. However this is not without problems, because if you assign to a new slot then you need to change the object's class, it needs to gracefully degrade to when the objects are used as hash tables, etc.

LLVM IL would be excellent for speed. The problem is that it's not memory safe (i.e. it allows reading and writing to arbitrary memory locations). NativeClient at Google is trying to solve that. http://code.google.com/p/nativeclient/

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

#118

Post by chc »

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.

LLVM is really how NaCl should be done anyway. The idea of compiling your Web app for a physical hardware architecture is completely backwards, particularly now that there are two families in wide use among consumers.

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

#120

Post by stcredzero »

stevecooperorg wrote: post #89
stcredzero wrote: post #22

Earlier quoted context omitted.

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

As people have commented, I'm suggesting writing a javascript function which takes pre-compiled bytecode; like so; function interpret(bytecode) { // stack machine implementation goes here } And called like so; var bytecode = load("http://my.domain.com/myscript.bytecode"); interpret(bytecode); I'm not suggesting that bytecode is inherently slow -- just that I could take a great stab at writing a slow bytecode interpre…

I'm suggesting writing a javascript function which takes pre-compiled bytecode

Sorry, I misunderstood.

Now you've broken the browser dependence on Javascript. At the cost of a VM written in JavaScript.

I keep looking at these two sentences again. On one hand I know what you mean. On the other hand, this doesn't make any sense because it contradicts itself. (Which is why I misunderstood the original comment, I think.)

Post reply on HN