this space intentionally left blank

February 13, 2009

Filed under: tech»web

The Browser Is The New X11

Since I'm not a GMail user, I didn't know about the new button design that Google implemented until I saw a reference to this post by their designer. As an exercise in HTML and CSS trickery, it's pretty impressive. As a look into the sausage-making for serious web application design, it fills me with abject horror.

To summarize: Google apparently wanted a button that would A) use no images for its appearance, and B) allow new kinds of interaction to go with their labeling functionality. In order to do this, they ended up creating a set of custom CSS classes applied to six nested DIV tags, as well as a large chunk of JavaScript, I'm sure. It's very clever, but it also makes me wonder just how far we're pushing HTML beyond where it was meant to go--and how much it's holding us back.

I've been writing HTML code, off and on, for more than ten years now, and I have hated every minute of it. I don't claim to be very good at it, of course, so maybe that's the problem. But it's always struck me as a technology stuck awkwardly between two worlds. On the one hand, a platform- and display-agnostic representation of textual content. On the other, the desire to build attractive, well-designed presentation layouts, including application interfaces. These are not, I think, entirely compatible with each other. Google's new buttons illustrate that tension, as they torturously beat text layout elements into paintbrushes (ones that will display across all the various browser quirks, no less).

There are new options to alleviate that, of course: the Canvas element gives Flash-like drawing tools to JavaScript and HTML developers (once it's more widely available--figure another couple years, at the rate things are going). And toolkits--jQuery UI, GWT, Dojo--have proliferated. But at some point, I think we have to stop, look at this situation, and realize that we're bludgeoning these tools into doing things that they fundamentally were not meant to do. As interface design languages go, HTML is terrible. I have a hard enough time getting a decent text layout to work reliably, much less trying to build interactive custom controls for anything more complicated than a basic form.

The interesting thing about computing trends, though, is that they're cyclical. Displaying information through a clumsy "semantic" thin client/fat server relationship? We've been there, and then most of us ran away to something better as fast as we possibly could. It's only a matter of time, I suspect, before something replaces HTML for doing UI (while maintaining the lessons we've learned about REST and open communication standards), and at that point we will look back in horror, and wonder how we managed for so long.

If you want to see how this is going to go, consider Twitter. All the basic functionality is available from twitter.com, but almost no-one I know uses that if they can help it. Invariably, you get a better experience from one of the clients (I use Twhirl and TinyTwitter for desktop and mobile, respectively). They're more reponsive, they take advantage of the native platform, and they don't require a browser to be open all day long. The communication with the server is still standard Web 2.0, but Twitter developers have largely abandoned the idea that they need to muck around with HTML, and everyone's better for it.

For the last few years, tech pundits have repeatedly predicted that the browser will take over the space currently occupied by the operating system: via solutions like Google Gears or Prism, or a custom shell like gOS, you'll run everything over the network via HTML/JS/CSS. It's failed to happen so far, and it'll continue to fail. The closer the browser comes to "real" applications, as with GMail, the more its shortcomings become apparent, and the more developers have to rebuild basic functionality in a system that's just not meant to handle it.

If anything, the future is in the middle ground: a heavyweight, native or bytecode platform that can be run in a distributed fashion over the web, splitting application programming back out from the browser and providing a real API for developers to leverage. Such a format addresses the weaknesses of modern binary applications, such as heavy installation and slow startup, without abandoning the advantages that a real operating system provides. AIR, Silverlight, and XUL (as well as Java, to a much lesser extent) are possibilities that could achieve this. HTML, if we're lucky, is not.

Future - Present - Past