I am convinced that progressive enhancement is the best solution to enhance the user experience. Many websites charge tons of useless Javascript for 80% of users, and do it in a bad way. Like mobile first, javascript must be seen as an additional layer of features added to an already functional website.

I am so happy to see your words out in the wild again it feels an eternity.

I’ve felt for a while that though many of us acknowledge that JavaScript should be an enhancement, we don’t know how to plan writing our pages, elements, components in a way that encompasses that.

If there are good coding examples of this methodology, it would be wonderful to share

Thank you Josh. this post is well written with a solid thesis. I have been reluctant to implement thick client for the reasons that you mention. You have given me plenty to consider.

Interesting article. Although I think the fat client/ fat server approach gives the best experience, I do not think it is most appropriate in most cases.

I recently implemented the pushState api on my own website, Ajaxing in all the content, yet retaining all the logic on the server. It was easier than I expected, but still slow, and tricky to work with. Key problems are loading in page specific resources (because the page head is not re-loaded, so link elements are out), and navigating away from the website and then returning from the back button (often the browser is unsure what to do). Remembering to do things like re-fire Analytics events can be tricky.

That said, I do think using this model is far more suitable for web app type systems (as opposed to more traditional websites), where you know from the start how each page is structured and what scripts/ styles are needed.

This article perfectly reflects my opinion on building robust websites, better accessibility, and the general state of the web… Probably the reason why most websites go for a JS only approach is the huge overhead when creating a robust server and client side solution. It’s like building two separate apps, and I think there’s still a lot of room for improvement. We’d need a development process that includes both without writing the same functionality twice.