[Lazare]

It's a hard choice.

I was recently involved in a project that was heavily focused on progressive enhancement - we started with a "standard" HTML app with forms and submit buttons. Every interaction required a full page load.

Then we started using Javascript to enhance the UX in such a way that it still worked without Javascript. It was a long and tricky process, because progressive enhancement is inherently quite fragile. You are basically taking an app, and then monkey patching it at runtime to be a different app. This is hard. :) Any change anywhere ripples through the whole app, and the entire thing is an offence against DRY; you are duplicating logic over and over and over.

Still, after a lot of time and effort... ...we gave up. We just couldn't get a slick, user friendly experience with JS, without the site breaking without JS. And frankly, the UX without JS was terrible anyhow. We rewrote the thing as a SPA (single page app). The codebase is much simpler, and the UX is great. :)

For us, the biggest pain point is our initial design had a server the emitted HTML; and accepted forms POSTed back to it. To enable AJAX, we then needed to duplicate a bunch of functionality so it would accept and emit JSON as well; this led to major headaches trying to keep all the logic in sync. If you DO want to maintain progressive enhancement...you need to figure out your site design from the start; it can't be an afterthought! If it's a complex project, you will live and die by your ability to keep your code DRY and enforce Seperation of Concerns.

[kls]

You would have saved a lot of time and frustration by building the single page app first and putting analytics on it to see how many non-JavaScript clients you where getting (most are surprised at how few the number is) and then if the number justify it, build out an older style UI separate from the modern web app that just proxies data to the same REST services, then use a sniffer to decide where each client goes. This is a simpler solution than trying to layer on dynamic functionality while trying to support the least common denominator. 9 time out of 10 though, when faced with the decision, the effort to chase older browsers is better spent chasing a larger market like Mobile.

[Lazare]

I know! :( It was definitely a learning experience.

And in regards to your comment on mobile: Agreed! Not only is getting a slick mobile client a much more important use of resources that stuffing around with progressive enhancement, but a good JSON/REST API is really really helpful when it comes time to get a mobile app working.

Thinking of webapps as client-server applications communicating via a JSON API is really helpful at the moment, I think.

[kls]

Yes many people make that leap after a first iteration, but once you do the pattern becomes very clear and very powerful. Looking at your back-end as a platform for all future clients really helps as well.

[drostie]

Yeah, I should expand on this and say that, if you want your page to be bilingual, it helps to have a central gateway through which your data will pass. If you know that you're going to want to request X, Y, and Z as JSON later, then there should be an intermediate form of the data as something which you could easily serialize into JSON -- and your HTML pages are then just a particular loose-and-quick view of that data.