Eight Squared Software

Stop breaking the Web


Over the past several years, tech bloggers and coding magnates have spent countless words on decrying the Web as an application platform. Chances are you've heard it before. The chorus has shouts of “The Web is broken!” while various verses complain about the weirdness that is CSS (evidenced by the nearly half-million Stack Overflow posts with the 'css' tag) and the fact that JavaScript was invented in ten days, and how can a language with such minimal gestation time amount to anything good and decent? “The Web is broken.”

But before we light our tiki torches to set fire to that which we call the Web and break out the marshmallows to roast over its embers as we discuss what should rise from the ashes, we should consider the possibility that the Web is broken because we are breaking it. We break it by appifying everything, by insisting that the browser permit us to execute hundreds of kilobytes of arbitrary, unsigned code in order for us to display even the simplest of content. We break it by insisting that all users have high-speed, reliable connections at all times to download dozens of assets (without any one of which the entire site falls down), not to mention that ginormous video that autoplays above the fold on the landing page. And we break it by requiring users to possess a spiffy new CPU and preferably a decent GPU as well to bring our glorious creations to life at the expense of their bandwidth and electricity, which we consume as though it were unlimited and free of charge.

In this article I will argue that these practices go against the very spirit of the Web as laid out by Sir Tim Berners-Lee and his colleagues nearly 30 years ago. I will not argue against using the Web as an application platform. This is dearly wanted, and we now have a list more than a decade long of fantastic Web applications to bear witness. I will also not argue that the Web is the final stop on the journey to cross-platform, always-updated, interactive applications. I sense most developers would agree with me on this point: using the Web as an application platform feels wrong, like mixing barbecue sauce into your ice cream. Eventually (we hope) someone will discover a better way.

The Web as it was meant to be

To understand my reasoning, it will help to return to where it all began: the original proposal for the development of the WorldWideWeb. Like most inventions, the Web found its birth in a problem needing a solution: information scattered across computers, locked away in myriad formats and guarded by proprietary protocols. Only those with the right credentials, the tangible blessing of the omnipotent system or network administrator, were permitted to access this or that network share or database. The Web was to be a virtual bolt-cutter, freeing information from these chains and making it available to all. In essence, the Web was to be the user interface for data.

If you are reading the proposal for the first time, several things may surprise you. First, that your browser renders the page rather well, despite the underlying markup having a decidedly archaic flavor (lacking closing tags in many places, and no <head>, <body>, or even <html> tags to be seen). Few formats can rival HTML when it comes to backward-compatibility and longevity.

Second, that HTML is mentioned nowhere. (It hadn't been invented yet.) In fact, despite the popular envisioning of “the Web” as “HTML and CSS documents”, the Web's actual goal was to publicize information regardless of formatting. Information (or generic nodes, as termed by the proposal) can be anything: a CSV file of world population statistics; a tab-delimited weather forecast for Helsinki, Finland; and the third draft of a space opera set in a galaxy far, far away are all considered information.

Third, that accessibility is a primary goal. From its inception, the Web catered to the lowest common denominator. Users on text-based terminals with cursor-oriented browsers were just as welcome as those on spiffy new Macintoshes and NeXT boxen. In today's appified Web we suffer from a collective amnesia regarding this point. Despite many Web apps being little more than glorified portals to create and consume the very sorts of information the Web sought to liberate, we often exclude users who fail to meet some unspoken set of hardware and software requirements, evoking memories of sites from decades past that required a particular version of Internet Explorer in order to run.

One need only browse the Web with JavaScript disabled (or if one is particularly brave, with CSS disabled) to see how far we have fallen. Fancy apps like Pixlr's image editor not working are expected—certain tasks like media content creation and games simply must have the ability to execute arbitrary code that only JavaScript currently provides. But for a news site like Forbes, whose primary output is text-based information, to simply refuse to work without any explanation should you dare to access its servers without JavaScript turned on is a terrible disappointment.

Before you point out that only stuffy old news sites clearly stuck in the last decade are guilty of this sin, consider the example of How Many People Are In Space Right Now?, a single-page site whose sole purpose is to display a number and a list of names that changes no more than a few times a year. Should you have the endurance to type out the full address, you will be greeted with no useful information behind that URL unless you agree to execute a script that does nothing more than fire off an AJAX request to load a JSON file from the server. The Web would be better served (pun intended) if requesting the root URL returned the raw data rather than a gussied-up SPA full of extraneous images and markup.

Preserving the Web

How can we keep the Web open and accessible as it was in the beginning? One answer is to throw out JavaScript entirely, to return to the world of server-side rendering and full-page refreshes just to post a comment on a Facebook post. But this is throwing the baby out with the bathwater. The explosion of JavaScript has pushed the Web into the future, and though this explosion helped coin the term “JavaScript fatigue”, it also made possible experiences that the authors of the Web probably never imagined three decades ago. Despite its warts, the shoehorning of application delivery into the Web has at least given us a good idea of what works and what doesn't while simultaneously setting the stage for debates about the next great leap.

Instead of abandoning years of progress, let's embrace the Web's original goal of accessibility. In the twenty-first century, everyone deserves to access the Web, whether you are on a bleeding-edge desktop with fiber to your home or an eight-year-old netbook patched into an overcrowded 2G cell tower. We can keep the Web open to all by following a few basic rules.

First, treat assets as optional. When a user requests the content behind a URL, you cannot assume that any external assets (images, stylesheets, scripts) will be loaded. Perhaps the user has disabled JavaScript for privacy or performance reasons. Perhaps the user has disabled images in order to conserve bandwidth on a metered cellular connection. Perhaps a network grue ate those other requests before they reached your server. Whatever the case, make sure that first response has the content you expect users to see. Have you tested your site with all the bells and whistles of the modern Web silenced? You should.

If you provide a web app that absolutely must have JavaScript, politely inform the user that their browser needs JavaScript enabled. If at all possible, make your app's primary features functional without JavaScript, or provide a "light" version of your app that covers the 20% of features that 80% of users rely on. And if you are a content publisher, blog, recipe site, news aggregator, or are otherwise in the business of amalgamating chunks of text into something resembling a page, you have no excuse for your site not to function when JavaScript is disabled.

Second, never treat CPU and network as free. A user's visit to your site is not carte blanche for devouring that user's processor cycles and network bandwidth with wild abandon. Particularly with mobile devices, there is a very real cost associated with every asset that must be packaged and shipped through the air, with every line of code that must be parsed and executed, and with every AJAX request that shakes the radio out of an idle state just to ping your server. Conserve these resources as though you paid for them alongside your server bill rather than foisting the expense onto your gracious visitors. Ask for permission before doing something potentially battery-draining or bandwidth-consuming. Be a good steward of your users' resources.

Third, remember that the Web loves data. There is no question that with the tools and techniques available to the modern Web developer, the sky is the limit when it comes to how sophisticated a Web application can be. And this is a good thing. It is good to experiment, to push boundaries, to discover new and interesting things that were once considered impossible. But the Web exists for its users. Users rely on the Web for information, and it is information for which the Web must be a safe haven. If your work makes you a provider of such information, consider whether your time would be better spent looking for ways to make that information easier to view, easier to consume, easier to remix. Content negotiation has been a part of the Web since that very first proposal, and remains one of the great untapped veins of Web gold. A site that lets one view tabular data ensconced in HTML trinkets is acceptable; a site that shows a graph of that data or permits one to access it in raw, machine-readable form just by changing an Accept header is fantastic. Open data is the future, and the data-driven Web is how we can bring that future into the present.


The Web is one of the greatest inventions of the past several decades, and it can continue to thrive for many decades if those building on it embrace its original goals. Rather than chasing after the latest features available only to those living on the bleeding edge of browser support, we should invest in making our creations open to all, consumable by all, and welcoming to all. We should do this because the Web depends on us to shape its future, and because users from all over the world deserve to be included in that future. Let's make that future a bright one.