Wanting to build first without Javascript is not the same as hating it

I love Javascript. I used to hate it, and with good reason: for the first few years of its life, the only value it added for the user was it would crash their browser before a shitty, over-scripted website would have a chance to load and poke them in both eyes. Even then, it would rarely crash all browsers reliably. Even its crapness was not cross-browser compatible. Trust me: if you didn't experience Javascript in Netscape Navigator, you will never truly understand how bad things were.

But hidden beneath the bad implementations of Javascript was a good language, with functional behaviour and a richly sloppy prototypal object inheritance. And over time, those bad implementations have been gradually stripped off, as if by Acid, leaving more of the good language behind.

These days, with the rise of the new browsers, the creation of frameworks like jQuery, and the imminent demise of IE6 (with IE7's life support being tied to obscure OS versions), one can rely more and more not merely on Javascript being available, but also on it behaving well. For the record, I fully support the removal of the "disable Javascript" checkbox from Firefox, if only because there exist checkboxes that kill your product, and I want Firefox to live.

With all this in mind, it's important to still be careful with your use of Javascript. However well browsers these days might do Javascript, they will always render HTML and CSS better. Treating the last two as languages, which they are: HTML is a better supported language in the browser than Javascript. That means that, if your website is content-heavy and predominantly static, then even these days your website should still work without Javascript.

Regardless of who will or won't have Javascript switched on, it's simply the optimal way to think about content delivery to the browser. If your website is not wholly a Javascript application, then it's probably a content-heavy site serving semi-static pages. This is ideally solved by treating HTTP as an API for delivering content for the browser.

But if you then make the browser's display of this content somehow dependent on Javascript you have violated a basic principle of separability of your code: not only can debugging then be much, much harder; but also if, later on, you find some horrid bug likea memory leak in your Javascript, you have no fallback position. You cannot switch off the Javascript in the mean time, because you've set things up not to work that way. HTTP is, for you, no longer an API, but internal function calls, dependent on your own architecting. And the site, which could have worked OK without Javascript if only you'd architected it differently, will remain broken until a fix is rolled out.

And if that ever happens to you, then remember progressive enhancement, and consider how it could've all worked out so very differently; by which I don't mean we should all still be using Netscape Navigator.