why not just import new language into browser?

[eric]

在 15/5/28 02:04, duanyao 写道:
> 在 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[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
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150529/ea6f02bb/attachment.html>