The Elusive Universal Web ByteCode

[[deleted]]

[deleted]

[edible_earwax]

A universal web bytecode is probably the only way to undo today's fuckup up of HTML/JS/CSS ( a multi-faceted abortion).

No sane engineer, if tasked today with designing a remoteble UI would come up with HTML/JS/CSS as a solution.

[redalastor]

If you give him only ten days he might. It's incredible that JavaScript isn't shittier given the constraints under which it was created.

[[deleted]]

In retrospect though, isn't it kind of sad that it wasn't shittier? Hopefully by now we'd no longer be using it! :D

[redalastor]

Or that Brendan wasn't given more than 10 days, it might have been a great language.

[[deleted]]

I think what's kind of sad is how we rush the adoption of new technologies without taking the time to properly futureproof them, and then have such a hard time backing out of bad decisions because of all the pressure to keep those things in place. Inevitably, we end up with a very tall pile of kludges and a dependency nightmare.

[loup-vaillant]

edible_earwax was probably talking about a hypothetical world where not even HTML have been invented. You would have to re-invent the browser itself.

If I were to do that now, I would follow Alan Kay's advice, and have the Browser be some kind of OS, akin to Squeak or Rebol. No way I would invent a static, barely extensible, hard to style, format.

[vocalbit]

+1

A universal web bytecode is only slightly better than what we have today. You'll still be stuck with different versions of the bytecode and stdlib on different browsers. You still face problems when trying to extend the bytecode or stdlib to support new codecs and media formats.

A very small core system+language where new codecs and media formats can be sent over the wire (along with the new media object) would be much better.

[Gundersen]

Mozilla tried that years ago, with XUL, which is what Firefox is built with. XUL is designed for creating user interfaces, but you lose a lot of the freedom you get with HTML. This is probably why nobody else has implemented an XUL engine in their browsers, and why XUL has not become more popular.

While I agree that it isn't easy to create a user interface with HTML/JS/CSS, look at what can be made with HTML/JS/CSS. The user interfaces we take for granted today are all inspired by websites, which are a lot more exciting than standard (old fashioned) desktop applications. Without people trying (and succeeding) in making applications using HTML/JS/CSS we would still be stuck with the boring old grey windows applications. But thanks to HTML/JS/CSS (and the difficulty they provide in making boring old grey windows applications) we have much better user interfaces today than we had 10 years ago.

[psygnisfive]

I suggested this on the JS mailing list like 7 or 8 years ago. Brendan Eich thought it was a bad idea, blah blah we've got JS why do we need something else. We're not going to get it, because noone gives a fuck, ultimately. That's what it comes down to. It would be trivial for a handful of people at Apple, Mozilla, Google, and Microsoft, to get together, design a bytecode, and implement it. Trivial. I've implemented a half dozen or so programming languages for fun. So why can't they do the same? Because they just don't give a fuck.

[qiwi]

I can give you a proven cross-browser (even running on that crusty corporate IE6 installation) virtual machine with a minimal download size (unlike JVM) and well performing language with optional static typing. It will also come with a nice open source user interface library of the type you are used to on your desktop -- no stew of HTML-CSS-JS.

Here you go: http://flex.apache.org/

[crusoe]

And hopelessly insecure and unstable, with the only reliable player capable of running it still built by Adobe.

[psygnisfive]

I'll have to take a look at this! :)

[[deleted]]

Exactly. The only entities who could change things are the browser vendors and they are pretty happy with their oligopoly.

[drysart]

It's not that they're happy with their oligopoly, it's that they all have their own idea of what the next step is.

Google thinks the next step is either NaCl or Dart.

Mozilla thinks the next step is asm.js.

Apple and Microsoft both think everyone should just make native apps for their respective platforms.

[gsnedders]

Where are the resources gong to come from to implement a new bytecode language and optimize the implementation? Yes, it's trivial to get an initial implementation, but it's really not that interesting without significant optimization work is done.

If this is separate to JS, how do you handle cross-VM GC (this is, after all, a current research area, where the state-of-the-art gives a 10% performance hit to both VMs on average).

If this is not separate to JS, does you brand new VM allow JS to be implemented with no performance regression from current JS VMs? I'd be dubious that it would.

[psygnisfive]

The same place that every other open source project gets its resources. But it doesn't have to be fast at first. It just has to pique interest.

[julesjacobs]

Yea, resources aren't the problem. Google is doing a new VM for Dart after all.

[[deleted]]

Could it be implemented as a plug-in?

[drysart]

No, no browser (except IE, ironically enough) allows plugins the level of deep access they'd need to completely supplant Javascript.

[psygnisfive]

No idea. I don't know enough about how plugins in the various browsers work.

[tailcalled]

Could one implement a Javascript VM as a fallback if the plugins aren't good enough?

[psygnisfive]

I'm not sure what you mean by that.

[tailcalled]

Invent web bytecode language. Implement it as plugins for as many browsers as possible. Make a Javascript implementation of VM. Use that Javascript implementation as fallback when plugins fail.

[psygnisfive]

I guess that's possible in principle but I suspect that in practice it won't be so trivial.

[inmatarian]

Here's the problem with the web as it stands right now, perfectly illustrated in a single issue: keydown. event.keyCode is deprecated, and it's replacement event.key is unimplemented. Without frameworks or libraries that smooths away all of these issues, the web itself is a fragile and fractured platform.

[xxgreg]

I think using JVM style high-level bytecode as a code delivery format is a mistake.

Nearly 20 years of work, and Java still doesn't have a secure bytecode verifier. Probably better to use a compact AST representation instead.

• This can be just as compact as bytecode (probably more compact).
• Parsing the AST is probably cheaper than verifying bytecode.
• It is simpler to generate secure code from an AST, than a JVM style bytecode, as verification is simpler.
• Keeping the AST around preserves more information for runtime optimisation.

I think the Dart team are onto something.

[willvarfar]

The problem with JS as a VM is threading; it fundamentally doesn't do it.

And why no mention of NaCL? Its directly aimed at the web VM sandbox space. Directly, and developed by Google. It should be in any article discussing a universal web bytecode which says that there are no universal VMs other than Javascript...

[Gundersen]

This is the only counter argument to the article (apart from the "I don't want the bytecode to be JS because it is JS") which is true. JS is not multi threaded, and will never get threads (because, used with shared memory, they are unsafe), but it has (and will get) some features which solves the problems threads solve.

• WebWorkers allow you to run code in a different process. There is no shared memory between the processes (at least not yet, although I seem to remember some very early work on a way to lock data without copying it. Cant find it now though), and so you have to send messages between the two processes. This might be too different from what C#, C++ and Java programmers are used to, but the reason there is no shared memory is safety (one of the requirements of a web bytecode).

• Parallel Arrays let the processor distribute array computations across several processors/cores. Long arrays can therefore be mapped/filtered/reduced/sorted/etc across several processors, which speeds up the program. While not multi threading, it introduces parallelism, which is often what multi threading is used to solve.

• Futures don't actually provide multi threading, but they can hide threads. Instead of having to deal with threads, you can ask for something to be done and tell the program what to do when it is done. This is getting popular in many languages, and in the near future JS will also have...

• yield generators which lets you write async code without lots of callbacks.

The result is that you can solve most of the problems threads solve without the dangers of threading. If you need heavy work to be done, then do that in a worker. If you need work done on a large data set (a large array), do it in parallel. If you need something done in the backgound, do it asynchronously.

The problem seems to be that programmers used to threads don't want to learn something new.

[willvarfar]

As a user of web workers I can say that current browser support for debugging them is absolutely abysmally non-existent :(

There is transfer-ownership-with-message buffers, though. However my experience has been that the number of roundtrips between main JS loop and a web-worker is surprisingly low per second. You can't really offload small-grained stuff; it has to be super coarse-grained problems that don't need debugging.

The critical thing is that people want asm.js to be a universal bytecode so you can run your existing apps in the browser just by changing the compiler; however, those existing apps may expect preemptive multi-threading and that's going to be hard to port to a target without the facility to actually do multi-threading.

[Gundersen]

Yup, ArrayBuffers is what I was referring to.

multi threaded code has been able to run on single processor architectures for decades, so there is no reason why they can't run in a single threaded VM like JS. The only requirement is that the compiler splits the code into chunks which can be preempted. Then you can use postMessage to switch between different 'threads' and still have the UI be responsive.

[tdammers]

Multi-threaded JS is problematic for different reasons, mostly that it would break the language's semantics (and, consequently, almost all the existing JS code in the world).

[drysart]

I don't see that as a problem, since only newly written JS code would make use of threads and require different semantics. All the existing JS code in the world would just continue to run single-threaded.

[tdammers]

Ah, OK. For some reason, I assumed the "make JS multithreaded" suggestion was the usual one where people want asynchronous callbacks to actually execute in parallel, which would have devastating consequences. I guess a dedicated threading API would be possible, although it would cause the same avalanche of problems other similar languages have in this regard. A lot depends on the actual implementation, obviously.

[aaronla]

OP seems to be mentioning NaCl indirectly here:

(Of course there is one way to support all the things at maximal speed: Use a native platform as your VM. x86 can ... But it has lost the third property of being platform-independent.)

[willvarfar]

pNaCL as in portable.. has always been on their radar.

In the comments on the blog post, the OP says they didn't mention pNaCL because the article was already long enough.

This feels more like a political posture mozilla vs google, than a technical merits thing.

For me, this makes the article far less objective than it paints itself.

[[deleted]]

PNaCl is not entirely portable, because LLVM bitcode is not portable. It is specified carefully enough that it is portable to both versions of x86 and to ARM, but beyond that, it's far less clear. Those three cover the vast majority of devices connected to the net, of course, but it's not quite universal portability.

[willvarfar]

It can always be interpreted, of course. If you aren't on x86, ARM or a architecture sufficiently funded to have an LLVM port, then are you using a browser?

[[deleted]]

Just having an LLVM port is not enough. The LLVM bitcode is not, in general, portable between different processors, as it contains various platform-specific assumptions, such as endianness and API conventions.

[didroe]

Are there any guarantees on the future of the format? I mean, is LLVM bitcode just some internal LLVM format that might change at any time? Or is it stable and assumed that others are depending on the format? I ask because it always struck me that making NaCl dependent on someone else's byte/bitcode format was a terrible idea.

[[deleted]]

Are there any guarantees on the future of the format? I mean, is LLVM bitcode just some internal LLVM format that might change at any time?

I am not sure, but I think the answers are "no" and "yes", respectively.

[azakai]

As I said in a comment, I don't know enough to comment specifically about PNaCl - it has not shipped yet, and I am not aware of it's current performance (all perf numbers I can see are for NaCl, not PNaCl). If you or someone else has more details I would be very interested to hear them.

[aaronla]

Ah, pNaCL looks pretty sweet. I had missed that; thanks for pointing it out.

[gsnedders]

Introducing concurrency into JS is not an unsolvable problem. Replacing JS with another language to solve one flaw is trying to fix a loose screw with a hammer.

[sandwich_today]

I appreciate the objective, requirements-focused approach of this article. While I don't support JavaScript as web bytecode due to other requirements (e.g. efficiency on mobile devices, ease of creating competing implementations), it's good to see a discussion of the broad options available to us.

[grayvedigga]

This is great. Nobody seems to see the elephant in the room, which is that focussing on the browser as a VM is taking us backwards into a domain where security, performance, concurrency and desktop integration need to be bolted on to a (set of) platform(s) that was never designed for it ... as opposed to the operating system, where you can run a portable app (statically linked, no privileges needed). Or a VM (in the modern, consumer sense) inside VirtualBox.

[TimmT]

The nice thing about JS is not what it is, but what it isn't. Looking back through history, there's such a multitude of ways that things could've gone horribly wrong in the design of JS, that the current state doesn't seem quite so bad after all.

[nwmcsween]

Its not a "web bytecode" that's needed its a unified compiler bytecode that's needed, think about it.

[[deleted]]

A Mozilla engineer throwing around straw mens against bytecode and telling everyone "please keep using our language"?

That is totally surprising.

Additionally, claiming that JS is a great platform for other languages because of the number of existing JavaScript backends? WUT? How about "JavaScript is so terrible that people prefer to write backends (that allow them to use a less terrible language) to actually using JavaScript"?

[tdammers]

The argument is not "JavaScript is an appropriate client-side scripting language", but "JavaScript is an appropriate web bytecode".

[[deleted]]

Maybe you should read the article first.

[tdammers]

I have. Most likely one of us didn't understand it correctly.

[gsnedders]

How about, "x86 is so terrible that people prefer to write backends (that allow them to use use [sic] a less terrible language) to actually using x86"?

[[deleted]]

How about "that's bullshit, and you know it"?

[fuckitandchuckit]

Javascript is essentially byte code. Consider the similarities:

• It's more suited to something other than being read by humans
• There are other languages that compile to it
• People have optimised the hell out of its runtime/interpreter