When I was but a fledgling web developer, JavaScript was a toy; a little bit of DOM manipulation (or DHTML, if you will) was about as good as it got. It certainly wasn’t being used to make full-blown client-side (or indeed server-side! 1) applications, and if you told someone you were going to generate all of your content using it, they’d probably have laughed. For one thing, writing even the simplest JavaScript was a nightmare to get working in all the browsers available — even when you only cared about supporting two of them 2.

Fast forward to today, and the JavaScript landscape is somewhat different. You’d be hard-pressed to find a modern website without a “ tag somewhere. Fortunately, browsers have by and large reached a point where there’s a broad consensus on standards, and we have a whole host of libraries that deal with the shadowy bits that nobody likes to talk about. Adding advanced functionality to our websites in 2013 is so easy we almost don’t need libraries any more!

Unfortunately, it seems that JavaScript is being somewhat taken for granted. While it is true that the percentage of end users around the world without JavaScript is somewhat negligible (0.5% to 2%, as of 2010), the end user’s settings are far from your only problem.

Even the best developers make mistakes (though we all run tests against our code, right?!), and an errant comma or a small change to the HTML can leave our JavaScript out in the cold. It doesn’t even have to be your error; you don’t know what might be happening over the wire, and as for those ads you’re serving…

Full-scale web apps aside, relying on JavaScript for core functionality is a bad idea 3. And serving your user with an empty page, with the intention of filling it in later, is a big no-no. No ‘if’s. No ‘but’s. No ‘maybe’s. Even if your code is perfect, you may well find the server you’re pulling your content from unavailable (DNS issues, anyone?), leaving your user with nothing. You’ll also have a hard time getting those search engines to index that nice, clean, well-formed empty content of yours.

When a URL is requested, serve the content that lives there. Please.

  1. Well, that’s not strictly true.
  2. Hah… supporting both? Who am I kidding?!
  3. There really is no reason not to have a nice form somewhere to let your users log in, even if they rarely see it.

Your email address will not be published. Required fields are marked *

HTML is not allowed (it'll appear as typed), but you can use Markdown instead. For the unitiated, paragraphs will be auto-inserted, but links won't be converted unless you [write them properly](http://example.com/).