Notices by molily (molily@mastodon.social)

Fakt: Mittelaltermarkt heißt auf Niederländisch »extra belegen markt«

#deutsch #niederländisch #übersetzung #duits #nederlands #vertaling

I think noone really has a clue, not me, not you. Last year I wrote that we need to stop with sermons, insults and self-righteousness. We need to convene in respectful and productive ways to make radical changes. These are still my two cents.

Unpopular opinion in these corners of the internet:
The current state of client-side JavaScript usage on the web is so abysmal *also* because the criticism of said state is so abysmal.
As someone who tried to intervene to improve the state, I don't exempt myself from this verdict. If we want to make any progress, we need to start with this confession.

There are so many truisms that crumble when the tire hits the road.
Use the Platform, HTML First, Progressive Enhancement, UX over DX, Vanilla JavaScript, Web Components, Hypertext/Hypermedia, HTML over the Wire, Resumability, Islands, Server Components or whatever the new savior is supposed to be.
Some fundamental principles and certain techniques are useful. Unfortunately they are often sold with the same zeal, marketing and superficiality as the next JS framework.

I think there's much room for debate. So many questions need to be discussed in nuanced ways. Social, organizational, economical questions. Not only technical.
Instead, people present silver bullets and jump to conclusions.

Human brain: Benutzer*innen
Planet brain: Benutzer∗innen
Galaxy brain: Benutzer�innen

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

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.

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.

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

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.

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.

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