HTML & CSS - - By John Allsopp

Is HTML Relevant in the Age of Web Apps?

Let’s think for a moment about what we build, when we build things for the web.

We build traditional web sites — still, I’d argue, the vast majority of the content of the web. These are document-centric, though they may — and indeed, increasingly do — include interactive, application-like content.

We are also now frequently building more application-like, less document-like experiences. This, as we know, has been going on for quite some time but for most of that time, much of our application logic has resided on the server, with the client being a largely dumb interface.

In recent years (though examples of this like Google Maps and Gmail go back quite some way), our client-side applications have become more sophisticated, aided in particular by the ability to send data rather than entire pages to and from the server. We call that Ajax these days, though when people started doing it it didn’t have a name.

In the last three or four years, with the success of mobile application platforms like iOS and Android, we’ve seen a rise in the expectation that mobile applications (particularly) that run in the browser will be more native-like.

And in response to this, a particular architecture has emerged to build these kinds of native-like applications: the Single Page Application (SPA).

Developers building these SPAs have found that there are specific challenges to developing them with web technologies: in particular, performance and the ability for these apps to work while the user is offline.

This has set off something of a crisis mentality among many developers for the web. We seem to have native app envy. Web technologies are themselves too slow. The Web landscape moves less quickly than native platforms like iOS and Android. Web apps don’t work offline. Scrolling is “janky”.

In response to these various anxieties, and also in response to the increasing sophistication of the things we’re now building with web technologies, we’ve seen an explosion of frameworks, libraries, build tools, languages that compile to JavaScript, and preprocessors for CSS.

Now, I’m not saying these criticisms, these challenges are not real, not painful, and don’t need solving. But I think we need to be very careful how we go about solving them. And I’m not sure we’re being careful enough.

Easier Living Through Complexity

Rich Hickey, the inventor of Clojure, speaks about the way in which we as developers often seek out easiness, at the cost of the complexity of what we build. You can watch him talk about it here. You really should. It’s well worth the time.

Easiness, he observes, is a benefit we experience as developers. We start Yeoman, and get all the scaffolding and infrastructure we need for our latest project with the push of a button. But how many interdependencies, how much unneeded plumbing do we also have now that our project relies on?

How much more complex is our application? Complexity is an aspect of the things we build. And the more complex something is, the harder to debug — and maintain — it is.

These days, it’s hard to imagine many sites being built without relying on a monolithic library like jQuery, a UI library, and even more infrastructure. This is how we’ve “solved” the challenge of the ever more sophisticated things we’re expected to build.

But all this plumbing impacts on the performance of our site, so we then need to minify and concatenate our files.

Which means we need tooling to perform these build tasks.

Which makes debugging harder, so then we need source maps.

And, of course, CSS is hard and lacks things like variables and loops (because you know, it’s a declarative programming language), so we need preprocessors to make CSS more like the imperative paradigm of programming.

Which means even more build tools.

And even more distance between our source code and the systems we are building.

And even more layers of abstraction.

And of course it means we need sourcemaps to debug our CSS.

And because this is hard, and because curly braces are painful to type — as is, of course, the word “function” — we need to work in CoffeeScript, which means more preprocessing, more build tools, more source maps, more abstraction.

Again, I’m not saying all of these are all bad in all circumstances. But each tool, each piece of technology, needs to be carefully assessed each time we come to use it. After all, sometimes all we’re building is a plain, old fashioned, document-centric website. Like ReadWrite, does it really need to be built with Twitter Bootstrap? Does each page need on average 19 iFrames, and as many linked script files?

Yes, tooling can make our life easier. We type fewer keystrokes, and commit more code. But as software engineers learned a long time ago, most of the life of an applications is not in its initial development. It’s in maintaining it. This is something we on the web have had the luxury of being able to largely ignore up to now. After all, how many of the things you build will last years, decades? We still largely build to throw out and start again.

As the systems we build increasingly replace traditional enterprise, client server, desktop and mobile apps (yes it will happen), this luxury of building disposable code, with no real concern for the tower of complexity our code rests upon, will pass.

It’s time for us to grow up, and start learning from the more than 50 year legacy of software engineering.

Because, as with all history, if we don’t learn from it, we are doomed to repeat it.

This article was adapted by John from a speech he gave at the Full Frontal JavaScript conference held in November 2012 in Brighton, UK.

Sponsors
Login or Create Account to Comment
Login Create Account