why not just import new language into browser?
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.
2015-05-26 4:13 GMT+01:00 eric <calidion at gmail.com>:
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.
, Michiel
On Mon, May 25, 2015 at 11:13 PM, eric <calidion at gmail.com> 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 jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS
- Matthew Robb
在 15/5/26 20:46, Matthew Robb 写道:
On Mon, May 25, 2015 at 11:13 PM, eric <calidion at gmail.com <mailto:calidion at gmail.com>> 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 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.
On Tue, May 26, 2015 at 12:22 PM, eric <calidion at 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: emscripten.org and asmjs.org
If you don't think it will "catch on" then you should try to get more informed on the subject.
blogs.windows.com/msedgedev/2015/05/07/bringing-asm-js-to-chakra-microsoft-edge
Finally: alwaysbetonjs.com
- Matthew Robb
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="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 写道:
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
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 写道:
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
在 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] bitbucket.org/xilium/xilium.cefglue [2] bitbucket.org/geckofx
2015-05-26 18:18 GMT+01:00 eric <calidion at gmail.com>:
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="code.site.com/abc.o" 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
2015-05-27 2:18 GMT+08:00 duanyao <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.
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.
On Wed, May 27, 2015 at 5:01 PM, 李白|字一日 <calidion at gmail.com> 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: 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?)
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)
在 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.
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.
在 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.
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')orrequire(['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.
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.