View-Source Follow-Up
One of the points I made during last Saturday's panel was that the further down the path we go with JavaScript, the more pressure there is to use it in ways that defeat view-source. Brendan called me out for seemingly not being aware of beautifiers which can help correct the imballance, but I think that response (while useful) is orthogonal to the thrust of my argument.
Indeed, I hadn't personally used the excellent jsbeautifier.org, instead using my own hacked-up copy of Rhino to beautify when I need to, but neither tool sufficiently reverses the sorts of optimizations being employed by GWT and the even more aggressive Closure Compiler. Far from the mere obsfucation of ShrinkSafe and its brethren, these new compilers apply multi-pass AST-based transforms on an entire body of code, performing per-browser optimizations, type inference and annotation based optimizations, loop invariant hoisting, function inlining, dead-code removal, and global code motion optimizations that produce code different not only in style but in flow of control. The results are nothing short of stunning. The Closure Compiler can deliver code that's much, much smaller than I can wring out by hand and that performs better to boot. It's also totally unrecognizable. De-obsfucators have no hope in this strange land -- brand new tools akin to symbol servers and WinDbg-style debuggers are needed to work with the output in a meaningful way. I argued in the panel and in the comments of my last post on the topic that when we get to this place with JavaScript the product is functionally indistinguishable from a bytecode format like SWF or Java and the effects on the learning-lab nature of the open web are the same: less ability to easily share techniques, a smaller group of more professional users, and a heavier reliance on tooling for generating content.
If we assume that the furthest down the code-centric path we'll go are the Dojo and JQuery style augmentations of existing content, then a simple de-obsfucator is sufficient. But I'm afraid the current generation of high-end sites and apps points in a different direction, one that is less hopeful, and one that implies to a greater extent that the browsers must lead the way out of the wilderness by creating new tags and CSS properties to help re-democratize the process of creating applications. We've already seen the alternatives, and while they may be elegant, they lack leverage and the second-order beneficial effects that have made the web as successful as it is today.
If HTML is just another bytecode container and rendering runtime, we'll have lost part of what made the web special, and I'm afraid HTML will lose to other formats by willingly giving up its differentiators and playing on their turf. Who knows, it might turn out well, but it's not a vision of the web that holds my interest.