Question:
Despite the huge plurality of programming languages in different environments (desktop, server, mobile devices), the browser continues to support one and only one language: JavaScript. The reason for this escapes me: although there is a problem with compatibility (whoever makes a website or web app wants it to work in any browser ), nothing prevents other languages from being used and "compiled" for JavaScript. This can be done either on the server side (eg Google Web Toolkit ) or client side (eg processing.js ). Although it seems like a "gambiarra", it works, and there is no lack of interest in it (the PyPy platform used to support Python compilation for JavaScript, but the last time I checked this functionality was abandoned).
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.) )?
Answer:
There are some technical impediments that make it difficult to implement a multilingual environment in the browser.
The Javascript language has bindings in Webkit (for example) which is one of the web engines, between the c++ runtime and the javascript VM (V8 in the case of chrome and JavascriptCore in the case of safari)
First of all, any candidate for an alternative language to Javascript, would need to have a VM also plugged directly into the Webkit, with the respective bindings between the c++ runtime and the VM runtime.
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:
Imagine, for example, if from 2014 onwards browsers with javascript and dart are launched.. the developers would need to check if the browser supports Dart or another script and from there, decide to send it or browser.. (but this is also a of the reasons why Dart compiles to Javascript.. no problems in this case), but if the implemented language doesn't have this transpiler.. nothing done
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)
With this idea it would be possible to have only one VM in the browser, implement Javascript in order to produce this IR, and leave it open so that other compiler beast developers can implement different languages for the browser (or whoever ships this VM)
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.