Notices by molily (molily@mastodon.social), page 2

My problem with an understanding of progressive enhancement as ”simply sprinkle vanilla JS on top of server-rendered HTML” is that it falls behind all robustness practices and abstractions developed in the last decade.

I had a similar impression when reading this article: https://www.jayfreestone.com/writing/web-component-libraries/
The conclusion disappointed me. Web Components either require manual wiring and low-level DOM code. Or they render full templates like Lit. This duplicates server templates unless you SSR.

The article didn't want to fall into the trap of implementing one feature twice on the server *and* with client JS. It avoids code/logic sharing. I agree it's fine to have pure client-side JS enhancements.

But I also think the fundamental question of PE & JS is how to build experiences where client-side JavaScript failure means falling back to lower-level enhancements and ultimately the server.
Modern frameworks like Remix revolve around solving these problems, for good reasons.

I get it – to introduce someone to enhancing progressively with JavaScript, you need an example that is simple yet complete enough to explain the design and implementation process: Identify core experience & enhancements, group enhancements, what to implement on server & client, how to apply enhancements etc.

I just find it hard, not to say impossible, to contrive an example that has practical value, good code while also teaching the architectural/design thinking of progressive enhancement.

But of course, if you are under the impression that the last decade was a lost decade for the web, you must claim that client-side JavaScript has not improved or evolved a bit since 2013. So you write code like in 2013. ?