First, my position: ceteris paribus, view-source was necessary (but not sufficient) to make HTML the dominant application platform of our times. I also hold that it is under attack — not least of all from within — and that losing view-source poses a significant danger to the overall health of the web.

That’s a lot to hang on the shoulders of a relatively innocent design decision, and I don’t mean to imply that any system that has a view-source like feature will become dominant. But I do argue that it helps, particularly when coupled with complementary features like reliable parsing, semantic-ish markup, and plain-text content. Perhaps it’s moving the goal line a bit, but when I talk about the importance of view-source, I’m more often than not discussing these properties together.

To understand the importance of view-source, consider how people learn. Some evidence exists that even trained software engineers chose to work with copy-and-pasted example code. Participants in the linked study even expressed guilt over the copy-paste-tweak method of learning, but guilt didn’t change the dynamic: a blank slate and abstract documentation doesn’t facilitate learning nearly as well as poking at an example and feeling out the edges by doing. View-source provides a powerful catalyst to creating a culture of shared learning and learning-by-doing, which in turn helps formulate a mental model of the relationship between input and output faster. Web developers get started by taking some code, pasting it into a file, saving, loading it in a browser and hitting ctrl-r. Web developers switch between editor and browser between even the most minor changes. This is a stark contrast with technologies that impose a compilation step where the process of seeing what was done requires an intermediate step. In other words, immediacy of output helps build an understanding of how the system will behave, and ctrl-r becomes a seductive and productive way for developers to accelerate their learning in the copy-paste-tweak loop. The only required equipment is a text editor and a web browser, tools that are free and work together instantly. That is to say, there’s no waiting between when you save the file to disk and when you can view the results. It’s just a ctrl-r away.

With that hyper-productive workflow as the background, view-source helps turn the entire web into a giant learning lab, and one that’s remarkably resilient to error and experimentation. See an interesting technique or layout? No one can tell you “no” to figuring out how it was done. Copy some of it, paste it into your document, and you’ll get something out the other side. Browsers recovering from errors gracefully create a welcome learning environment, free of the inadequacy that a compile failure tends to evoke. You can see what went wrong as often as not. The evolutionary advantages of reliable parsing have helped to ensure that strict XML content comprises roughly none of the web, a decade after it was recognized as “better” by world+dog. Even the most sophisticated (or broken) content is inspectable at the layout level and tools like Firebug and the Web Inspector accelerate the copy-paste-tweak cycle by inspecting dynamic content and allowing live changes without reloads, even on pages you don’t “own”. The predicate to these incredibly powerful tools is the textual, interpreted nature of HTML. There’s much more to say about this, but lets instead turn to the platform’s relative weaknesses as a way of understanding how view-source is easily omitted from competing technologies.

The first, and most obvious, downside to the open-by-default nature of the web is that it encourages multiple renderers. Combined with the ambiguities of reliable parsing and semantics that leave room for interpretation, it’s no wonder that web developers struggle through incompatibilities. In a world where individual users each need to be convinced to upgrade to the newest version of even a single renderer, differences only in version can wreak havoc in the development process. Things that work in one place may not look exactly the same in another. This is both a strength and a weakness for the platform, but at the level of sophisticated applications, it’s squarely a liability. Next, ambiguities in interpretation and semantics mean that the project of creating tooling for the platform is significantly more complex. If only one viewer is prevalent (for whatever reason), then tools only need to consume and generate code that understands the constraints, quirks, and performance of a single runtime. Alternate forms of this simplification include only allowing code (not markup) so as to eliminate parsing ambiguity. The code-not-markup approach yields a potentially more flexible platform and one that can begin to execute content more quickly (as Flash does). These advantages, taken together, can create an incredibly productive environment for experts in the tools that generate content: no output ambiguity, better performance, and tools that can deliver true WYSIWYG authoring. These tools can sidestep the ctrl-r cycle entirely.

But wait, I hear you shout, It’s possible to do code-only, toolable, full fidelity development in JavaScript! Tools like GWT and Cappuccino generate code that generates UI, ensuring that only those who can write code or have tools that can will participate; removing the potential value of view-source for those apps. But lets be honest: view source is nearly never locally beneficial. I can hardly count the number of times I’ve seen the “how do I hide my code?” question from a web n00b who (rightly or wrongly) imagines there’s value in it. For GWT the fact that the output is an HTML DOM that’s styled with CSS is as much annoyance as benefit. The big upside is that browsers are the dominant platform and you don’t have to convince users to install some new runtime.

Similarly Flex, Laszlo, GWT’s UI Binder, and Silverlight have discovered the value in markup as a simple declarative way for developers to understand the hierarchical relationships between components, but they correspond to completely unambiguous definitions of components they rely on compiled code — not reliably parsed markup — for final delivery of the UI. These tight contracts turn into an evolutionary straightjacket. Great if you’re shipping compiled code down the wire that can meet the contract, but death if those tags and attributes are designed to live for long periods of time or across multiple implementations. You might be able to bolt view-source into the output, but it’ll always be optional and ad-hoc, features that work against it being pervasive. Put another way, the markup versions of these systems are leaky abstractions on the precise, code-centric system that under-girds both the authoring and runtime environments. This code-centric bias is incredibly powerful for toolmakers and “real” developers, but it cuts out others entirely; namely those who won’t “learn to program” or who want to build tools that inject content into the delivery format.

Whatever the strengths of code-based UI systems, they throw web crawlers for a loop. Today, most search engines deal best with text-based formats, and those search engines help make content more valuable in aggregate than it is on its own. Perhaps it’s inevitable that crawlers and search engines will need to execute code in order to understand the value of content, but I remain unconvinced. As a thought experiment, consider a web constructed entirely of Flash content. Given that Flash bytecode lacks a standard, semantic way to denote a relationship between bits of Flash content, what parts of the web wouldn’t have been built? What bits of your work would you do differently? What would the process be? There’s an alternate path forward that suggests that we can upgrade the coarse semantics of the web to deal with ever-more-sophisticated content requirements. Or put another way, use the features of today’s toolkits and code generators as a TODO list for markup driven features. But the jury is still out on the viability that approach; the same dynamic that makes multiple renderers possible ensures that getting them to move in a coordinated way is much harder than the unilateral feature roadmap that plugin vendors enjoy. HTML 5 and CSS 3 work is restarting those efforts, but only time will tell if we can put down the code and pick markup back up as a means to express ourselves.

I’ve glossed over a lot of details here, and I haven’t discussed implications for the server side of a non-text format as our lingua-franca, nor have I dug into the evolution metaphor. Many of the arguments are likewise conditional on economic assumptions. There’s lots of discussion yet to have, so if you’ve got links to concrete research in either direction or have an experience that bears on the debate post in the comments! Hopefully my fellow panelists will respond in blog form and I’ll update this post when they do.

Apple

iPhone, Safari

Google

Android, Chrome

Nokia

Series 60 browser

Plam

WebOS

Adobe

AIR web runtime

From deep integration with the platform to being the platform, WebKit in various forms is how nearly every credible smartphone now “does” the web. The major outliers here are the WinCE devices, Blackberry, and whatever Sony’s doing this week, but the writing is on the wall for them too. Mobile IE is a joke and the Blackberry succeeds in spite of its web experience. iPhone, Android, and Pre have raised the bar. The sucky-web center will not hold.

For a sizable chunk of the mobile browsers that a web developer would like to target today, that means that WebKit == Mobile. As predicted, the mobile world has beaten the desktop to the web of the future. It doesn’t hurt that WebKit is making deep inroads into the desktop, either….but then you could reasonably assume that they pay me to say that.

So what does a WebKit-only world look like? And how portable are our desktop-web skills and tools? I did a quick set of experiments this past weekend to see how much of Dojo you’d still need and what we could leave behind. The results are encouraging. The headline numbers for dojo.js are roughly:

You can grab a copy of this pre-1.3.0 version here (webkitMobile.dojo.js).

The big size wins (in decreasing order) were:

1. Moving to a QSA-only version of dojo.query()
2. Being able to use intrinsics for dojo.forEach, etc.
3. Dropping IE and FF-specific rendering, XHR, and style hacks
4. Using a common closure wrapper for the entire core

And there’s even more fruit on the vine. I think without too much more work I’ll be able to drop the current animation system in favor of pure CSS animations and can significantly simplify the XHR code which doesn’t do the straightforward thing to avoid terrible memory leaks on IE and very old versions of FF.

All of this points to where we could be if the browsers just got collectively awesome all of a sudden. That’s the good news. The downside is that still leaves a lot of janktastic spec mistakes to be worked around at nearly every level of the platform. This experiment suggests that there is still a price to be paid just to get the platform to a usable state. If we look at the APIs of Dojo, Prototype, or jQuery as a set of suggestions for the APIs that the web should expose, then it becomes pretty clear that we’ve still got a long long way to go. But we can do at least 30% better in the short run, and I’m very glad of that.

My friends over at SitePen beat me to the punch on my own patches, but that’s how it goes sometimes. Props to them for that.

Take, for example, ZDNet’s gutter-to-gutter coverage which, I’m afraid, simply ends in the intellectual gutter. Larry Dignan’s piece does the profession no favors by simply recycling the tried-and-true blogger formula for traffic generation:

I know about X, Google did Y, which is clearly *all about* X

The best of this flavor of “story” approaches the quality level of a plausible but objectively outlandish conspiracy theory, often pulling together bits of fact with a healthy dose of wild speculation (journalistically couched as the unfounded and unquestioned opinion of some supposedly credible third party).

ZDNet piles all aboard the loony-bin express with Paula Rooney’s “analysis” piece, helpfully asking the non-question “is this a prelude to Google acquiring Mozilla?”. In what twisted alternate universe would this wild, hair-brained straw-man garner a full ‘graf in a legit online publication, let alone a respected print daily? A small, tiny dig into the strategy of Google’s Mozilla search placement deal and the infrastructure of the Chrome browser would lead anyone (and everyone) to conclude that Google’s interest here is in keeping the browser a viable platform by any means necessary, not that they would ever gain anything by “acquiring” MoCo or MoFo (an even more nutty idea, since it would be difficult for a 501(c)3 organization to transfer resources and assets to a for-profit entity anyway).

The strategic and tactical incoherence continues with the daringly dumb quote:

Larry Dignan of ZDnet suggests that perhaps Google and Mozilla are working together as a tag team to defeat Microsoft’s Internet Explorer, and that Google may perhaps purchase the Mozilla Firefox crew and integrate the two code bases to deliver a kock out punch to Microsoft’s IE. Will Mozilla become Google browser labs? Given the close cooperation of the two projects, it’s more than possible.

Ignoring the incestuous and dubious use of a fellow reporter’s speculation as a source for an article, the idea that the Google would want much (if any) of the Firefox team (or vice versa) beyond those which they already pulled away. It does Google no good to reduce competition in the browser space, and one can imagine that there’s no love lost at Mozilla over Chrome, particularly after Google shunned the Firefox rendering engine, replaced the JavaScript engine, and re-built the entire visual and end-user experience from-scratch with completely different technology (i.e., not XUL). Good sourcing might have fleshed out the idea and perhaps even made a case for the theory, but alas, that seems far too much for ZDNet to produce on deadline. I mean, it’s not like they cover technology for a living…gosh, that’d be embarrassing. Quick tip for the next time they want to write this story: Google just became “Google’s browser labs” after giving Mozilla a good long run at it. They’re still strategically aligned, but Google seems impatient and is likely most interested in having direct leverage in the browser space (first via Gears and now Chrome) instead of the indirect influence they exerted over Firefox when it was still “Plan A”.

The coupe-de-disgrace belongs to PC World, though. After laying out 7 sensible, but “we’re just cribbing this from the press release, really” reasons to like Chrome they proceed to indulge in 7 forehead-slappingly idiotic reasons why you might consider something announced as a Beta to be…well…a beta. It feels kinda dirty just linking to it. Luckily, the PC World crew was able to get it together enough to publish a scoop-free “I played with it for 5 minutes” piece that WaPo wasn’t embarrassed to run, although the “like being there!” aspect really looses it’s punch when anyone can download the beta and, well, be there.

At least with Wired you know you’ll be getting fawning access journalism without the pretense of objectivity, but damnit, it’ll be well written and vaguely cogent.

I won’t even start on the blags. It’s to depressing. I’ll except Ajaxian and Philipp Lenssen here as they added some useful background from the inside perspective and scooped the story (respectively). “Citizen journalism” has a loooong way to go before it earns a place in the 4th estate, though.

Why, oh why, can’t we have better tech journalists?