why not just import new language into browser?

[duanyao]

在 2015年05月27日 23:01, 李白|字一日 写道:
>
>
> 2015-05-27 2:18 GMT+08:00 duanyao <duanyao at ustc.edu 
> <mailto:duanyao at ustc.edu>>:
>
>     在 2015年05月26日 11:13, eric 写道:
>
>         I would like to suggest a language neutro interface for all
>         languages inside all browsers.
>
>     Web APIs are defined in WebIDL, which is language neutro. However
>     I don't think the implementations of those APIs in browsers can be
>     acutually "language neutro".
>     Most browsers are implemented in C++, so they can provide C/C++
>     APIs in addition to JS APIs. But if you want to support other
>     languages, you'll have to write wrappers around C/C++ APIs, and
>     these are non-trival efforts (checkout cefglue[1] and geckofx[2]).
>     Additionally, for security and portability reasons, browsers can't
>     expose Web APIs to web pages via unmanaged C/C++.
>
>
> Web Api, Native Client are all the efforts made to make the browser 
> side to be a platform other than HTML + CSS + JAVASCRIT Parser.
>
> obviously client side languages should be subsetted and provided 
> limited accesses to the browsers.

If other languages in browsers are also managed and CPU/OS neutro, they 
will have very little advantages over "compile to JS (espacially 
asm.js)" solutions.
This is why Dart VM and Portable Native Client can't gain much adoption.

>
>
>         so the browsers will support all languages by plugin instead
>         of changing javascript into an evil language.
>         and the rest of programmers will use there languages freely.
>
>     What do you mean by "plugin"? ActiveX? NPAPI? PPAPI? NativeClient?
>     or something new?
>
>     Supporting languages except JS natively were tried (C/C++ via
>     ActiveX and NPAPI, VBScript, Java Applet, Flash, and Silverlight),
>     but all failed or are failing. Why?
>
>     (1) Security. ActiveX and NPAPI are proven to be insecure.
>     Althrough newer plugin architectures like PPAPI are safer, but are
>     not as safe as no plugin at all.
>
>
> that is why a neutro language interface is important.
"Important" things are not always feasible to implement. How a 
"language-neutro interface" looks like? Do you have an idea on how to 
implement it in some browser engines? I don't.

> plugin here means even when we defined the language neutro interface, 
> we still need many plugins to be developed by various language supporters.
>
> the easiest one would be javascript interface.
> because it is implemented now.
>
> but others should be able to be developed one by one if the interface 
> is open and the packaging and importing problem the javascript has now 
> will disappear.
> because all the languages can use their importing or packing mechanism 
> before compiled into a browser executable file.
>
> this plugin is just a way to extend the language options for browsers. 
> not like activeX and NPAPI, etc.

Please describe what the plugins look like, not what the plugins are not 
like.

>
> the aim is to make DOM manipulating more easier for other languages.
>
> especially for mobile applications where fast speed needs badly.

There is not guarantee that other languages can be faster than JS; they 
are more likely slower than highly optimized JS engines.

>
>     (2) Complexity. Browsers are unwilling to duplicate works if some
>     features are already availible via JS.
>
>
>
> the separating of javascript from browser will make it more simple and 
> extensible.
Obviously, browser developers disagree.  Blink removed JavaScriptCore, 
Webkit removed V8, and MS Edge removed VBScript.

>
> the javascript engine can be replaced. and can be downloaded from the 
> internet.
> the client users can be more delighted to download various fast 
> javascript engines or engines of other languages.
>
> HTML file can have a default engine url for browsers to download.
Won't work. JS(or other languages) engines are native codes and not 
portable, so there is no guarantee that a suitable engine is availble to 
every CPU/OS/Browser combination.
>
>
>     (3) Portability. Native codes and most plugins are not portable
>     across CPU or OS, this is unacceptable for most web apps. Portable
>     NativeClient is an exception, but it doen't show significant
>     advantages over asm.js.
>
>
> won't have this problem. the plugin is no more than an interface.
Yes. As you decribed above, the plugin must contain a complete language 
engine. If not, how those languages are executed?
>
>
>     (4) Maintainability. Who are supposed to maintain those plugins of
>     additional languages in browsers? Even some big companies are
>     unwilling to maintain plugins for some platforms. For example, MS
>     never implemented Silverlight on non-windows platforms and will
>     drop it in Edge browser; Adobe had discontinued Flash for android
>     and linux. Who want to use a language that is not guaranteed to
>     work in future?
>
>
> asm.js  is a way to make this happen in the mask of javascript.
Compiled asm.js code will run as long as browsers continue to support 
JS; the tool chains of asm.js are simiple to implement and are 
open-sourced (emscripten).
But this is not true for plugin-based solutions(espacially propertitary 
ones) -- if the plugin's vendor decides to quit, browser vendors and web 
developers can do very little.
>
> so the efforts made in es6,7 will be found useless.
They are very useful to many devepolers.
>
>
>     [1] https://bitbucket.org/xilium/xilium.cefglue/
>     [2] https://bitbucket.org/geckofx
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150528/0e0db74d/attachment-0001.html>