[lukifer]

If your web page is a simple marketing site, blog, or e-store, then I completely agree.

But if your web page is a complex application, having to support no-JS either shuts you out from from a huge set of interface tools, or forces you to maintain two interfaces in tandem. To me, 2% doesn't justify that, particularly when you can just politely inform the user that their browser has a significant feature disabled, and inform them how they can remedy the situation so that your site works.

[mirkules]

I agree with you and the posters below that you can't develop two versions. But I'd like to point out that "it doesn't work because JS is disabled" versus "it's not pretty because JS is disabled" are two different things, and they are not mutually exclusive. There are a slew of sites that work without JS even though they depend on it for "fancy" stuff. Plus you don't have to support two different sites in tandem, it's not exactly 100% more work. For example, instead of an AJAX call (which returns content), display the content in a new page, i.e. Slashdot's comment system -- when JS is turned off, clicking on a comment opens it up in a new page.

[bmelton]

You're overlooking a lot of powerful applications that need SOMEthing to work client-side. Markup.io, recently featured here, is not the sort of application that can post-through to another page to fix. One could argue that it might also work with Flash, or ActiveX, but I'm only even mentioning them to head off somebody else from doing so, as that's hardly a solution.

I suppose it could be implemented as an Applet, but what's important is that Markup.io is exactly the sort of thing that Javascript exists for, really. And yes, disabling JS will break it, completely, and yes, I think that's perfectly forgivable.

On the whole, I agree that my blog should degrade, and data-entry type applications should work as well, but saying that everything should is completely overlooking an entire category of application for which it's perfectly acceptable, in my opinion.

[mirkules]

Ok, good point. My problem is sites where it is reasonable to expect them to work without JS, but end up not working at all. I would never expect a specialized site like Markup.io or asteroids-on-a-page (forgot the name) to work without JS. News sites, portals, blogs, shopping sites, etc, are all fair game for no JS (like you said).

By the way, not sure if you're the author of Markup.io, but it's pretty cool.

[bmelton]

Oh, no I'm not even remotely connected to it, it was just the first example that came to mind.

It is pretty cool though.

[prodigal_erik]

Markup.io isn't actually a part of the world-wide web of linked semantic documents. Its content is inaccessible (even for viewing) unless you blindly trust its code. It rightfully deserves to be a browser plugin, it's just cleverly smuggling itself into everyone else's content because there are no good portable extension mechanisms for browsers.

[lukifer]

> because there are no good portable extension mechanisms for browsers.

...which is why JS is filling that gap. :)

[reid]

Even if your users have JavaScript enabled, they still need to download and run it before using your complex application.

Consider GMail. How awesome would it be if you didn't have to wait for its "Loading..." progress bar? It takes 2-4 seconds for that to go away on my computer. If you design for progressive enhancement, you can interact immediately and when JS is ready, it simply enhances what's already there. If done right, it's all the same interface.

If you don't mind waiting, your users may not agree: Google and Amazon both have noted significant losses in revenue at page delays much shorter than 2 seconds.

[steveklabnik]

> Consider GMail. How awesome would it be if you didn't have to wait for its "Loading..." progress bar?

Well, taking a look at "Basic HTML view"... considerably less awesome.

[reid]

My point was that Google solves this problem the wrong way.

Instead of making two interfaces, they should make one interface. If JavaScript hasn't loaded yet (or if it's disabled), the majority of the interface can still be available immediately.

JavaScript should always add to the experience. It doesn't make sense to show GMail's Chat widget until JS is loaded-- but it really doesn't make sense to show nothing at all until the Chat JS downloads and runs!

You should be able to show the message list right away. You can start scanning your messages immediately. You can click normal links and submit forms.

Bonus for JS enabled users: a few seconds later the links, buttons, etc. all get hooked up to JavaScript. The Chat widget appears. By the time you click, things may even happen all AJAXy-- and it appeared to load instantly by loading JS in the background.

Now that's awesome.

[steveklabnik]

But what about features that _need_ JS to work? Should they be in the interface until the JS loads and they work? Then when I try to use them in the first few seconds, they're broken. If they're added afterwards, they just pop into existence...

I don't mind waiting the second or two.

[reid]

No. Those features should not be in the HTML markup if they are bonuses that require JavaScript. At least, they must be hidden until its script loads. But you shouldn't have to hide everything.

I'm pretty happy browsers don't show a big "Loading..." message until everything is loaded instead of painting the page as soon as possible. Shouldn't we be avoiding that too?

The bulk of that interface can be progressively enhanced.

For example, the message list and side navigation can be normal links. When JS comes along, they get actions (show this view, show this message) that override the default actions of those links (navigate to the page /message_view?id=foo).

If you try to use them in those first few seconds, they act as normal links-- they aren't broken, they just weren't enhanced yet. You can start using the page faster.