Is there any standardized way (or in the process of being standardized, à la HTML5) to support other programming languages in the browser, which does not depend on the installation of plugins (eg Java, Flash, Silverlight)? Preferably, something that works exclusively on the client side (like the example of processing.js) without requiring a specific program on the server side (and consequently a round-trip to it whenever code has to be interpreted).
And if not, are there any known obstacles that make such a thing unfeasible? In other words, it is only due to a lack of interest on the part of the providers that this occurs, or is there an open problem that prevents such a thing – either privately or that depends on consensus between the different major players (standardizers, browser providers, etc.) )?
There are some technical impediments that make it difficult to implement a multilingual environment in the browser.
The Webkit would have to be rewritten to support (at runtime) two or more VM's alternating according to user or developer code
Google's Dart project tried this (and still tries), being possible to use this branch of Chrome, called Dartium.. But apparently there are serious problems with garbage collectors due to two or more VM's having to be loaded in the same process, splitting memory regions… considerably degrading performance.
One of the limitations is that the DOM logic is written in C++, and the language's VM has to do quite expensive operations efficiently every time it needs to communicate with the native c++ runtime; Possibility: rewrite the DOM, HTML, SVG logic, etc.. in each script language.. but.. there are not many gains because these languages tend to be less efficient than C, so the gain in communication ends up being lost in others places 🙁
There are also compatibility issues:
Another possibility would be to use an IR – Intermediate Representation – from a compiler, where this IR is so powerful that several languages can be implemented on top of this representation.
Two great examples are the java bytecode, which allowed several different languages to work in the JVM, and also more recently the LLVM project, with its own "bitcode". (other ideas of note are mozilla's asm.js.. but which are not as ambitious as a universal IR)
Note: IR JVMs as well as LLVM have limitations for dynamic languages because they were thought for the reality of static languages in their design.. LLVM still produces a bytecode with some non-portable elements with instructions for specific processors.. not being a IR "universal".
Google's Pnacl project uses a modified LLVM VM, with a properly universal bytecode.. problems: LLVM was made for AOT compilation, so it takes time to compile, as it seeks to produce an extremely optimized final code, unlike JIT VM's like V8 , Dart and Lua that also seek speed when producing the code.
As seen, there is no easy path to this long-awaited platform, even if there is a desire to pursue this path, it takes a lot of investment to fund a high-level team, for at least 2 years, to come out with an acceptable result.
The best option now is to see if the Dart project can be shipped with Chrome, having at least a dual platform.. because for this "universal" platform, it takes a miracle, will and a good sum of money to reality.
Note: I am using IR in the sense of final (retargatable) bytecode, and not in the sense of intermediate internal representation of compilers (IR level 1), as IR is commonly defined in the specialized literature on compilers.