Full Fucking Service
Reckless web development practices are encouraging idiots

Or, how content is suffering because of lazy people who don’t understand that a strong web relies on addressable content with access to all.

Reckless web development practices are encouraging idiots and prolonging the cycle of ignorance in front-end development and its associated industries.  The kind of irresponsible practices encouraged by the current series of “AMAZING!" "HTML5!" "WEBSITES!" is manoeuvring the web development industry into a corner which it may struggle to fight its way out of.

Sites like The Expressive Web from Adobe and demos for applications like Sencha Animator and Edge — again from Adobe — display some of the worst practices of browser-based development. The content these sites are dressing up with extremely rich interfaces is being negated by the very technology that is aiming to communicate content more clearly. Because these sites are absolutely reliant on JavaScript, or Flash, or a particular browser (in Animator’s case, WebKit) in order to display their content, the sites are failing at their job. They’ve taken us back to the early 90s in terms of the maturity of the web. They show an absolute disregard for the building blocks of the web in favour of ‘the shiny’ — a repugnant phrase which reflects the shallowness at the heart of many web workers’ outlook. They are style over content. They may fool casual web users, but they are hollow and artificial eye-candy that merely serves as a distraction for developers who just want to do a good job.

It’s really simple: if you have important content to display to the user, it is the primary job of your web page to deliver that content to the user. The content, or resource, might be some text, or an image, or a video; or a combination of all those things. Now, within reason, there is nothing stopping you serving that content, or a representation of that content, to any user, in any web browser, without having to rely on a particular technology. The language of the web is simple. Resources are nouns and HTTP methods are verbs. I get a resource, or I put a resource, or I post data to a resource, or I delete a resource. The whole things falls apart if there are no real resources to interact with. I’ll come back to the representation of content later.

There are plenty of circumstances where I can imagine you might want to argue for a fully JavaScript dependent solution with no real content underneath. A web application which is also to be dropped into a native application and deployed into a mobile device? Okay. A web application of such terrifying complexity that it cannot possibly operate without access to JavaScript or, less convincingly, Flash? Maybe. But in the vast majority of cases there is just no need for the sort of shoddy corner-cutting that web developers are increasingly engaging in.

I work in a full service digital agency, where clients expect to serve content to the vast majority of their customers, whatever their browser, whatever their device. And in the vast majority of cases we can do that. Because we understand their domain, and we understand their content. We know what’s important to them. Content is king. Many of our clients are open to experimentation and innovation, but when those ideas are rightly folded in to the mainstream offering everything still needs to operate in a stable framework of content delivery. If a user on a device can’t see any content on a page, she doesn’t assume it’s her device that’s broken, She assumes it’s the website that’s broken. And that looks bad for the client, and bad for us.

The representation of content I mentioned earlier is a technically and culturally proven method for delivering content everywhere on the web. The technical implementation of it is progressive enhancement. Progressive enhancement is based on the notion of core content, feature testing and step-by-step improvement of the user experience. By utilising the features of the browser available to us, we can represent the content in the best and most appropriate way possible. In this way even the most basic browser gets a simple representation of the content — for example, a simple mobile phone device may display a single-column of plain text, or a low-resolution image. The next layer is an enhanced presentation layer, usually using CSS and higher resolution images, which can be used to target a number of differently sized devices.  Larger screens may be able to flow content differently around a complex layout. This is followed by the behavioural layer, usually JavaScript, which can completely transform the look and feel of a page beyond all recognition. But it’s still the same page, and the same core content is there in some form.

At a time when the engineering aspect, particularly of front-end development, is being increasingly better understood, many people are creating fundamentally weakly architected solutions to what are well-understood problems. The most architecturally sound method of creating content on the web is to create the static resources and the method of accessing those resources; then to enhance the experience of accessing those resources through a better, richer interface, and by significantly reducing or optimising the journey. Then to add the secondary and tertiary content and beyond — the social layer, the ads, the analytics, the animations and interactive behaviours which maintain user engagement and keep users coming back. But to start that process at the wrong end — by creating the whizz-bang graphical animations first — you’ll always be struggling with an essentially unstable foundation. Your content is at the core of your website and at the core of the web, so build it first.