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

91–100 of 187 posts

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

#91

Post by jallmann »

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 and static code generation. I suppose it'd be possible to JIT the bytecode (assuming that current Javascript optimizers work on the IR; I don't know enough to qualify this any further). From my casual browsing of LtU, it seems that tracing JITs in particular may offer optimizations dificult to achieve with static bytecode compilation, particularly in identifying hot spots. But the more I think of it, that's a non-issue because you're still compiling to bytecode and JITing from there.

This feels very Java-ish to me. If you really want to script the browser in another language, compiling to Javascript (a'la GWT) would essentially do the same thing.

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

#92

Post by [deleted] »

didip wrote: post #75
haribilalic wrote: post #49

Earlier quoted context omitted.

JavaScript was released in 1995 as part of Netscape Navigator 2.0. Lua was released in 1993. I don't know about a decade .

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

[deleted]

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

#93

Post by silentbicycle »

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

All true. But I think the potential benefits are real, and I don't necessarily think it's a bad thing if the JS VM was specialized for JS. Standardizing the byte-codes could allow a looser coupling between browsers and JS. It could also allow for people to play with JS optimizations and augmentations without having to touch the VM internals itself. All of this makes me think that if I was a VM researcher, I'd serious…

I agree with you. Typical web devs probably don't have enough context about virtual machine implementation to understand the trade-offs, though.

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

#94

Post by stevecooperorg »

nathanwdavis wrote: post #85
stevecooperorg wrote: post #15

Earlier quoted context omitted.

I'd also be interested in knowing. AFAIK, things like coffeescript compile to readable, plain JS. Can a relatively efficient system be made which interprets something more 'bytecodey' than readable JS; eg, interpret(['.maxstack 8', 'ldstr "Hello World!"', 'call void window.alert', 'ret']);

This is what I've been thinking about too. If javascript like what you wrote above were much faster than nicely structured, readable javascript, then perhaps the idea of "Javascript is the bytecode" may not be such a bad one. I'm just not sure that it would really provide the performance improvement we would hope for.

It would almost certainly be a good deal slower. Or at least, it would be if I wrote it.

I know cappucino (http://cappuccino.org/) works with a JavaScript language interepreter, so there are mature products out there heading along these lines.

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

#95

Post by stevecooperorg »

jallmann wrote: post #91

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.

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

#96

Post by mascarenhas »

didip wrote: post #75
haribilalic wrote: post #49

Earlier quoted context omitted.

JavaScript was released in 1995 as part of Netscape Navigator 2.0. Lua was released in 1993. I don't know about a decade .

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 from its earlier incarnations.

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

#97

Post by robhu »

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

I don't think you understand the proposal: JavaScript would still be the language of the web. The things you don't see would just be handled differently. In fact, it would be easier to to "find out wtf it's doing" because something that is now ad-hoc - what to do with the JS given to a browser - would be standardized. Keep in mind that the browsers already do something to your JS, either compile it to byte-code for t…

No, the idea is that you could compile whatever language you like into byte code that would then run in the browser.

Javascript might still be the main language on the web (and would probably continue to be handled in the same way it is now) but you could also use other languages.

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

#98

Post by nikcub »

snissn wrote: post #83

Microsoft's silverlight plugin allows for embedding python and ruby in the browser: http://www.silverlight.net/learn/dynamic-languages/

and Javascript. It is very very fast with Javascript.

You can do what is discussed in this thread today by detecting Silverlight in the client and if it exists use it instead of Javascript source. DOM access, manipulation and everything else is just so much faster.

The Silverlight SDK is free, you can get it on Linux and OS X (Moonlight) and there are a lot of Silverlight VM's out there

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

#99

Post by scott_s »

robhu wrote: post #97
scott_s wrote: post #82

Earlier quoted context omitted.

I don't think you understand the proposal: JavaScript would still be the language of the web. The things you don't see would just be handled differently. In fact, it would be easier to to "find out wtf it's doing" because something that is now ad-hoc - what to do with the JS given to a browser - would be standardized. Keep in mind that the browsers already do something to your JS, either compile it to byte-code for t…

No, the idea is that you could compile whatever language you like into byte code that would then run in the browser. Javascript might still be the main language on the web (and would probably continue to be handled in the same way it is now) but you could also use other languages.

For reasons that silentbicycle presents elsewhere in this thread, that goal is quite difficult. The benefits I mentioned above would be true even if no other languages compiled down to the standardized byte-code - we'd have the above benefits first.

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

#100

Post by silentbicycle »

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…

> 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/documentation/published/implementati...).

The Self bibliography page (http://selflanguage.org/documentation/published/index.html) has a lot of other content applicable to dynamic languages in general, too.

Post reply on HN