The nice thing is that Alan Kay's call for the Web browser to be refounded on (effectively) something like NaCl + WebGL and Tim Berners-Lee's embrace of what he called the Principle of Least Power http://www.w3.org/DesignIssues/Principles.html are both correct, and they can both be adhered to at the same time. Thesis, antithesis, synthesis. Declarative formats are a Good Thing for the reasons you mention, but it's not necessary or desirable to weld the code needed to interpret them into the browser. As it stands, the web browser is a half-hearted attempt at a dedicated reader for one particular declarative format, which has been worked up into a messy approximation to a generic application runtime. Much better to start with the generic runtime and write for it programs to handle (view, edit, inspect etc.) various different declarative formats. When it's told to open a file that's in a declarative, non-executable format, the browser can (by default) find and run a generic display program for files of that type.
I'm not arguing for the status quo, I just think the OP throws the baby out with the bathwater. The pivotal question is where does this code come from?
If I've got a "page" that displays an image, how is the code to display that image specified? In lisp terminology, does that reference involve a relatively opaque gensym that is bound (by the page) to the code to interpret it? Or does the page instead include a well-known semantically meaningful unbound symbol, which is then interpreted by my software stack as referencing code that is administered by my package manager?
There's certainly a continuum between the two, but everything in the OP strikes me as arguing for the opaque and locally bound symbol, at the expense of control by the end-user.
> The pivotal question is where does this code come from? [...] If I've got a "page" that displays an image, how is the code to display that image specified?
Here's a quick-and-dirty outline of how it could work. The webclient has a local map of file associations from a given file type to a generic-runtime display program for files of that type, specified by a URL (or maybe a URI). When the webclient has to determine the default display program for a particular file it is loading, it first looks up the local table. (Obviously the default action for a file which is itself a generic-runtime executable is to run it directly.) If there's no local mapping for the file's filetype then, for that loading sequence only, the webclient takes as the default the display program suggested (again using a URL/URI) by the file's webserver in the response header.
Of course display programs can be cached locally. There's also no assumption that the default display program will always be the one used - on any given occasion that a file is loaded, the user (or a default-runtime program which is XHRing the file) can specify a non-default display program, in order to get a different UI or a non-standard view or just a different display-program implementation. (And a program doing an XHR could just take the file itself if it desires.) Finally, the process can chain, so a particular file might be given to a display program which is a Ruby script which would in turn be given to a generic-runtime interpreter for the appropriate version of Ruby.
> There's certainly a continuum between the two, but everything in the OP strikes me as arguing for the opaque and locally bound symbol, at the expense of control by the end-user.
Yes, the OP is basically advocating Alan Kay's floor-wax over TBL's dessert topping. But talking about a continuum implies that I'm hawking some horrible compromise substance made by mixing floor-wax and dessert topping in a bucket in whatever ratio. In fact, I'm offering a delicious synthesis product which really is a perfect specimen of both things at the same time! ;) http://en.wikipedia.org/wiki/List_of_Saturday_Night_Live_com...
