On Wed, May 27, 2015 at 5:01 PM, 李白|字一日 <calid...@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: <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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
