Conversation

Notices

1. Embed this notice
   molily (molily@mastodon.social)'s status on Tuesday, 28-Mar-2023 22:51:20 JST molily

   in reply to

   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. ?

   • Embed this notice
     molily (molily@mastodon.social)'s status on Tuesday, 28-Mar-2023 22:51:21 JST molily

     in reply to

     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.

   • Embed this notice
     molily (molily@mastodon.social)'s status on Tuesday, 28-Mar-2023 22:51:21 JST molily

     in reply to

     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.

   • Embed this notice
     molily (molily@mastodon.social)'s status on Tuesday, 28-Mar-2023 22:51:21 JST molily

     in reply to

     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.

   • Embed this notice
     molily (molily@mastodon.social)'s status on Tuesday, 28-Mar-2023 22:51:21 JST molily

     in reply to

     Conceptually and structurally, this resembles jQuery + Handlebars widgets in 2013 but now based on Custom Elements.

     Totally agree with the article saying *nothing has changed*. “[Using Web Components is] not *meaningfully* different than simply passing a node to a constructor and listening for DOM updates.”

     That's what we did in 2013. And in 2003. I find it hard to grasp that people accept an outdated development model that produces error-prone sites.

   • Embed this notice
     molily (molily@mastodon.social)'s status on Tuesday, 28-Mar-2023 22:51:22 JST molily

     in reply to

     I'm glad more people are getting into progressive enhancement. Still, as someone who's deep into it, this leaves me puzzled for several reasons. I think we need realistic, non-trivial examples regarding PE & JS. Here we have a rather contrived example with one button/interaction. Not saying it has no educational value. It addresses many practical questions. Yet it's not particularly convincing. One could question this particular example or its implementation, but this would be pointless.

   • Embed this notice
     molily (molily@mastodon.social)'s status on Tuesday, 28-Mar-2023 22:51:22 JST molily

     in reply to

     More importantly, I find the high-level messages worth discussing.

     The crucial point for me is “[Enhancement] doesn’t mean unimportant. Enhancements can be critically important. […] Your primary value proposition might be an enhancement”.

     The other point is the rather technical definition of the “core experience” as the “value that you can provide when [everything but the server] breaks”.

   • Embed this notice
     molily (molily@mastodon.social)'s status on Tuesday, 28-Mar-2023 22:51:22 JST molily

     in reply to

     I kinda agree and appreciate that the article addresses this misunderstanding. But I kinda disagree as well? I, for one, am interested in progressive enhancement to get my product's value proposition implemented as robust as possible. IMHO, this is the business benefit of progressive enhancement and also my advantage over competitors with slow/brittle software.

     But again, it's hard to discuss such important architectural questions on the basis of simple examples, so I might be overthinking.

   • Embed this notice
     molily (molily@mastodon.social)'s status on Tuesday, 28-Mar-2023 22:51:22 JST molily

     in reply to

     In total, I think it would help to not discuss the progressive enhancement of non-products and try to infer/generalize the theory, but share what we have learned from enhancing existing products.

     This equally affects my writing on progressive enhancement which often focussed on trivial examples or was too theoretical. It often lacked stories about products I was actually working on.

   • Embed this notice
     molily (molily@mastodon.social)'s status on Tuesday, 28-Mar-2023 22:51:23 JST molily

     This is an interesting series on Progressive Enhancement & JavaScript:
     When JavaScript Fails: https://scribe.rip/@jason.godesky/when-javascript-fails-52eef47e90db
     A Practical Guide to Progressive Enhancement in 2023: https://blog.bitsrc.io/a-practical-guide-to-progressive-enhancement-in-2023-52c740c3aff3