Hacker News new | ask | show | jobs
by reid 5735 days ago
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.
1 comments
steveklabnik 5735 days ago
> 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.

link
reid 5734 days ago
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.

link
steveklabnik 5734 days ago
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.

link
reid 5734 days ago
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.

link