This is exactly what I meant - the technical solution is not the hard part, gaining widespread adoption is.

No, the technical solution is the hard part. Designing a bytecode format for the web would not be a trivial undertaking.

Assuming this work was completed, widespread adoption is mostly a matter of browser support and time. I suspect the Chrome team would be open to implementing it after it's been designed (there are parallels with the Native Client work), and other browser teams would be unlikely to resist if there are clear performance and workflow benefits (which there undoubtedly would be). Basically it's a "if you build it, they will come" situation.

To understand the scale of the task, consider the 'batteries-included' aspect. The core libraries for the bytecode format should be standardised (i.e. core library API set in stone for each major version of the bytecode). That's a huge amount of work. Then you'd also have the security testing needed (to ensure the bytecode was securely sandboxed). You'd also need to work on ensuring the bytecode was efficiently implemented for all processor architectures. I don't know about you, but I certainly don't feel qualified to do that.

Is "bytecode format for the web" not basically what Java applets were? Seems that adoption is the problem.

Except it wouldn't really be that hard. If Google and Mozilla were on board that would be enough. But neither has any interest it seems.

Yes, that thing was JVM, java.. It too escaped the browser and infiltrated the server..

No, it wasn't. It wasn't sandboxed and the libraries were not restricted enough to ensure a reliable target. Java applets were essentially running on the desktop, not in a website.

Write once, debug everywhere.

I know it's a Java joke, but it applies to everything cross-platform, all the more reason to make the core as uncomplicated as possible.