Weblogs: Web Standards

The first two talks at this year's Full Frontal conference were extreme position pieces arguing about the relevance of HTML in building webapps. They were sparked by the growing number of web app frameworks that start off with an empty HTML document (or a series of nested empty div elements), such as the first version of SproutCore used prominently by Apple's failed MobileMe website. As my good friend Steve Webster describes SproutCore's development approach at that time:

SproutCore doesn't just ignore progressive enhancement - it hacks it into tiny little pieces, urinates all over them and then mails them back to you one by one

(Note that these frameworks have a track record of ignoring established web development best practices, and then attempt to bolt them back in later. Meteor is also heading down the same cobbled path, they added Google crawlability as a feature in later releases.)

Enforcing imperative development

The list of Web frameworks that perpetuate the empty-document technique grows; SenchaTouch and Meteor being two garnering attention today. John Allsopp notes the approach is about replacing a declarative set of technologies with an imperative model. Thus the idioms and patterns are quite different.

The core of the argument is that apps built using web technologies are being left behind by app-specific development toolkits, and that web technologies need to improve to be better than these toolkits. Trying to succinctly express this runs headlong into absurdity, perhaps not through reductio ad absurdum:

Apps built with app-specific technology are better apps than those built with non-app-specific technology.

Obvious? But more pertinent is the question: so what? The Web's declarative model is what keeps the barrier of building websites as low as possible. (And web apps are just websites, just with a lot more JavaScript.)

The shiny toy syndrome

And yet, James Pearce's talk at FullFrontal 2012 kept plugging in this direction, resulting in this particular example of HTML minimisation:

<script src="app.js"></script>

That is the entire HTML document for a web application. It's hard to understand whether this is a tongue-in-cheek, or a foot-in-mouth argument. Claiming it as just an extreme example of a web app and not meant for real world use is disingenuous; people seem compelled to use these odd curiosities in real world products.

Take the "lets reimplement the browser in Canvas from scratch" noodling of Bespin. As the HTML5 Editor (at that time) Ian Hickson noted:

Bespin is a great demo, but it's a horrible misuse of <canvas>.

Or Henri Svionen's less succinct, yet still brutally accurate:

I think Bespin can be taken as an example of using <canvas> being "doing it wrong" and the solution being not using <canvas>.

Despite this regular feedback, it still took the Bespin / SkyWriter developers a few years of fighting with performance and usability issues before they moved away from canvas. In that time, not least because of the initial attention Bespin received in tech circles, the "canvas as the browser" approache started to gain adoption as an acceptable way to build web applications. Bespin was no more than a proof-of-concept never intended to be used in a production setting (according to its developers).

Doing it right the hard way

Of course, modern web developers using new fangled content-less HTML aren't making the same mistakes as Bespin and SproutCore. Their conceptions reflect web development best practice; of a separation of concerns (for stability), progressive enhancement (for wide device compatibility), graceful degradation (for robustness), accessibility (as an extreme usability utility). Right?

In the far-too recent past, web app developers jumped on the HashBang URLs as the technique that exemplifies the applification of the Web. Despite it being contrary to web development best practice, single-page webapp developers persisted with this technique in the name of better performance and more robust code.

Yet Twitter backtracked back to progressive enhancement (in the name of better performance, reducing the time to first tweet), and Gawker Media quietly reverted on their hashbang-dependent implementation in the name of customer experience and robustness.

Both companies recognised that the problems of Hashbang URLs weren't in the URLs themselves, but the complete dependence on a JavaScript bootstrap for the content experience. That means instead of one document loading before content appears, it now requires one document, plus a chunk of JavaScript that simulates a browser to load in, initialise itself, call its required content and template assets and then render them in the content window.

Death by first impression

Where HashBang URL using web apps fell down is the overhead before a user experiences the first chunk of content (Twitter's "time to first tweet" metric) is too high for a responsive web experience. Yes, the single page website is fractionally more responsive to customer interactions after the core application infrastructure has finally loaded up and run; the duration to first content visible turns out to be a more important metric.

It's the first impression, folks. Despite the empirical fallaciousness on the importance of a first impression, customers tend towards experiences that get them to their content and utility quicker. We've know this since the beginning of the web; a two-page form converts better than a three-page form, despite requesting the same information.

It's probably an urban legend, but makes a good story nevertheless, that Twitter brought in the high-priest of High Performance JavaScript (Steve Souders) to advise them on how to make their web application faster and he replied with: "Have you though about putting the Tweets in the HTML instead of loading them through JavaScript?"

It turns out progressive enhancement isn't dead. It's actually still the primary technique for getting content to the customer fast. It's just continually ignored, and web apps eventually get there when they run out of non-best-practice techniques to throw at the bootstrap-time problem.

(It does make me chuckle when web developers claim progressive enhancement is hard as a reason for skipping it, and a little time later after the diminishing returns of that short-sightedness has worn off, they undertake the far more difficult approach to bolting progressive enhancement back in because the alternatives are even harder. All high-quality and efficient web development paths go through the forest of progressive enhancement eventually.)

Building applications with the web stack

Building applications using web technologies isn't new. We've been doing it for at least a decade. Sometimes you don't really notice.

Firefox and Thunderbird are two quintessential examples of applications being built with web technologies. The entire user interfaces of both products are a collaboration of markup, CSS and JavaScript displayed by the Gecko rendering engine. Firefox is thus the inception point, since it's a web application that runs other web applications.

We had a steady stream of applications built on Mozilla's XUL framework beyond mere proof-of-concepts (and Twitter clients): Songbird, Komodo Edit IDE, Cyclone3 CMS, Flickr Uploader, ChatZilla IRC Chat, InstaBird IM Client, Blue Griffon ePub editor, StreamBase.

XUL is an XML vocabulary, but it works with HTML so cleanly that at times it can be mistaken for just being extra tags bolted on top of HTML. Even the extension mechanism XBL allows you to create extra tags that can be used as first class elements in your structural (or declarative) documents.

The Mozilla approach to connecting the web surface to the computer interfaces is to create an entire series of APIs that expose the inner workings of a computer and make them available through JavaScript. And the developer can chose to surface that right up to an actual custom element.

We've sunk countless hours working within the XUL framework, some of the best developer tools came through that route. For example Joe Hewitt's Firebug, a tool that effectively brought web development out of the Stone Age, and its little cousin Chris Pederick's Web Developer Toolbar.

The second still-growing framework for web technology based apps is Adobe Air. I still regularly see new software being built by and sold to small and medium-sized business, as a simple way of encapsulating expert knowledge into a handy tool. I think I've bought at least three Adobe Air based applications (not including Twitter clients) this year alone. For example Keyword Blaze helps small businesses explore and find online niches and assist in Keyword Research. It's lowering the bar for entrepreneurs to handle and manage their own SEO strategy.

While webapp ninjas complain about their tools and environment, entrepreneurs create these applications with the web stack.

As an aside: there was a movement running in parallel to Mozilla's effort that focused on the idea of Rich Internet Applications (largely driven by the Open XUL Alliance), where developers collaborated on building declarative interface bindings to their pet languages. For a brief while that's where web application development sparked. That produced toolkits like Luxor-XUL for client-side Python bindings as one notable example.

Web application stack drawbacks

The typical counter-argument to these approaches is the visual look and feel. Clearly none of the platforms above look exactly like custom iPhone apps on the iPhone. They don't feel like native iPhone apps.

Developers who find this particular feature galling then go to extraordinary lengths to duplicate the feel of the iPhone interface inside their web apps. This has the side-effect of the app feeling ridiculous on an Android phone of the same technical specifications because you get an Android experience on the outside, and a sub-par iPhone emulated experience on the inside of the app. It's common to land in a situation of having two back buttons in this scenario each doing something different.

The crux here isn't that web technologies don't make good enough application platforms, they don't match perfectly with the native apps look and feel. Because every native platform is different, whether it's in the design or the establishment of the idioms and metaphors that are the heart of it, or just subtle differences in definitions and interfaces.

The Web is platform agnostic, its success isn't chained to the continued success of a specific platform. And so they do not conform to individual platform expectations. Much like their cousins the cross-platform application toolkits (Java, QT, Lazarus), they don't exactly match the Operating System native widgets because there isn't a clean mapping across the range of platforms they support.

This platform independent characteristic is a feature of the Web, not a shortcoming. It's not meant to emulate Operating System graphical widgets. That's the browser's job (or the operating system's job), not the web stack's.

And you know what, it doesn't matter. Applications written for a specific platform also don't always look the same as other apps on the same platform. WinAmp, QuickTime, Twitterific, Chrome and StickyNotes are just five applications I'm running right now that don't look like the default visual standard of the Operating Systems they are running on.

If an application's success is primarily based on looking and feeling like a native application for that platform, you really have to be an idiot to build that application using something other than a toolkit or framework designed with that goal as the primary endpoint.

GMail continues being a pioneering success for web applications. It remains steadfastly popular for its features and information management, not because it looks like a native iPhone app on the iPhone.

The Web platform

The Web's independence from the hardware and software platform people use is a feature. It's better than cross-platform frameworks which are constantly criticised for not producing exact native-feeling apps on the multitude of platforms they run on. The Web is above that pettiness.

The Web isn't an application platform. It is really a data platform (or more precisely, a content platform). A data platform that has a very light visual and behaviour layer available: Cascading StyleSheets and JavaScript.

Take a typical brand new iPhone. Make sure it doesn't touch the web in any way, so place it in an environment where it cannot make an HTTP Request or receive an HTTP Response.

How useful are your native applications? Oh that's right, the only applications you can get to are the ones installed on the phone by default. The other applications are just data sitting on the Web waiting for you to request them.

And the default applications you do use because of the value they provide are probably going to offer you less value without that lifeline to the Web. Yes, the value of the application isn't because it's a native application, but because of the data it uses, and that data is sitting on the Web.

Smartphones are useful because they participate on the Web of content, as equal citizens to desktop browsers and tablets. Applications are just a shell that offers interaction with the data. Without the data, the interactions are worthless.

The Web is ubiquitous

Native apps need the Web, the Web doesn't need native apps.

If your primary requirement is a seamless native app experience, then you need to build a native app for each platform you want to support.

If you are content to abstract away the nativeness of a platform to a wrapper (like a browser), then a web application is perfectly adequate.

But there's also a third alternative: a hybrid of both approaches, since the Web isn't (just) an application platform, it's the primary globally available data platform in your application.

We who cannot remember the past...

---

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]