why not just import new language into browser?

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

why not just import new language into browser?

李白|字一日
hi, all

after es6 was drafted for a long time, i don't see any advantages from
these changes.

the import syntax is no better than require('module') or
require(['sss'], function() {});

and the import of class is no need for frontend developement.
the import of classes will lead to the demand of packages or namespaces.
all this only to polute the simplicity javascript has today.
And no good to the javascript developement .

I would like to suggest a language neutro interface for all languages
inside all 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.

javascript may not be the only language to the browser side.
but other languages can be freely imported.

thanks.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

Edwin Reynoso
Lol "you" don't see the advantages, yet most do (including me). Why wouldn't we improve the language itself. So just leave the language alone like that, and let's focus on using plugins for other languages to work?? really?? and then we'll have to put in work into updating and fixing bugs on those plugins, which IMO is just more work for nothing. If you don't like javascript (well then I'm sorry but that's your problem). And what about all the work done for ES6, and ES7, ES8.. and on, what just goes to the trash?

Idk man I don't agree.

On Mon, May 25, 2015 at 11:13 PM, eric <[hidden email]> wrote:
hi, all

after es6 was drafted for a long time, i don't see any advantages from these changes.

the import syntax is no better than require('module') or require(['sss'], function() {});

and the import of class is no need for frontend developement.
the import of classes will lead to the demand of packages or namespaces.
all this only to polute the simplicity javascript has today.
And no good to the javascript developement .

I would like to suggest a language neutro interface for all languages inside all 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.

javascript may not be the only language to the browser side.
but other languages can be freely imported.

thanks.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

Michiel Sikma
In reply to this post by 李白|字一日

2015-05-26 4:13 GMT+01:00 eric <[hidden email]>:

and the import of class is no need for frontend developement.
the import of classes will lead to the demand of packages or namespaces.
all this only to polute the simplicity javascript has today.
And no good to the javascript developement .

thanks

The import syntax is optional, so there's no need to use it. The same goes for any other changes to JS. You'll likely never need to worry about your code breaking, ever.
I don't think there's a need to discuss the concept of importing code, but I just wanted to note that you're free to stick with ES5 or earlier principles if you so desire.

Regards,
Michiel

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

Matthew Robb
In reply to this post by 李白|字一日

On Mon, May 25, 2015 at 11:13 PM, eric <[hidden email]> wrote:
I would like to suggest a language neutro interface for all languages inside all browsers.

​I hate to be the broken record guy but I guess on these lists we're bound to see new people come in all the time and needing old answers. Javascript IS the neutral interface for all languages.




- Matthew Robb

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

李白|字一日


在 15/5/26 20:46, Matthew Robb 写道:

On Mon, May 25, 2015 at 11:13 PM, eric <[hidden email]> wrote:
I would like to suggest a language neutro interface for all languages inside all browsers.

​I hate to be the broken record guy but I guess on these lists we're bound to see new people come in all the time and needing old answers. Javascript IS the neutral interface for all languages.




- Matthew Robb
I hate to be misunderstood and mislead one question to another.

javascript can be a neutral language for those who want to be compiled to javascript.

but it is a language.

C++ can be compiled to C too.
no one would say C is a neutral language interface.

Such misleading is what I hate most.

I think the booming of frontend programming will lead to the booming of the frontend projects.
and therefore the booming of programmers from various backgrounds.

so javascript certainly can not meet all the needs to those programmers.

the change of ES6, ES7 shows this trend.

It is time for browsers to move forward not to just change the javascript where it is but to introduce more languages both compilable (for efficiency) or scriptable.

the key job for javascript is to handle the dom which is defined by w3c specification and it's related events.
simply put BOM, DOM.

formerly there was vbscript which did the same job as javascript.

today it is the time for the browser side languages to boom.

in this way, javascript remains untained and programmers from various backgrounds can be easily turned into frontend programmers without uncomfortableness.

the translation of languages into javascript or the evolving of ecma version will do no good in this new trend.

but only get frustrated both by former javascript programmers and newbies from other languages.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

Matthew Robb

On Tue, May 26, 2015 at 12:22 PM, eric <[hidden email]> wrote:
C++ can be compiled to C too.
no one would say C is a neutral language interface.

​I'm sorry to tell you but the overwhelming trend within browsers is not in favor of what you are proposing. C++ compiles to Javascript and is VERY fast in that form.​
See: http://emscripten.org and http://asmjs.org/

If you don't think it will "catch on" then you should try to get more informed on the subject.




- Matthew Robb

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

李白|字一日
You are always misleading.

what you've listed just show that the trend is real and urgent.

but you choose to ignore it and mislead it.

why asm.js ? because there is no support for c++/c from browsers.
what if the browsers support c++/c navtively?

by
<script language="c" src="http://code.site.com/abc.o">
</script>
which will run faster than asm.js.
do we need asm.js then?

if browser natively support languages like c, c++, python, ruby.
then veryone can be a full stack programmer,



在 15/5/27 00:35, Matthew Robb 写道:

On Tue, May 26, 2015 at 12:22 PM, eric <[hidden email]> wrote:
C++ can be compiled to C too.
no one would say C is a neutral language interface.

​I'm sorry to tell you but the overwhelming trend within browsers is not in favor of what you are proposing. C++ compiles to Javascript and is VERY fast in that form.​
See: http://emscripten.org and http://asmjs.org/

If you don't think it will "catch on" then you should try to get more informed on the subject.




- Matthew Robb


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

Andrea Giammarchi-2
then veryone can be a full stack programmer

I had a genuine laugh there ... it's like sayiing since JS runs on server, micro-controllers, and IndexedDB is a thing, everyone now is a full stack developer that could do server too.

Please do not merge these two very different topics ... if you know Python or C you won't move a single step forward on the Web and DOM. Different environments, problems, worlds, different everything ... you function validates an email? Good, how about everything else that could go wrong or is simply different?

Anyway, this is the development-toolchain era so if Google Dart is fine abandoning an alternative engine for its own browser and simply trust transpiling to JS, why wouldn't any other "different language" lover do the same?

It's also the era where everyone cannot wait for any sort of plugin to die due any sort of related problem ( looking at you Silverlight DRM streaming on Linux ) so regardless I agree there are cases where we'd like to have pure/native "other language" running on the browser (e.g. see also WebGL and GLES indirections) I don't think having the equivalent of LLVM interfaces for any sort of PL would bring any real-world benefit to the Web ... see, again and indeed, Emscripten to asm.js results

Regards


On Tue, May 26, 2015 at 6:18 PM, eric <[hidden email]> wrote:
You are always misleading.

what you've listed just show that the trend is real and urgent.

but you choose to ignore it and mislead it.

why asm.js ? because there is no support for c++/c from browsers.
what if the browsers support c++/c navtively?

by
<script language="c" src="http://code.site.com/abc.o">
</script>
which will run faster than asm.js.
do we need asm.js then?

if browser natively support languages like c, c++, python, ruby.
then veryone can be a full stack programmer,



在 15/5/27 00:35, Matthew Robb 写道:

On Tue, May 26, 2015 at 12:22 PM, eric <[hidden email]> wrote:
C++ can be compiled to C too.
no one would say C is a neutral language interface.

​I'm sorry to tell you but the overwhelming trend within browsers is not in favor of what you are proposing. C++ compiles to Javascript and is VERY fast in that form.​
See: http://emscripten.org and http://asmjs.org/

If you don't think it will "catch on" then you should try to get more informed on the subject.




- Matthew Robb


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

李白|字一日

Programmers are always facing different environments or problems.
the differences between frontend and backend or the database or os kernel are minor to talented programmers.
You are laugh at yourself.

Abandoning dart doesn't mean that the way is wrong,  maybe only the timing is not proper.

And finally is a netro language interface is not a plugin.

an era of browser as a platform will surely come:-)


在 15/5/27 01:43, Andrea Giammarchi 写道:
then veryone can be a full stack programmer

I had a genuine laugh there ... it's like sayiing since JS runs on server, micro-controllers, and IndexedDB is a thing, everyone now is a full stack developer that could do server too.

Please do not merge these two very different topics ... if you know Python or C you won't move a single step forward on the Web and DOM. Different environments, problems, worlds, different everything ... you function validates an email? Good, how about everything else that could go wrong or is simply different?

Anyway, this is the development-toolchain era so if Google Dart is fine abandoning an alternative engine for its own browser and simply trust transpiling to JS, why wouldn't any other "different language" lover do the same?

It's also the era where everyone cannot wait for any sort of plugin to die due any sort of related problem ( looking at you Silverlight DRM streaming on Linux ) so regardless I agree there are cases where we'd like to have pure/native "other language" running on the browser (e.g. see also WebGL and GLES indirections) I don't think having the equivalent of LLVM interfaces for any sort of PL would bring any real-world benefit to the Web ... see, again and indeed, Emscripten to asm.js results

Regards


On Tue, May 26, 2015 at 6:18 PM, eric <[hidden email]> wrote:
You are always misleading.

what you've listed just show that the trend is real and urgent.

but you choose to ignore it and mislead it.

why asm.js ? because there is no support for c++/c from browsers.
what if the browsers support c++/c navtively?

by
<script language="c" src="http://code.site.com/abc.o">
</script>
which will run faster than asm.js.
do we need asm.js then?

if browser natively support languages like c, c++, python, ruby.
then veryone can be a full stack programmer,



在 15/5/27 00:35, Matthew Robb 写道:

On Tue, May 26, 2015 at 12:22 PM, eric <[hidden email]> wrote:
C++ can be compiled to C too.
no one would say C is a neutral language interface.

​I'm sorry to tell you but the overwhelming trend within browsers is not in favor of what you are proposing. C++ compiles to Javascript and is VERY fast in that form.​
See: http://emscripten.org and http://asmjs.org/

If you don't think it will "catch on" then you should try to get more informed on the subject.




- Matthew Robb


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

Andrea Giammarchi-2
the differences between frontend and backend or the database or os kernel are minor to talented programmers.

nope


an era of browser as a platform will surely come:-)

not sure what you mean, have a look at FirefoxOS


Anyway, I'm done here, so probably should you


On Tue, May 26, 2015 at 7:02 PM, eric <[hidden email]> wrote:

Programmers are always facing different environments or problems.
the differences between frontend and backend or the database or os kernel are minor to talented programmers.
You are laugh at yourself.

Abandoning dart doesn't mean that the way is wrong,  maybe only the timing is not proper.

And finally is a netro language interface is not a plugin.

an era of browser as a platform will surely come:-)


在 15/5/27 01:43, Andrea Giammarchi 写道:
then veryone can be a full stack programmer

I had a genuine laugh there ... it's like sayiing since JS runs on server, micro-controllers, and IndexedDB is a thing, everyone now is a full stack developer that could do server too.

Please do not merge these two very different topics ... if you know Python or C you won't move a single step forward on the Web and DOM. Different environments, problems, worlds, different everything ... you function validates an email? Good, how about everything else that could go wrong or is simply different?

Anyway, this is the development-toolchain era so if Google Dart is fine abandoning an alternative engine for its own browser and simply trust transpiling to JS, why wouldn't any other "different language" lover do the same?

It's also the era where everyone cannot wait for any sort of plugin to die due any sort of related problem ( looking at you Silverlight DRM streaming on Linux ) so regardless I agree there are cases where we'd like to have pure/native "other language" running on the browser (e.g. see also WebGL and GLES indirections) I don't think having the equivalent of LLVM interfaces for any sort of PL would bring any real-world benefit to the Web ... see, again and indeed, Emscripten to asm.js results

Regards


On Tue, May 26, 2015 at 6:18 PM, eric <[hidden email]> wrote:
You are always misleading.

what you've listed just show that the trend is real and urgent.

but you choose to ignore it and mislead it.

why asm.js ? because there is no support for c++/c from browsers.
what if the browsers support c++/c navtively?

by
<script language="c" src="http://code.site.com/abc.o">
</script>
which will run faster than asm.js.
do we need asm.js then?

if browser natively support languages like c, c++, python, ruby.
then veryone can be a full stack programmer,



在 15/5/27 00:35, Matthew Robb 写道:

On Tue, May 26, 2015 at 12:22 PM, eric <[hidden email]> wrote:
C++ can be compiled to C too.
no one would say C is a neutral language interface.

​I'm sorry to tell you but the overwhelming trend within browsers is not in favor of what you are proposing. C++ compiles to Javascript and is VERY fast in that form.​
See: http://emscripten.org and http://asmjs.org/

If you don't think it will "catch on" then you should try to get more informed on the subject.




- Matthew Robb


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

段垚
In reply to this post by 李白|字一日
在 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++.

>
> 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.

(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?

[1] https://bitbucket.org/xilium/xilium.cefglue/
[2] https://bitbucket.org/geckofx

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

Michiel Sikma
In reply to this post by 李白|字一日
2015-05-26 18:18 GMT+01:00 eric <[hidden email]>:
why asm.js ? because there is no support for c++/c from browsers.
what if the browsers support c++/c navtively?

by
<script language="c" src="http://code.site.com/abc.o">
</script>
which will run faster than asm.js.
do we need asm.js then?


The security implications alone make this an extremely bad idea.

Additionally, there's just no point. JS (V8/SpiderMonkey) are extremely fast, to my knowledge only LuaJIT is faster among interpreted languages. The language itself has undergone a major evolution and is very solid now, and improving continuously. When you look at what makes sites slow, it's virtually always poor DOM management or other things that aren't really inherent language problems.

Michiel 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

李白|字一日
In reply to this post by 段垚


2015-05-27 2:18 GMT+08:00 duanyao <[hidden email]>:
在 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

Thaddee Tyl
On Wed, May 27, 2015 at 5:01 PM, 李白|字一日 <[hidden email]> wrote:
> Web Api, Native Client are all the efforts made to make the browser side to
> be a platform other than HTML + CSS + JAVASCRIT Parser.

Web API (by which I assume you mean the APIs defined in the W3C and
WHATWG standards) is definitely not an effort made to make the browser
side to be a platform other than HTML + CSS + JS.

> obviously client side languages should be subsetted and provided limited
> accesses to the browsers.

If you really believe that, prove that it is practical and does not
incur a performance hit by implementing it on your choice of
open-source browser.

Everyone seems to believe otherwise. DOM bindings are tricky enough as
they stand, they have been heavily optimized by every browser, and
they won't want to see all that work flushed so that browsers can
finally start having new kinds of incompatibilities.
“Hey, I built this page in Python! It is Chrome-only, because only
Chrome implemented the VM-DOM bridge of my dreams. Also, running the
very same code in PythonJS is faster on other browsers, partially
because they didn't complicate their DOM bindings, partially because
JS engines are freakishly fast:
<http://2.bp.blogspot.com/-pylzspKRu6M/UqbAv3qIGTI/AAAAAAAAAkE/NnsAM5DZ_8M/s400/nbody.png>.”

There is no point in caring about what language browsers provide,
because they indirectly support any. You want to write it in C++?
Please do; there's a compiler for that, it's called Emscripten. It
uses sourcemaps so that your debugger shows your C++ source code, just
like gcc/gdb uses DWARF on ELF assembly.

What you want is already there, you simply have wrong assumptions
about what is there.

> the aim is to make DOM manipulating more easier for other languages.

Any compiler can offer that. Cheerp has that. Dart2js has that.
Scala.js has that.

> especially for mobile applications where fast speed needs badly.

Then don't make DOM bindings slower by requiring multiple VMs. Like I
said, I would be very surprised if you could make things faster than
an optimized asm.js output by somehow adding the ability to run
multiple VMs in a browser.

> the javascript engine can be… downloaded from the internet

Why are you only suggesting things that would make webapps slower, if
what bothers you is speed?
(Also, do you really want any webpage to be able to install malware
instantly? How would the browser see the difference between a JS
engine and malware hidden in a JS engine?)
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

Brendan Eich-2
I would like to suggest that everyone let this thread die. It's way out
of scope for es-discuss, and three kinds of bogus just considering the
Subject: line. If anyone wants to chat about it, HN has regular
recurring "why not blub?" and "why not bytecode" threads.

/be (co-moderator with @awbjs)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

段垚
In reply to this post by 李白|字一日
在 2015年05月27日 23:01, 李白|字一日 写道:


2015-05-27 2:18 GMT+08:00 duanyao <[hidden email]>:
在 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.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

李白|字一日


在 15/5/28 02:04, duanyao 写道:
在 2015年05月27日 23:01, 李白|字一日 写道:


2015-05-27 2:18 GMT+08:00 duanyao <[hidden email]>:
在 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.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why not just import new language into browser?

李白|字一日
In reply to this post by Matthew Robb
I would be very happy to know that the web assembly standard answers my question.
thanks you to all of those who understand my request and make progress for it.

2015-05-27 0:35 GMT+08:00 Matthew Robb <[hidden email]>:

On Tue, May 26, 2015 at 12:22 PM, eric <[hidden email]> wrote:
C++ can be compiled to C too.
no one would say C is a neutral language interface.

​I'm sorry to tell you but the overwhelming trend within browsers is not in favor of what you are proposing. C++ compiles to Javascript and is VERY fast in that form.​
See: http://emscripten.org and http://asmjs.org/

If you don't think it will "catch on" then you should try to get more informed on the subject.




- Matthew Robb


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss