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

161–170 of 187 posts

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

#161

Post by tolmasky »

jashkenas wrote: post #158
tolmasky wrote: post #151

Earlier quoted context omitted.

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

No not combative at all, what you say makes perfect sense. I suppose the confusion arose because he bundled objj with gwt, saying you'd need a totally different jquery, which is certainly not the case with objj.

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

#162

Post by teyc »

ianb wrote: post #128
tptacek wrote: 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 tho…

I believe the biggest cause of the JVM start up times were initializing the static members of classes.

Gilad Bracha wrote more here http://canoo.com/blog/2010/05/07/java-post-mortem-with-gilad...

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

#163

Post by nickik »

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…

JS is just not a good language as a compiler target. If you hade an Bytcode with all the right low level types and features it would be easier to optimise for the VM implementers (mozilla, google ...), you could modify JS without changing the VMs, languages would not be blocked by the speed of JS, faster languages would be possible. It would be easier to make languages that are very diffrent from JS work in the browser.

Your solution work but a haskell interpreter in js will never have good performence but if you could make a GHC backend that comipiles to "web bytecode".

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

#164

Post by jashkenas »

orangecat wrote: post #153
cpr wrote: post #140

Earlier quoted context omitted.

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

For what it's worth, there are tools that can help you avoid the bad parts. JSLint won't let you forget a "var" or "===" ... and if you use CoffeeScript, it's not possible to forget "var" or "===", because there aren't any.

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

#165

Post by pjscott »

klync wrote: post #105
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.

Since Google is actually working on this, I would read their PNaCL paper before calling the discussion "purely academic":

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

Summary: Send LLVM bytecode to the browser, and enforce sandboxing by inspecting the compiled code.

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

#166

Post by pyre »

silentbicycle wrote: post #32

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…

It's probably less to do with a bytecode 'standard' vs. a set of standard libraries for doing things outside of the browser (file manipulations, etc). Then browsers could just not support those libraries, but JavaScript VM developers could. In this way, it would be possible to not have 'the future of JavaScript' tied down to a specific bytecode implementation. Then people could pick and choose the VM that they want to run their JS in based on what sort of optimizations they needed.

One of the largest requirements here would probably be a method of linking against/using C libraries, and also a standard for 'import/#include/etc' statements.

Maybe I'm being naive here though. Feel free to correct me.

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

#167

Post by InclinedPlane »

silentbicycle wrote: post #159
cpr wrote: post #155

Earlier quoted context omitted.

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

I'd say Unix and C have more warts, and more serious warts, than Javascript does. But we have come to accept those warts in Unix and C as "the way things are" whereas we generally perceive javascripts warts as such. Arguably the decision to use null-terminated strings in C in order to save one or two bytes of memory per string is an error of much greater than Y2K proportions that we are still paying for.

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

#168

Post by SudarshanP »

pyre wrote: post #166
silentbicycle wrote: post #32

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…

It's probably less to do with a bytecode 'standard' vs. a set of standard libraries for doing things outside of the browser (file manipulations, etc). Then browsers could just not support those libraries, but JavaScript VM developers could. In this way, it would be possible to not have 'the future of JavaScript' tied down to a specific bytecode implementation. Then people could pick and choose the VM that they want t…

http://code.google.com/p/nativeclient/ may answer your need. Hopefully someday something like this will be available cross browser...

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

#169

Post by jrockway »

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.

Unix didn't get "fixed" later.

When did Unix get fixed?

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

#170

Post by silentbicycle »

jrockway wrote: post #169
cpr wrote: post #155

Earlier quoted context omitted.

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.

Unix didn't get "fixed" later. When did Unix get fixed?

You need to be pun-ished.
Post reply on HN