why not just import new language into browser?
duanyao at ustc.edu
Tue May 26 18:18:23 UTC 2015
在 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
> so the browsers will support all languages by plugin instead of
> and the rest of programmers will use there languages freely.
What do you mean by "plugin"? ActiveX? NPAPI? PPAPI? NativeClient? or
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.
(2) Complexity. Browsers are unwilling to duplicate works if some
features are already availible via JS.
(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.
(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?
More information about the es-discuss