why not just import new language into browser?
duanyao at ustc.edu
Wed May 27 18:04:39 UTC 2015
在 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 and geckofx).
> 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
This is why Dart VM and Portable Native Client can't gain much adoption.
> so the browsers will support all languages by plugin instead
> 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.
> because it is implemented now.
> but others should be able to be developed one by one if the interface
> 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
> 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.
Webkit removed V8, and MS Edge removed VBScript.
> the client users can be more delighted to download various fast
> 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?
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
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.
>  https://bitbucket.org/xilium/xilium.cefglue/
>  https://bitbucket.org/geckofx
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss