But! There's still room for expertise. And this is where I disagree about swimming with the tide. There will be those who are uninterested in using the AI. They will struggle. They will hone their craft. They will have muscle memory for the tasks everyone else forgot how to do. And they will be able to perform work that the AI users cannot.

The future needs both types.

But consent is key. Maybe we need regulation that compels companies to disclose these manipulative techniques in digital services. Give people the chance to opt in or out.

But anyone who tries it without really understanding JS is eventually going to have a bad time. It’s important to know how to work with the event loop, how to properly use promises, etc. Server-side JS is a lot more unforgiving than front-end JS when it comes to these concepts.

The hard part is navigating the bureaucracy and building consensus toward a change. This management-craft is where the clever thinking and emergent solutions are found and deployed.

With that said, in my experience, many stand-up formats devolve into some version of "the two most talkative people have a conversation for 30 minutes while everyone else listens". I'd probably get more value out of doing a write-up than sitting through a meeting like that.

It really depends on the health of the stand-ups on the team.

In the following line...

> Hyphen - A custom element base class for great developer ergonomics.

...I would recommend adding a link on "custom element" that points to a definition somewhere. This might make it easier for skimmers to parse the meaning of this opening line.

And you're right about how connectivity changes over time. But how many people are on their bikes when applying for unemployment insurance? I just don't think most business apps benefit from this level of offline support. There are of course use cases for this! But it's not the common case.

My point is that if you're in danger of losing your internet connection, you're not going to be able to reliably get that initial JS bundle anyway.

Most of my users have old phones and bad connections. I've tried this JS-heavy bundle-first approach. It doesn't work.

The solution is way simpler than local-first. Just shrink every page and interaction. Fewer requests, little JavaScript (if any at all), low latency. Use static pages when possible. Even the oldest phones on the most remote connections can usually deal with a sub-50kb page all-in. It feels like people forget how simple web interactions can be.

I'm sure local-first can be great for highly interactive tools like Figma. But the grandparent is right. Most sites don't need anything close to that level of complexity.

* Fast builds are way more pleasant during development. "Incremental" per-article builds help, but not in all scenarios. Nothing kills my motivation faster than having to wait 30 seconds to preview a fix.

* Fast builds help us avoid jams in our automated push-live systems. Sometimes we have many editors updating pages during a big event. You could consider many different trade-offs when deciding how to manage these queues. But a fast build time erases a lot of those conversations.

We use 11ty on most of our sites. We've found 11ty itself to be fairly performant. The slugs tend to be everything related to processing assets: JavaScript bundles, Sass builds, image manipulation, etc. By streamlining those activities, we can usually get a site build down to just a few seconds.

That said, "instant build" is the dream that animates the best conversations on our team, and we've started building our own static site generator. Our SSG can run both on the server and in the browser. We want our editors in our CMS to be able to get instant, true previews of the page they're editing. Then we want to be able to push single-article builds live, instead of always rebuilding the whole site. It's early days yet. Maybe you'll see it on a "Show HN" some day.

This comment deserves some clarity.

Web components should not bypass server-side rendering. However, that server-side rendering should not come from the web components themselves. Rather, the "SSR" in this case should be the job of whatever generates the page HTML.

The page HTML should include default "slotted" content (inside the custom element's tag) to be picked up by the web component when the page loads. That's the best way to do progressive enhancement in web component land. Whenever I reach a point when I think, "Gee, I wish I could SSR this web component," I take it as a bad smell, like I'm probably not taking advantage of web component features.

Put another way, I wouldn't want to SSR a web component for the same reason I wouldn't want to SSR a

tag. The latter makes no sense, right? Web components are custom elements, and they should be treated like elements, and designed like elements.

> Web components certainly have their place and, used judiciously, can certainly add value. It's just essential to approach them with a nuanced understanding and not as a silver bullet.

Fully agreed with this, it should be repeated over and over. Web components can be part of a balanced diet but they can't be the whole meal.

Web components are superficially similar to React/Angular/Vue, but very different in practice. Different strengths. Different use cases. Different opportunities. Like the post says, the web components community has been terrible at articulating and marketing these differences.

This is false. Use