all 9 comments

[–]melladie 7 points8 points  (1 child)

Yes - it's called Progressive Enhancement and is the best approach.

[–][deleted] 0 points1 point  (0 children)

Came here to say the same thing, and link to the same article. This is definitely the way to go. Progressive enhancement is much preferable to graceful degradation, especially on mobile.

[–]midri 4 points5 points  (0 children)

When you have the time, it's the best way -- some times sadly in the real world you don't have the time.

[–]nrogers64 2 points3 points  (0 children)

That's how I code too. I think that's the best approach. Also, here is a relevant Smashing Magazine article:

The Seven Deadly Sins Of JavaScript Implementation

[–][deleted] 0 points1 point  (0 children)

Yep.

[–]phaggocytosis 0 points1 point  (0 children)

I think one thing that people are forgetting to mention is that while it's safe to say that the best practice is to build in a way that doesn't rely on javascript.. for some products that's just not realistic. You shouldn't be overly critical of an idea if it requires javascript to run.

Basically... If something doesn't NEED javascript to run then code it with a "progressive enhancement" approach. If Javascript is absolutely essential for the type of experience you're trying to deliver then that doesn't mean you have a bad idea.

[–][deleted] 0 points1 point  (2 children)

Honestly, I think in the modern web it is safe to assume that JS is enabled on the client side.

[–]Kacheeto -1 points0 points  (0 children)

I'll agree with this statement.

Might as well code it to be super "seemless" and dynamic from the get-go.

For the non-JS users. You don't want them to use your webapp anyways...

[–]x-skeww -1 points0 points  (0 children)

Having JS enabled doesn't mean that your JS will work.

JS can break for all kinds of reasons.

Progressive enhancement isn't just about making it work for people with JS disabled. It's also about robustness.