Have you ever seen an error message like this one? XML parsers are designed to call it quits as soon as they encounter an error. XML grammar is strict, so the parsers need to be strict too. This particular error is from an & in a URL. &s in URLs are super common occurrence, but if you throw one into a plain XML document, without inserting it as a character entity (&) or numerical character reference (&) you get an error.
Sweet.
To be honest, I’m not a huge XML hater. I’m a technical guy so ensuring that some of the documents I create adhere to a technical standard doesn’t kill me.
I mean, Ant.
That said, I don’t like the way XML’s strict error handling inserted itself into the web with xHTML. A good part of the reason the web blossomed the way it did was because the language underpinning it, HTML, it was so forgiving people could get by without knowing what they were doing. My initial HTML was so bad, I’m surprised I ever did anything.
But yet, I did.
And I’ve been building sites since. 17 years and counting! All because I could create a tag-soup mess that, kinda/sorta did what I wanted it to do and the browsers at the time did their best to try to make sense of it. That was great.
XML/xHTML took that possibility away. Which is why, while many people (including myself) wrote xHTML documents, we didn’t actually serve them as XML. The danger of having a catastrophic error was too great, so all but the hardiest developers basically treated xHTML like HTML 4.0, just with XML style syntax.
Which is kinda’ goofy.
Remember when they said “Users should not be exposed to authoring errors?”
The group that went on to found the WHATWG (the group responsible for the current HTML specification) recognized that this was a serious flaw and put a specific reference to this issue with xHTML in their proposal for the future of web application development. It was one of their seven guiding design principles. In case you’re unaware of the history, that paper is the foundation of the modern HTML specification. One piece of that foundation is as follows:
Users should not be exposed to authoring errors
Specifications must specify exact error recovery behaviour for each possible error scenario. Error handling should for the most part be defined in terms of graceful error recovery (as in CSS), rather than obvious and catastrophic failure (as in XML).
These are concepts embedded in the very heart of modern web development.
- Avoid catastrophic errors.
- Allow for graceful error recovery.
Why, then, do so many people create web applications that rely so much on JavaScript that they catastrophically fail? The web, at its best, should be resilient. Nothing warms my heart more than a 20 year old page that’s still kicking, a 10 year old link that redirects properly onto a completely new domain or platform or a modern site that can serve something useful to a 15 year old browser. To me, that’s the web at its best.
The opposite end of that spectrum, from my perspective at least, are the sites that do nothing at all without a relatively modern (or, in some places, completely modern) browser with JavaScript turned on and all dependencies (many of which are on third-party domains) loaded. While you can make an argument that JavaScript should be a hard requirement for certain kinds of applications (I’ll give you games written in the Canvas 2d API, for example,) I don’t think it’s the way of the web to have your site fail and show a blank screen because some third-party dependency doesn’t load, JavaScript is turned off or because your developer left a trailing comma in a JavaScript object and didn’t test in Internet Explorer.
I understand that creating a completely static version of your site or application is impractical. Granted. Still, showing nothing if there’s a problem is just terrible. But yet, people are happy to do it.
Client side JavaScript all the way
Nicholas Zakas has talked about this a little bit with his presentation, Enough With the JavaScript already. We’ve moved so far towards JavaScript in some circles that some people are starting to use tools like Backbone even in use cases that don’t require complicated interactions, like a static content site. Whether it’s a case of being obsessed with the new-shiny or simply not knowing any better, people are parsing and rendering entire pages in the client, even when there’s no real dynamic content. Beyond the fact that that’s going to be slower (why would you serve 1MB of JavaScript/JSON to render 100kb of HTML when the server can just serve the parsed/rendered 100kb to begin with?) you’re just setting yourself up for catastrophic failure if, for example, your static content server goes down and all that fancy Backbone code disappears.
What’s wrong with progressive enhancement?
Nothing, that’s what. Just because we can do everything in JavaScript doesn’t mean we should. In fact, the more complexity and dependencies we bring into the front end, perversely, makes the danger of something catastrophic happening even more likely. Third party scripts, web service calls, browser bugs, users with JavaScript disabled and your own application errors can all cause catastrophic failures if you’re not careful. That’s why, in my mind at least, the principles of progressive enhancement are more important now than they’ve ever been. Building solutions that are robust and resistant to changes in the environment (including many that are going to be forever beyond your control) is going to ensure that you can always reach your audience.
Your users don’t care how fancy your stack is. They care that they’re getting their content, that they’re getting it as fast as possible and it appears consistently from visit to visit. If your stack is getting in the way of any of those goals then you need to revisit the way you’ve designed your web solutions.
