2015-05-27 2:18 GMT+08:00 duanyao <duan...@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. > >> 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. 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. the aim is to make DOM manipulating more easier for other languages. especially for mobile applications where fast speed needs badly. > (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. 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. > > (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. > > (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. so the efforts made in es6,7 will be found useless. > [1] https://bitbucket.org/xilium/xilium.cefglue/ > [2] https://bitbucket.org/geckofx > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
