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

61–70 of 187 posts

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

#61

Post by tiles »

gvb wrote: post #19
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.

There have been several JVM (without the "V") created[1]. None of them really caught on other than the ARM Jazelle[2], which isn't really a JM, it is more of a JVM accelerator: it has support for direct execution of many of the JVM opcodes. After investing lots of time and money into creating a JM, the companies were chagrined to find a general purpose processor with a good JVM (especially with JIT) could run circles…

And that makes an excellent case for why JavaScript should simply be the bytecode of the future. x86 is gaudy and unsuited for many tasks--but it's where most of the speed innovation happens, thus it's the best platform for compiling other languages too.

I'll propose an alternative, fix JavaScript by adding APIs like ByteArrays and shorts and a proper int to the language. Over time, JS could become an excellent IL. We can standardize on intermediate bytecode, but like all things in web adoption, it will probably be the path of least resistance that works. (Who would ever give HTML graphic, multimedia, and threading abilities?)

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

#62

Post by skybrian »

lincolnq wrote: post #36
tomjen3 wrote: 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.

Then why don't you treat your JavaScript as object code, and compile a language you like better to it? It does not lack types (it just lacks static type checking); it is not significantly slower (JavaScript JIT is very advanced, and you're not compute-bound in JavaScript). And "it does not execute the same way on all platforms" is true for pretty much all languages on all platforms, so I don't know what you're gettin…

JavaScript lacks 64-bit integers and binary data, just for starters. You can emulate these things (GWT does) but not efficiently.

Byte code isn't necessarily the solution though. It might be a good idea to add these types directly to JavaScript, so they're usable both directly and as an object language.

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

#63

Post by chrisaycock »

lincolnq wrote: post #36
tomjen3 wrote: 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.

Then why don't you treat your JavaScript as object code, and compile a language you like better to it? It does not lack types (it just lacks static type checking); it is not significantly slower (JavaScript JIT is very advanced, and you're not compute-bound in JavaScript). And "it does not execute the same way on all platforms" is true for pretty much all languages on all platforms, so I don't know what you're gettin…

We can add Skulpt (Python) to that list too.

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

#64

Post by narag »

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?

Are compiled programs what people disliked? Do most people even know if an applet is a script, bytecode or compiled?

I don't believe that compiled programs is what the blog is advocating either, but the ability to run programming languages other than JS.

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

#65

Post by contextfree »

AndrewDucker wrote: post #27
siddhant wrote: post #13

Earlier quoted context omitted.

There was a session about it, this time in the Google Developer Day at Munich. Interesting stuff. Right now they're stressing on C/C++, but probably C# is up next.

Well, Mono supports LLVM, so it sounds feasible.

Mono has already been made to work with PNaCl (for some experimental-prototype-y definition of "already been made to work").

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

#66

Post by ssp »

It's not a bad idea.

In fact, why not take it a step further and make a stand-alone client that only executes the byte code? It would be different from Java for two reasons:

(a) The bytecode format could be much simpler if it weren't tied to a particular language (no type system, no objects, maybe not even a garbage collector). If the bytecode was similar to a real CPU architecture, it would be possible to target it from LLVM.

(b) There would be no humongous standard library to install, because it could just be downloaded on demand. With almost all of the library living on the server side, application authors could avoid a lot of the usual compatibility nightmares with different client implementations each one with its own bugs and workarounds.

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

#67

Post by narag »

rlpb wrote: post #58
tptacek wrote: post #52

Earlier quoted context omitted.

Have you not done the [java applet DOM] Google search, or is every link on the first SERP wrong in some way?

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.

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

#68

Post by contextfree »

amix wrote: post #34

Having a standard bytecode would make it much harder to steal code which is much needed as web and mobile applications shift towards using lots of JavaScript. Currently it's way too easy to steal everything since the whole source is exposed. You can obfuscate JavaScript and CSS, but the main semantics will still be there and someone that's interested will still steal your code (this has happend twice to us, even if a…

If anything I think e.g. .NET/CLR bytecode is easier to reverse engineer than obfuscated JavaScript, because of the type metadata.

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

#69

Post by contextfree »

stcredzero wrote: post #22
stevecooperorg wrote: post #12

I'd be really interested in seeing this develop. Define a bytecode interpreter (JSVM?) and push bytecode into it. Performance may be god-awful, but you'd be free to use whatever language you fancy. Parchment is an example of the approach, implementing the z-machine VM in javascript. http://code.google.com/p/parchment/

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

I think he's suggesting a bytecode interpreter implemented in JavaScript.

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

#70

Post by lincolnq »

skybrian wrote: post #62
lincolnq wrote: post #36

Earlier quoted context omitted.

Then why don't you treat your JavaScript as object code, and compile a language you like better to it? It does not lack types (it just lacks static type checking); it is not significantly slower (JavaScript JIT is very advanced, and you're not compute-bound in JavaScript). And "it does not execute the same way on all platforms" is true for pretty much all languages on all platforms, so I don't know what you're gettin…

JavaScript lacks 64-bit integers and binary data, just for starters. You can emulate these things (GWT does) but not efficiently. Byte code isn't necessarily the solution though. It might be a good idea to add these types directly to JavaScript, so they're usable both directly and as an object language.

Yes, it's true that it's utterly ridiculous that JS doesn't have integers. That's a definite lack of foresight on the part of the ECMAScript authors.
Post reply on HN