J is for Joyless
The point is folks, the browser is dead, so long live the browser!
X is for eXile (I hope)
I have had the misfortune of having been involved with XML since its very early days. I remember pleading with our standards folks at Microsoft and the W3C to get XML simplified. I remember asking that we get rid of the stupid attributes, reduce the bloat and for heaven's sake put in a workable schema language. I failed on all fronts. Not one of my prouder moments I must admit.
Nonetheless XML has become a huge success, which most of us guessed would happen. That's why I pushed WebDAV to support XML. We used to joke about the XML Jedi Mind Trick. You could walk up to anyone and say "You will support XML" and voila, they would do it. Scary stuff.
XML is not beyond redemption. If the world got a clue and switched to RelaxNG then we could probably deal with XML's bloat, complicated processing model, etc. But I don't see it happening because of the huge investment in XML Schema. To me this means that XML is an evolutionary dead end. If a data language can't do versioning then it's a dead letter in the protocol world.
I have no idea what will replace XML but I must admit to some evil thoughts about JSON + XML Simple Types + a RelaxNG style schema language.
The browser has been a success for a large number of reasons, from the simplicity of HTML (in the old days), the beauty of graphics (anyone remember Gopher?) to the power of the URL model. But I think one of the key aspects of the browser's success is that it is, in essence, a pain free application installation, execution and de-installation environment.
You can 'install' software just by navigating to it, no install dialogs to worry about, no disk space issues to check, to permissions to fret over, no conflicts to deal with, and when you are done with the "software" (a.k.a. web page) the software just vanishes (well mostly…).
All of which leads me to point out that when we look for the new browser to replace the AJAX browser we must make sure it keeps the same 'pain free' execution environment characteristics of the browser. So yes, put in server functionality, but make the server functionality disappear when the user exits the "page" (or whatever metaphor makes the most sense). By all means put in local storage, even SQL support, but make sure that the storage is first and foremost a cache. The browser can be smart about keeping cached content around for frequently visited "pages" but in the end a site has to understand that any data it puts in the cache can disappear at any time and so the information has to be backed up. And yes, we can do cool things like dynamically define where 'backed up' is so that 'backed up' could be the user's own machine or a user selected, fully encrypted, network backup facility or whatever. But that's a separate story.
Regardless of how these issues are resolved we must make sure not to throw the baby (pain free execution, URLs, etc.) out with the bathwater (modern browsers).
Go Forth and Be Creative!
But one word of warning, please, for the love of G-D, do not try to standardize this next generation "thing" any time soon! As I have talked about before premature standardization is a great way to kill a market and destroy all creativity. The last thing we need is a 'designed by committee' monstrosity in an area where no one fully understands what the problem is much less the solution. Standards are what happens once innovation has come to an end. So please, allow the market to have its say!