Re: why not just import new language into browser?

[李白|字一日]

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 :

>
> On Tue, May 26, 2015 at 12:22 PM, eric  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.
>
>
> https://blogs.windows.com/msedgedev/2015/05/07/bringing-asm-js-to-chakra-microsoft-edge/
>
> ​Finally: http://alwaysbetonjs.com​
>
>
> - Matthew Robb
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: 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 >:


在 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 

Re: why not just import new language into browser?

[duanyao]

在 2015年05月27日 23:01, 李白|字一日 写道:



2015-05-27 2:18 GMT+08:00 duanyao >:


在 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 th

Re: why not just import new language into browser?

[Brendan Eich]

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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[Thaddee Tyl]

On Wed, May 27, 2015 at 5:01 PM, 李白|字一日  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:
.”

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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[李白|字一日]

2015-05-27 2:18 GMT+08:00 duanyao :

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

Re: why not just import new language into browser?

[Michiel Sikma]

2015-05-26 18:18 GMT+01:00 eric :
>
> why asm.js ? because there is no support for c++/c from browsers.
> what if the browsers support c++/c navtively?
>
> by
> http://code.site.com/abc.o";
> <http://code.site.com/abc.o>>
> 
> 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[duanyao]

在 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[Andrea Giammarchi]

> 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  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  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
>> http://code.site.com/abc.o";
>> <http://code.site.com/abc.o>>
>> 
>> 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  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.
>>
>>
>> https://blogs.windows.com/msedgedev/2015/05/07/bringing-asm-js-to-chakra-microsoft-edge/
>>
>> ​Finally: http://alwaysbetonjs.com​
>>
>>
>>  - Matthew Robb
>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[eric]

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 > 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
http://code.site.com/abc.o";
<http://code.site.com/abc.o>>

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 mailto:calid...@gmail.com>> 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.


https://blogs.windows.com/msedgedev/2015/05/07/bringing-asm-js-to-chakra-microsoft-edge/

​Finally: http://alwaysbetonjs.com​


- Matthew Robb



___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[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  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
> http://code.site.com/abc.o";
> <http://code.site.com/abc.o>>
> 
> 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  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.
>
>
> https://blogs.windows.com/msedgedev/2015/05/07/bringing-asm-js-to-chakra-microsoft-edge/
>
> ​Finally: http://alwaysbetonjs.com​
>
>
>  - Matthew Robb
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[eric]

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
http://code.site.com/abc.o";>

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


https://blogs.windows.com/msedgedev/2015/05/07/bringing-asm-js-to-chakra-microsoft-edge/

​Finally: http://alwaysbetonjs.com​


- Matthew Robb


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[Matthew Robb]

On Tue, May 26, 2015 at 12:22 PM, eric  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.

https://blogs.windows.com/msedgedev/2015/05/07/bringing-asm-js-to-chakra-microsoft-edge/

​Finally: http://alwaysbetonjs.com​


- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[eric]

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


On Mon, May 25, 2015 at 11:13 PM, eric > 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.


See 
https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS 
​




- 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[Matthew Robb]

On Mon, May 25, 2015 at 11:13 PM, eric  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.

See
https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS
​



- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[Michiel Sikma]

2015-05-26 4:13 GMT+01:00 eric :
>
>
> 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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  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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss