Is HTML Relevant in the Age of Web Apps?

John Allsopp
Web Directions co-founder

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.

Win an Annual Membership to Learnable,

SitePoint's Learning Platform

  • Anonymous

    Very good points after spending some time looking at Yeoman over the last couple of days I couldn’t help but think to myself that what the hell is this thing all installing when I ran the npm install and looked at all the dependencies. Yeah it’s new and flashy and can do x and y, but is this something I would use in a production site probably not.

  • Kevin Yank

    For mainstream developers, the Java web development space (J2EE) collapsed under the weight of its own layers of complexity and dependency years ago. I agree with John that mainstream web development as a whole now risks going down the same path.

    When the answer to “how do I build a website” becomes “Well, to do it right you really need to read these five books.” or “Pay a professional at least $10,000 for a simple one.”, something important has been lost—something that made us all so passionate about the Web to begin with.

    Ecosystems like Facebook and WordPress seek to establish a baseline abstraction upon which untrained users may build a presence on the Web like “the good old days”, but today’s easy-to-use platform is tomorrow’s technology ghetto. Simplifying abstractions are possible, but are they sustainable?

    With all the impressive, open-standards-based experiments we see come out of, say, Google, I’m surprised we have not seen a beta of a reimagined World Wide Web that combines the media-rich, interactive and responsive experiences we expect from today’s Web with the playing-field-leveling accessibility of 1997-era HTML.

    Ultimately, today’s World Wide Web happened by accident, and the pessimist in me wonders if a democratising platform for human communication can only be created that way.

  • brothercake

    I think there’s a larger issue at heart here — that of putting our own convenience ahead of users’ needs.

    CSS pre-processors are a classic example — they makes things easier for developers, but they generate larger stylesheets which take longer to load and parse. And coffeescript might be quicker to write, but the dependency stack is frightening.

    This is why, personally, I don’t use any of these kinds of tools. No pre-processors, no general-purpose libraries, nothing. Every new app starts with a blank page, with zero assumed dependencies.

    Because what really matters is the user experience. We can’t sacrifice that just to make our lives easier; it’s not our job to make our own lives easier, it’s our job to do that for users.

  • John Allsopp

    Thanks Kevin,

    there’s definitely a place for the off the shelf web site, hopefully with well done underlying code, with concern placed on accessibility, interoperability, responsiveness and the like. Maybe the likes of WordPress will get there, maybe it will end up as facebook (heaven forbid!)
    Meanwhile, like you having seen the crushing weight of infrastructure around “mature” ecosystems like Java, I think, like Joni Mitchell says, we might not know what we’ve got ’til its gone in regard to the simplicity of the stack of technologies we have when it comes to developing for the web.

    In part, I think it’s because relatively few web developers have much real world exposure to more legacy ecosystems, and the complexity around them, that we are rushing headlong in the same direction.

    Or maybe people are concerned that HTML + CSS + JS + DOM isn’t “grown up” enough?

    The web did indeed happen by accident – but maybe that’s a good thing! Because every time we try to do it on purpose, it’s a total failure ;-)

  • John Allsopp

    Hi Brothercake,

    long time. I very much agree, and that’s Rich Hickey’s central point, we make what we build increasingly complex, to make our own lives as developers easier (which we don’t in the long run anyway)

    Maybe we’re both too old school, but that’s exactly how I start too.

  • brad

    so far users don’t expect that much from web sites, so we can pile a lot of junk on because people expect some text, images, simple layout, and some event handling. if we think of highly graphical, rich/interactive web sites, cruft will be removed by necessity, because we won’t be able to deliver competitive solutions otherwise.

    i see the same in backend coding. the traditional cadre of interpreted/dynamic languages (perl/python/php/ruby) eventually get discarded when traffic, complexity, or some other functional demand requires something better. and its not just about replacing ruby with java…i see java on the cutting board periodically in favor of c++. our systems are fast, but system performance is being outpaced by the rise in complexity of applications.

    lacking a major revolution in system design, i expect c/c++ and also high-performance garbage collected tools like go and java displacing the interpreted dynamic tools of the 90s. our problems are getting more complex.

  • James Taylor

    Part of the complexity arises from it not being written down in the flow of the project creation. That’s why I created an implementation of Knuth’s literate programming: http://github.com/jostylr/literate-programming which allows one to write a single (or multiple if you like) document that generates web pages, css, javascript, whatever, and runs it through whatever tool you like. All of the processing is commanded in the document itself, not some external commands.

    It has a macro-language that allows one to eliminate some repetitive stuff, but the most important thing is that it allows one to write all the code as if it is an essay. The evolution of a page and its stuff is all there to be read by the maintainer in the future. Create your files in whatever style and way makes sense, not bound by the dictates of any language.

  • bandcoach

    Have to cosign with Brothercake – every project I do is a clean slate – stops unforeseen errors creeping in and allows for the coding to be customised to the task at hand rather than trying to shim the task into the straitjacket/corsetting of the newer frameworks. I do have some base code that gets reused for certain tasks and some base css for my own projects, but for the most part each project starts unfettered and unsullied by pre-existing code frameworks.

    I jumped on the html bandwagon in 94 and remember the original browser wars and the incompatibility that they brought to the user experience – a handful of developers were pushing their own agendas over the need for consistency (I know all about consistency being the hobgoblin of small minds, but in some situations, consistency is what is needed over all-singing, all-dancing, bells and whistles development)

  • Ken

    HTML came before any of the other languages now used to build web apps. HTML is continually evolving to meet new demands and expectations and should never be fully counted out of the game. I do agree that other technologies have advanced through the years, Java, ASP, and others compete for market share. One thing to consider is simply that when advising a young person on how to develop their programming skills we can make the learning curve a little more shallow for them if we suggest that they learn HTML 1.0 first because it runs on pretty much anything now and it is easy to learn. After that I advise them to learn each version after that and then learn ASP or C++ or C# or whatever seems to be most generally used right now.

  • Craig Buckler

    What a relief. With all the talk of CSS pre-processors, Bootstrap, Grunt builders, etc. I was beginning to think I was the only developer who started with a blank sheet! Having spent many years crafting HTML, CSS and JavaScript I find many of these tools have burdens and don’t save time. As Brothercake remarked, CSS pre-processors supply useful features but you lose control of the final source, your stylesheets are larger and debugging is more difficult. I wouldn’t say you should never use them, but are you using unnecessary layers of complexity?

  • dorja chopley

    i can’t read this, there are too many, commas.

  • David McDonald

    Agree with Craig about CSS preprocessors, I’ve tried to use them in my workflow but for me they added more layers of complexity – especially to debugging.