why not just import new language into browser?

Thaddee Tyl thaddee.tyl at gmail.com
Wed May 27 16:11:19 UTC 2015

On Wed, May 27, 2015 at 5:01 PM, 李白|字一日 <calidion at gmail.com> wrote:
> Web Api, Native Client are all the efforts made to make the browser side to
> be a platform other than HTML + CSS + JAVASCRIT Parser.

Web API (by which I assume you mean the APIs defined in the W3C and
WHATWG standards) is definitely not an effort made to make the browser
side to be a platform other than HTML + CSS + JS.

> obviously client side languages should be subsetted and provided limited
> accesses to the browsers.

If you really believe that, prove that it is practical and does not
incur a performance hit by implementing it on your choice of
open-source browser.

Everyone seems to believe otherwise. DOM bindings are tricky enough as
they stand, they have been heavily optimized by every browser, and
they won't want to see all that work flushed so that browsers can
finally start having new kinds of incompatibilities.
“Hey, I built this page in Python! It is Chrome-only, because only
Chrome implemented the VM-DOM bridge of my dreams. Also, running the
very same code in PythonJS is faster on other browsers, partially
because they didn't complicate their DOM bindings, partially because
JS engines are freakishly fast:

There is no point in caring about what language browsers provide,
because they indirectly support any. You want to write it in C++?
Please do; there's a compiler for that, it's called Emscripten. It
uses sourcemaps so that your debugger shows your C++ source code, just
like gcc/gdb uses DWARF on ELF assembly.

What you want is already there, you simply have wrong assumptions
about what is there.

> the aim is to make DOM manipulating more easier for other languages.

Any compiler can offer that. Cheerp has that. Dart2js has that.
Scala.js has that.

> especially for mobile applications where fast speed needs badly.

Then don't make DOM bindings slower by requiring multiple VMs. Like I
said, I would be very surprised if you could make things faster than
an optimized asm.js output by somehow adding the ability to run
multiple VMs in a browser.

> the javascript engine can be… downloaded from the internet

Why are you only suggesting things that would make webapps slower, if
what bothers you is speed?
(Also, do you really want any webpage to be able to install malware
instantly? How would the browser see the difference between a JS
engine and malware hidden in a JS engine?)

More information about the es-discuss mailing list