Hacker News Reader

Comment by otibom | Hacker News Reader

Ok so is the solution a standard bytecode for browsers ? Or is is NaCl ? Or PNaCl ? Or something like Hypercard ? Or do we tear down the monoliths that browsers are in small Unix-style components ?

View on HN

Or do we tear down the monoliths that browsers are in small Unix-style components?

That last one might not be a bad idea. The first browser I used ran 'xv' to display images.

In case you don't know of it: http://www.uzbl.org:

"uzbl-core: main component meant for integration with other tools and scripts

  - Uses WebkitGtk+ for rendering, network interaction (libsoup). Css, javascript,
    plugin support etc come for free
  - Provides interfaces to get data in (commands/configuration) and out (events):
    stdin/stdout/fifo/unix sockets
  - You see a webkit view and (optionally) a statusbar which gets populated
    externally
  - No built-in means for url changing, loading/saving of bookmarks, saving
    history, keybinds, downloads..."*

JavaScript is the standard bytecode.

I'm not following: Javascript is an interpreted language, not a bytecode standard. You can't compile Javascript to bytecode and run it anywhere.

Compare Javascript and Java Bytecode. The respective virtual machines are IonMonkey,V8,etc vs Hotspot,Harmony,etc. All those VMs are pretty portable across various architectures and operating systems. The syntax is C-like vs binary stack machine code. Both languages come with a documented standard, reference implementations, and standard libraries.
Sure, Javascript is somewhat harder to parse than Java Bytecode. Java Bytecode usually runs faster. However, from a high-level software architecture perspective there is not much of a difference. And the parser is usually not the performance critical part in any VM.

I never said it doesn't run in a VM. JavaScript is not bytecode. When the code is run, I grant you that you that the JIT will compile to some sort of bytecode. But you can't take that bytecode and run it under any virtual machine.
As for bytecode "running faster", that's entirely up to the JVM implementation. Given a feature complete JavaScript bytecode, I don't see why a JVM needs to be faster than the JavaScript VM.
You may be conflating the JIT nature of JavaScript vs fully compiled Java apps. With JavaScript, it interprets (even compiles) as it gets the JavaScript code, whereas Java code is already compiled into bytecode.

The V8 engine [0] compiles Javascript to assembly. Maybe it uses some other intermediate representation internally, maybe not. Why would you want to use bytecode for some random VM as internal representation?
You can run Javascript anywhere [1], why would you want to compile it to some portable bytecode?
[0] http://en.wikipedia.org/wiki/V8_(JavaScript_engine) [1] Well, there are restrictions, just like there are for Java Bytecode.

The original poster wrote "JavaScript is the standard bytecode". That's what I was responding to.

"Javascript is an interpreted language"
Huh? JavaScript JITs have been around for 4 years now.

Reply on news.ycombinator.com