How to use another language that does not JavaScript in the browser?

9

In spite of the huge number of programming languages in various environments (desktop, server, mobile devices), the browser continues to support one and only one language: JavaScript. The reason for this escapes me: even though there is a compatibility problem (anyone who 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 (eg processing.js ). Although it seems to me a "gambiarra", it works, and interest in it does not lack (formerly the platform PyPy supported Python compilation for JavaScript , but the last time I checked this functionality was abandoned).

Is there any standardized (or standardized, HTML5) way of supporting other programming languages in the browser, which is not dependent on installing plugins (eg Java, Flash, Silverlight)? Ideally, something that works exclusively on the client side (such as the processing.js example) without requiring a specific server-side program (and therefore a round-trip to it) whenever a code has to be interpreted).

And if it does not exist, is there any known obstacle that would make such a thing unfeasible? In other words, it is only because of a lack of interest on the part of the suppliers that this occurs, or is there a problem still open that prevents such a thing - either privately or depends on consensus between the different major players standard browsers, browser providers, etc.)?

    
asked by anonymous 08.02.2014 / 08:43

5 answers

7

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 the language alternative to Javascript would need to have a VM also plugged directly into Webkit, with the respective bindings between the c ++ runtime and the VM runtime.

Webkit would have to be rewritten to support (at runtime) two or more VMs by alternating according to user code or developer

The Google Dart project has tried this (and still tries), and it is possible to use this branch of Chrome called Dartium .. But apparently there are serious problems with garbage collectors because two or more VMs have to be loaded in the same process, dividing regions of memory .. considerably degrading the performance.

One of the limitations is that the DOM logic is written in C ++, and the language VM needs to do fairly expensive efficiency operations every time it needs to communicate with the native runtime in c ++; Possibility to rewrite DOM, HTML, SVG, etc. logic 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 2014 browsers with javascript and dart are launched .. developers would need to check if the browser supports Dart or another script to go from there, resolve to send it or browser .. (but this is also one of the reasons why Dart compiles to Javascript .. there are no problems in this case), but if the implemented language does not have this transpiler .. nothing done

Another possibility would be to use an IR - Intermediate Representation - from a compiler, where this IR was so powerful that several languages could be implemented on top of that representation.

Two great examples are the bytecode java, which allowed several distinct languages to work in the JVM, and also more recently the LLVM project, with its own bitcode. (other note ideas are the mozilla asm.js .. but they 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 thus leave it open so that other compiler-savvy developers can implement different languages for the browser (or whoever embarks this VM)

Note: IR JVMs as well as LLVM have limitations for dynamic languages because they have been designed 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 "universal" IR.

The project of Google Pnacl, uses a modified LLVM VM, with a bytecode properly universal .. problems: LLVM was made for AOT compilation, so it takes time to compile, because it seeks to produce an extremely optimized final code, unlike VMs JIT's like V8, Dart and Moon that also look for speed in producing the code.

As seen there is no easy way for this long-awaited platform, even if there is a will to pursue it, it takes a lot of investment to afford a high-level team, for at least two years, to come out with an acceptable result

The best request 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, a will and a good sum of money to make it a reality.

Note: I am using IR in the sense of the final bytecode, and not in the sense of internal intermediate representation of compilers (IR level 1), as they commonly define the IR compiler literature

    
09.02.2014 / 06:24
4

As been quoted , browsers do not by default internally read other languages. But instead, libraries emerge in other javascript languages and frameworks that generate javascript.

A good example of a "translator" library is Bryton , which allows you to use the <script type="text\python3"> tag and the page layout be done entirely and directly in the Python language.

Finally, you can still use languages that are "translated" from frameworks to javascript. Examples of this are ActionScript 3.0 with CreateJS and the new Google language, Dart , which is very reminiscent of the Java language and is intended to be a alternative to JS .

That is, natively supported today, there is no other language that is client-side, but there are several ways to use other languages that you feel more comfortable with than programming in javascript client-side .

    
08.02.2014 / 14:08
2

The main reason is that browsers only understand javascript itself. And neither do they do perfectly, each browser always has a specific quirk.

IE had, I do not know if it still has VBScript, for you to program in Visual Basic. Google is trying new things like NaCl, which allows C code, but this is still restricted to Chrome.

The moral of the story is that in order to have a language interpreted in the browser we need it to be programmed into it, and for all browsers to support it, there needs to be a standardization effort. And only javascript has reached that point to this day.

    
08.02.2014 / 10:29
1

Dart

Google will make your Dart language be interpreted natively by the browser.

In fact, it already does! There is a version of Chromium that already runs directly scripts written in Dart - Dartium .

The trend is that the Dart language will take up a lot of space in a few years.

If other browsers come to support Dart, then their use might be as prominent as today's JavaScript!

At the moment, Dart is "compiled" for JavaScript, that is, you write the program in Dart and the IDE translates to JavaScript , making it a usable solution right now. >

CSS, HTML, XML, XSLT ...

HTML, XML ... the "L" is "Language", that is, language . These are mark-up languages, not programming languages . But, last but not least, these are languages we use in browser , without JavaScript.

Similarly, CSS and XSLT are style-sheet languages that browsers also deal with.

And these are not all the "languages" that both us, developers and browsers can handle in the assembly of web pages and applications on the client side. However, as I said, there are programming languages .

Other Languages

A browser is a type of software that depends on an entire ecosystem. It's no use for a genius to craft a revolutionarily great browser, or even to bring the browser that will actually be used 50 years from now ... nowadays. Such a browser would be useless, as there is no website and no internet page prepared for it.

It's like traveling back in time and taking a television set for 100 or 200 years ago, or more: in what outlet do you turn on the bug? What programs will it capture, whether by antenna, satellite or cable? There is no power grid, no broadcasters: the TV, even if it's 3D, LEDs of the latest generation, is a waste of money.

At the evolutionary stage of IT we are today, the browser , as it is, has a (programming) LANGUAGE, and that language is JavaScript . And that's it. We can analyze and discuss the historical, social, political, economic and technological events of how evolution has gone until we get to this point ... but the fact is this: JavaScript is the language of the internet, the web , client-side, browser, browser . Mobile devices can have their native features ... but everyone will have JavaScript in their browsers .

For this bug that is the browser , today, accept, understand and run C, Ruby, PHP, Python, Perl, COBOL, Pascal, Basic, LOGO, Ada, Haskell and Fortran. well ... honestly ... it's this idea to me that does not make much sense. There could even be some standard web to make that connection ... but providing support for a multitude of built-in languages in the browser is one nonsense. Such a browser would be the heaviest software of all time!

Even if a standard standard is actually established to "connect" other languages installed on the host operating system to the browser ... then only those with the language installed could enjoy them. Nothing so different from what we already have today, with Flash (ActionScript), Java, etc. . That is, either through a plugin or a new standard , the user will need to install support for these other language (s). >

Otherwise, embedding support for them in the browser , as I said before, seems to me obviously unfeasible and absurd, for the simple technical fact of extrapolating the already extrapolated scope of a ... browser . This is how I understand it.

    
09.02.2014 / 01:39
0

Now I'm using Typescript, which allows you to program object-oriented, with typing and other advantages and then it compiles to javascript ensuring compatibility with all browsers so simles and without the need for plugin com flash.

link

Typescript

class Greeter {
    greeting: string;
    constructor(message: string) {
        this.greeting = message;
    }

    greet() {
        return "Hello, " + this.greeting;
    }
}

var greeter = new Greeter("world");

var button = document.createElement('button');
button.textContent = "Say Hello";
button.onclick = function() {
    alert(greeter.greet());
}

document.body.appendChild(button);

Compiled code for Javascript

var Greeter = (function () {
    function Greeter(message) {
        this.greeting = message;
    }
    Greeter.prototype.greet = function () {
        return "Hello, " + this.greeting;
    };
    return Greeter;
})();
var greeter = new Greeter("world");
var button = document.createElement('button');
button.textContent = "Say Hello";
button.onclick = function () {
    alert(greeter.greet());
};
document.body.appendChild(button);
    
17.11.2015 / 16:22