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 ?
"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..."*
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?
