在 15/5/28 02:04, duanyao 写道:
在 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.
that is why i would say that asm.js is on the way to this.
if the interface is opened to other language, any lanuage can be parsed
in browser.
browsers need no much work to make it happen.
just open current apis for dom manipulation that javascript use today to
more languages and set a way to load them.
the changes in es6, es6 to the javascript will be shadowed.
the code needs no minification or obfuscation anymore.
one advantange is enough. that is programmers can benefit from their
best familliar language.
no more advantages needed.
languages should always be replaced by better ones if it needs great
changes both technologically and commercially.
ES6, ES7 have shown that.
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.
It is no need that other language are faster.
(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
