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

151–160 of 187 posts

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

#151

Post by tolmasky »

Detrus wrote: post #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…

Not sure what you mean by Objective-J being too far out. Objective-J is much closer and "interoperable" with JS than CoffeeScript because it is a strict superset of JavaScript (in other words, all JavaScript is also Objective-J). Practically what this means is that any existing JS works alongside Objective-J with no changes whatsoever, the syntaxes do not "collide". The difference between ObjJ and JS are comparable to ECMAScript 2 and 5 (additions of new features and keywords)

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

#152

Post by silentbicycle »

cpr wrote: post #110
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…

"Worse is better." (Google it.) Javascript is a good enough (New Jersey-style) solution. Why "fix" it?

Worse is Better doesn't quite fit here. WiB is about getting a "basically right" prototype out, and then improving it with real world feedback, rather than waiting forever to have a perfect 1.0.

With Javascript, unfortunately, it didn't work out so well - a bunch of early bugs (which could have been quickly fixed) were preserved when Microsoft made a bug-compatible clone for IE, and then became part of the ECMAScript standard in 1996. This derailed efforts to improve the language - there is a lot of work on sophisticated implementations now, but the spec itself is buggy.

People invoke "Worse is Better" as retroactive justification for all kinds of engineering blunders, but it's a bit more limited in scope. Here you go: http://www.jwz.org/doc/worse-is-better.html

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

#153

Post by orangecat »

cpr wrote: post #140
silentbicycle wrote: post #116

Earlier quoted context omitted.

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.

OK, don't use the "bad parts." But it's a lot more than that. It's the "taste" of the language itself, and Javascript tastes much more like the kind of language I like using. Lua always struck me as being so simple it crosses the line into Factor/Forth territory.

OK, don't use the "bad parts."

That's what I try to do, which turns it into a crippled Ruby. And there's no getting around it silently doing the wrong thing if I ever forget a "var" or "===".

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

#154

Post by silentbicycle »

stefs wrote: post #150

imho an intermediate bytecode makes no sense, as silentbicycle explained. 3 alternatives: 1) make every browser vendor implement multiple runtimes 2) x-to-js translators 3) interpreters in implemented in javascript ad 1) multiple runtimes: not a good idea, because of multiple reasons. first, versioning hell. javascript is ~15 years old, and browser vendors are still not able to provide 100% compatibility. you'd have…

I think a standardized bytecode for Javascript could make sense, but designing a VM for JS and then trying to port (say) Ruby or ML to it later would be awkward, and I don't think most web devs are aware of that.

Compiling to Javascript is a practical choice now. I'm not a fan of the language, but that avoids a lot of its pain points.

I also wonder why these discussions seem to assume we're going to stay with the web stack as-is forever, but that's neither here nor there.

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

#155

Post by cpr »

silentbicycle wrote: post #152
cpr wrote: post #110

Earlier quoted context omitted.

"Worse is better." (Google it.) Javascript is a good enough (New Jersey-style) solution. Why "fix" it?

Worse is Better doesn't quite fit here. WiB is about getting a "basically right" prototype out, and then improving it with real world feedback, rather than waiting forever to have a perfect 1.0. With Javascript, unfortunately, it didn't work out so well - a bunch of early bugs (which could have been quickly fixed) were preserved when Microsoft made a bug-compatible clone for IE, and then became part of the ECMAScript…

I respectfully disagree. "Worse is better" originally applied to the Bell Labs Unix efforts vs the Lisp Machine efforts at MIT and elsewhere.

Unix didn't get "fixed" later.

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

#156

Post by silentbicycle »

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.

It'll probably be slower than smartly written, natively compiled code, but not necessarily by enough to matter. It really depends on what you're trying to do, so the best way to know is to try it and measure.

Compiling to a human-readable format can be pretty straightforward. You can skip some steps entirely (e.g. register selection), and modern tools make it easy to ignore others (lexing & parsing) for quite a while. Don't think about it as "compiling", if you think that's a scary hard thing. Think of it as "reading in a couple kinds of simple structures and converting them to text". Like a templating engine.

Figure out what kind of operations you want to support, how to map them into small chunks of Javascript, and go for it. You can pass hand-written JSON, XML, sexps, dicts, etc. to the compiler in a REPL and worry about parsing and other stuff later.

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

#157

Post by TNO »

silentbicycle wrote: post #103
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…

Tcl would have been worse, probably.

VBScript

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

#158

Post by jashkenas »

tolmasky wrote: post #151
Detrus wrote: post #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…

Not sure what you mean by Objective-J being too far out. Objective-J is much closer and "interoperable" with JS than CoffeeScript because it is a strict superset of JavaScript (in other words, all JavaScript is also Objective-J). Practically what this means is that any existing JS works alongside Objective-J with no changes whatsoever, the syntaxes do not "collide". The difference between ObjJ and JS are comparable t…

Not to be combative, but I think what he means is this: Although it's perfectly easy to use JavaScript from Objective-J, the same is not true in reverse. ObjJ generates code that looks like this:

    objj_msgSend(objj_msgSend(CPIndexSet,"alloc"),
      "initWithIndexSet:",_selectedRowIndexes);
... where objj_msgSend is how the Objective-J "interpreter" does it's magic. If I wanted to use a library that was originally written in Objective-J, from JavaScript, I'd have a hell of a hard time calling it correctly, unless the library author took special care to make it JavaScript-compatible in the first place. The syntaxes may not collide, but the semantics certainly don't match up.

On the other hand, you'd never know that you were calling a CoffeeScript library from JS, unless you inspected the source, and vice-versa. In that sense, they're interoperable.

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

#159

Post by silentbicycle »

cpr wrote: post #155
silentbicycle wrote: post #152

Earlier quoted context omitted.

Worse is Better doesn't quite fit here. WiB is about getting a "basically right" prototype out, and then improving it with real world feedback, rather than waiting forever to have a perfect 1.0. With Javascript, unfortunately, it didn't work out so well - a bunch of early bugs (which could have been quickly fixed) were preserved when Microsoft made a bug-compatible clone for IE, and then became part of the ECMAScript…

I respectfully disagree. "Worse is better" originally applied to the Bell Labs Unix efforts vs the Lisp Machine efforts at MIT and elsewhere. Unix didn't get "fixed" later.

Actually, I think you're right - Javascript was frozen very early and Unix had a while to develop, but the same forces (competing commercial implementations) locked in minor errors in Unix as well.

I'd say Unix got more of its warts fixed than JS did, but that's only a difference of degree.

Mainly: The whole "Worse is Better" thing works better when you don't get stuck maintaining reverse compatibility with your early releases.

Post reply on HN