在 2015年05月27日 23:01, 李白|字一日 写道:
2015-05-27 2:18 GMT+08:00 duanyao <duan...@ustc.edu
<mailto: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.
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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
