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

81–90 of 187 posts

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

#81

Post by adamzochowski »

But you can run different languages inside a browser.

Activestate had Perl running inside browser: http://docs.activestate.com/activeperl/5.8/Components/Window...

  
    $window->document->write('Hello world!');
Also you can run VBScript. I have seen code that avoid javascript confirm() and tries to check first if it can use VBScripts msgbox function, just so it can provide 'yes'/'no' buttons. Aka:

  function confirmVB (text)
    confirmVB = msgbox ( Text , VBYesNo )
  end function
and then javascript

  function confirmYesNo(txtText)
  {
    if (window.vbSupported)
    {
  	return confirmVB(txtText);
    } else  {
  	return confirm(txtText + " (ok = yes, cancel = no)"   );
    }
  }
Cheers

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

#82

Post by scott_s »

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 the browsers own VM, or compile it directly to machine code. This proposal would standardize what the intermediate representation would be.

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

#84

Post by nix »

My admittedly biased view: I spent two years of my life trying to make the JVM communicate gracefully with Javascript - there were plenty of us at Netscape who thought that bytecode was a better foundation for mobile code. But Sun made it very difficult, building their complete bloated software stack from scratch. They didn't want Java to cooperate with anything else, let alone make it embeddable into another piece of software. They wrote their string handling code in an interpreted language rather than taint themselves with C! As far as I can tell, Sun viewed Netscape - Java's only significant customer at the time - as a mere vector for their Windows replacement fantasies. Anybody who actually tried to use Java would just have to suffer.

Meanwhile Brendan was doing the work of ten engineers and three customer support people, and paying attention to things that mattered to web authors, like mixing JS code into HTML, instant loading, integration with the rest of the browser, and working with other browser vendors to make JS an open standard.

So now JS is the x86 assembler of the web - not as pretty as it might be, but it gets the job done (GWT is the most hilarious case in point). It would be a classic case of worse is better except that Java only looked better from the bottom up. Meanwhile JS turned out to be pretty awesome. Good luck trying to displace it.

SWF was the other interesting bytecode contender, but I don't know much about the history there. Microsoft's x86 virtualization tech was also pretty cool but they couldn't make it stick alone.

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

#85

Post by nathanwdavis »

stevecooperorg wrote: post #15
AndrewDucker wrote: post #6

Earlier quoted context omitted.

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.

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.

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

#87

Post by jules »

InclinedPlane wrote: post #80
jules wrote: post #29

Earlier quoted context omitted.

The difference is that Javascript is about the worst possible IL for a compiler to compile down to. Yeah you can recover some of the speed by spending man years on making Javascript execute somewhat fast. As a bytecode you wouldn't use a bytecode that is targeted at handling Javascript constructs. You'd use a bytecode that, for example, supports machine integers (unlike Javascript). Something that allows you to alloc…

"Worst possible"? Sub-optimal perhaps, but Javascript is becoming very fast in the browser, perhaps it's not such a bad choice after all.

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 a much better choice, because it supports integers and has a compact object representation instead of representing everything with hash tables. Bad point: all objects are boxed (like in JS). Good point: tail calls are handy when compiling all kinds of control structures.

- Java: As an IL to compile down to this would have been better than Javascript. Good points on top of Scheme: unboxed primitive types, static typing means fewer runtime checks. Bad point: lack of tail calls.

- ML: excellent choice: has both unboxed primitives and tail calls.

I challenge you to find a language that would have been a worse choice than Javascript. It may turn out that by working really hard on smart runtimes and compilers you can get OKish performance out of Javascript in some cases, but that doesn't mean that it's a good choice for an intermediate language. A ML compiler that just translates to LLVM IL as simply as possible without doing any optimizations itself will easily beat the highly optimized Javascript engines we have today.

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

#88

Post by Robin_Message »

jules wrote: post #87
InclinedPlane wrote: post #80

Earlier quoted context omitted.

"Worst possible"? Sub-optimal perhaps, but Javascript is becoming very fast in the browser, perhaps it's not such a bad choice after all.

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 best IL is LLVM IL though, since it was designed so everything can compile down to it.

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

#89

Post by stevecooperorg »

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

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 interpreter in JavaScript. ;)

So under this scheme, you could do a server-side compilation of any language -- let's imagine Pascal as an example -- and deliver it back to the client as bytecode. Now you've broken the browser dependence on Javascript. At the cost of a VM written in JavaScript.

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

#90

Post by hannibalhorn »

joelburget wrote: post #30
joubert wrote: post #5

Google nativeclient might be a start... http://code.google.com/p/nativeclient/

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.
Post reply on HN