nu23

Thanks for the recommendation, I just started reading the book and really liked the initial parts. The author has a very good discussion of how a result in sociolgy is obvious, and it's opposite is equally obvious which leads people to undervalue the findings in studies.

I guess I was wrong when I said every browser innovation. I also, more or less, agree with your other points - my goal wasn't to bash HTMLWG but to point out that the standardization of a lower level api will help us skip some of the other parts of the standards process by allowing us to do things like compile an sql library directly. Design is indeed hard, but with people free to implement different alternatives, it can happen in a distributed way with more possibilities explored even in production systems. Of course, something as basic as a module system should definitely have a standard. Which would also lead me to agree with your comment on scheme standardization while noting that some of the experiments with first class environments and f-expressions seem to be a genuine exploration a new part of the design space and not a gratuitous incompatibility, but maybe the standardization process should ignore them for the time being.

OK, Thanks for clarifying. Again, my purpose is not defending NaCl and if this can be done by making JS a better target or by a translator from another VM, that's great, and I hope these projects succeed. And these are worth trying even when the OSes have incompatible workalikes, precisely because they are incompatible. Thanks again for all your work on JS and the open web.

I agree with what you are saying in the beginning - We definitely need a proper standard and not a single company having design control. I am not so much defending the way Google is going about it, but rather the value of something which plays the essentially same role.

Ideally, I would like the web developer to have as much freedom as a developer for a native application - the freedom to choose a programming language and the ability to compile to a reasonably low level target for performance while still being cross-platform. Now, this somehow needs to be done without the security nightmares of ActiveX plugins. (Though, I dont see the non-security problems with a bunch of shared libraries stored on the browser. This is essentially what the OS does, and my goal is to replace the OS with the browser. Bandwidth will probably improve so that downloading libraries shouldn't be a problem and if not, the web site maintainer can still choose not to develop in a large library environment The popular ones will be cached in any case.)

You seem to be saying that the technical difficulties of doing this in a well-specified (memory and control-flow), secure and cross-platform way are intractable. Maybe this can be solved by moving the VM to a more abstract level.

Responding to your comment about NaCl, I just wanted to point out something, not contradicting what you said, but emphasizing the motivation for the other side. We are right now in a situation where every significant browser innovation has to move through a very slow process on a timescale of years. And these are the succesful features not blocked by vendor politics. Also, features which are not of widespread interest, (say I want to try web programming in a new just invented language), dont even come up in discussion, due to limited resources of the standardization process. We would ideally want to be in the position similar to lisp where innovations even in fundamental areas like object systems dont have to wait for a committee before being used in production systems, as opposed to something like the Java standardization process.

Now, NaCl may not be ideal for the various reasons you list. But something similar to it, when it becomes standardized, will lead to much faster innovation. Things which were previously held up in standards committees can then happen on the fly. In the spirit of Scheme, browser standardization can progress not library by library, but by removing the obstacles which prevent programmers from implementing libraries themselves. For this reason, I submit, that this should be one of the important goals of a web browser implementor, and maybe even worth a few compromises(not compromising cross-platform standardization, of course - the single greatest thing about javascript is that it freed us from the win32 api).