How to use a language other than Javascript in your browser?

Asked

Viewed 1,668 times

10

Despite the enormous plurality of programming languages in various environments (desktop, server, mobile devices), browser continues to support one and only one language: Javascript. The reason for this escapes me: even if there is a compatibility problem (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 or on the server side (eg.: Google Web Toolkit) or client (ex.: 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 feature was abandoned).

Is there any standardized way (or in the process of standardization, à la HTML5) to support other programming languages in the browser, which does not depend on installing plugins (e.g.: Java, Flash, Silverlight)? Preferably something that works exclusively on the client side (like the Processing.js example) without requiring a specific program on the server side (and consequently a round-trip to him whenever a code has to be interpreted).

And if not, is there any known obstacle that makes such a thing impossible? In other words, it is only by lack of interest from suppliers that this occurs, or is there some problem still open that prevents such a thing - whether it is private or depends on consensus among the different major players (standards, browser suppliers, etc)?

5 answers

7


There are some technical impediments that hinder the implementation of a multilingual environment in the browser.

The Javascript language has bindings in the Webkit (for example) which is one of the web Engines, between Runtime c++ and the javascript VM (V8 in the case of Chrome and Javascriptcore in the case of safari)

First of all any alternative language candidate to Javascript, you would need to have a VM also plugged directly into Webkit, with the respective bindings between Runtime c++ and VM Runtime.

Webkit would have to be rewritten to support (in Runtime), two or more VM’s alternating according to user or developer code

The Google Dart project, tried this (and still tries), being possible to use this branch of Chrome, called Dartium.. But it seems there are serious problems with Garbage Collectors due to two or more VM’s having to be loaded in the same process, dividing memory regions.. considerably degrading the performance.

One of the limitations is that the DOM logic is written in C++, and the language VM needs to do quite expensive operations at the efficiency level every time it needs to communicate with the native Runtime in c++; Possibility: rewrite the logic DOM, HTML, SVG, etc. in each language script.. 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 elsewhere :(

There are also compatibility problems:

Imagine, for example, if from 2014 browsers with javascript and Dart are released.. the developers would need to check if the browser supports Dart or another script to from there, resolve to send it or browser.. (but this is also one of the reasons why Dart compiles for Javascript.. 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 this representation.

Two great examples are the java bytecode, 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 asm.js from Mozilla.. but that 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 developers in compilers can implement different languages for the browser (or whoever ships this VM)

Note: IR JVM as well as LLVM have limitations for dynamic languages because they have been designed for the reality of static languages in their design.. The LLVM still produces a bytecode with some non-portable elements with instructions for specific processors.. It is not a "universal IR".

Google’s Pnacl project uses a modified VM LLVM with a proper universal bytecode.. problems: LLVM was made for AOT compilation, so it takes time to compile, because it seeks to produce an extremely optimized final code, unlike VM JIT’s such as V8, Dart and Lua that also look for speed when producing the code.

As seen there is no easy way to this so dreamed platform, even if there is a will to pursue this path, it takes a lot of investment to play a high-level team, for at least 2 years, to leave with an acceptable result

The best option now is to see if the Dart project can be shipped with Chrome, with at least one dual platform.. because for this "universal" platform, it takes a miracle, will and a good sum of money to make it a reality.

Note: I am using IR in the direction of bytecode (retargatable) final, and not in the sense of internal intermediate representation of compilers (IR level 1), as commonly defined by IR in the literature specialized in compilers

  • Thanks, that’s the kind of answer I was looking for. In fact, alternative languages either "compile" for Javascript or are interpreted in Javascript, both strategies with their disadvantages (e.g., poor performance). Now I am better understanding the technical challenges that make it impossible to open up more languages.

5

As cited in that reply, Browsers do not use other languages by default internally. But alternatively, libraries appear in other javascript-based languages and frameworks that generate javascript.

A good example of library "translator" is the Bryton, allowing the use of the tag <script type="text\python3"> and the page programming is done entirely and directly in the Python language.

Finally, it is still possible to use languages that are "translated" from frameworks to javascript. Examples of this are Actionscript 3.0 with Createjs and the new language of Google, Dart, that is very reminiscent of the Java language and aims to be a alternative to the JS.

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

  • 3

    Another interesting initiative is the Emscripten which is a JS backend for the LLVM. It effectively allows Clang to Compile C/C++ in Javascript.

  • Considering that Javascript is performing ever closer to native, by engine optimizations and by extensions like asm.js, it won’t take long for every great programming language to be routinely used in this environment.

2

The main reason is that browsers only understand javascript anyway. And even that they do perfectly, each browser always has a specific peculiarity.

IE had, I don’t 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 to have an interpreted language in the browser we need it to be programmed in it, and for all browsers to support it, there needs to be a standardization effort. And only javascript has reached this point to date.

2

Dart

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

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

The trend is that the Dart language will occupy quite a lot of space within a few years.

If other browsers support Dart then its use may be as prominent as Javascript today!

Dart is currently "compiled" for Javascript, meaning you write the program in Dart and the IDE translates to Javascript, making it a usable solution from now on.


CSS, HTML, XML, XSLT...

HTML, XML... the "L" is "Language", ie, language. Are languages of mark-up, non-languages of programming. But, anyway, these are languages that we use in browser, javascript-free.

Similarly, CSS and XSLT are languages of style-sheet that browsers also handle.

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


Other Languages

A browser is a type of software that depends on an entire ecosystem. No use a genius to devise a browser revolutionarily great, or even bring the real browser which will be effectively used 50 years from now... to the present day. Such browser would be useless, because there is no website or web page prepared for it.

It’s like traveling through time and taking a television set to 100 or 200 years ago, or more: in which outlet turn on the bug? What programs will it capture, whether by antenna, satellite or cable? There is no electricity network, no stations: the television set, even if it is 3D, LED of last generation, is a useless traste.

In the evolutionary point of IT that we are today, the browser, as it is, it has A (programming) LANGUAGE, and that language is the Javascript. And that’s the end of it. We can analyze and discuss the historical, social, political, economic and technological events of how the evolution took place up to this point... but the fact is this: Javascript is the language of the internet, the web, the client-side, the browser, the browser. Mobile devices can have their native resources... but everyone will have the Javascript in their browsers.

To this animal 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 doesn’t make much sense. There might even be some standard web to make this connection... but provide support for a multitude of languages built-in in the browser is a nonsense. Such browser would be the software heaviest of all time!

Even if a standard to "connect" other languages installed in the host operating system to the browser... then only those who have the language installed could enjoy it. Nothing so different than what we already have today, with Flash (Actionscript), Java, etc.. You mean, through a plugin or a new standard, the user will need to install support for that other language(s) (s).

Otherwise, embed the support into the browser, as I have already said, it seems to me evidently impracticable and absurd, for the simple technical fact of extrapolating the already extrapolated scope of a... browser. That’s how I understand it.

  • 1

    Although XSLT sometimes even seems like programming... :-)

0

Today I’m using Typescript, which allows object-oriented programming, with typing and other advantages and then it compiles for javascript thus ensuring compatibility with all browser simles and without the need for plugin with flash.

http://www.typescriptlang.org/

Code in 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);
  • 1

    Thank you for the answer! However, from what I understand Typescript is compiled on the server and then the resulting Javascript is sent to the client, right? In this question I sought to know the state of support for other languages in itself browser, without the need for JS translation on the server side. Many compilers translate X to Javascript, but that’s a bit different than "run X on browser" rsrs!

  • 1

    In fact Typescript is copied in the editor itself, it does not need a server, depending on the editor this compilation is very transparent but the end result is the traditional javascript.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.