> These "we cut 70% of our codebase" claims always make me laugh.

There's also a slide in my talk that presents how many JS dependencies we dropped, while not adding any new Python. Retrospectively, that is a much more impressive achievement.

... but the whole social movement of "back to the backend" is about getting rid of the client-side application as a separate component

of course it (should) lead to a lot less code! at the cost of completely foregoing most of the capabilities offered by having a well-defined API and a separate client-side application

... and of course this is happening as over the last ~2 decades we mostly figured out that most of that amazing freedom on the client-side does not worth it

... most clients are dumb devices (crawlers), most "interactions" are primitive read-only ones, and having a fast and simple site is a virtue (or at least it makes economic sense to shunt almost all complexity to the server-side, as we have fast and very capable PoPs close to users)

> ... and of course this is happening as over the last ~2 decades we mostly figured out that most of that amazing freedom on the client-side does not worth it

It's not that, at least in my opinion, it's that we love (what we perceive as) new and shiny things. For the last ten years with Angular, React, Vue et al., new waves of developers have forgotten that you can output stuff directly from the server to the browser outside of "APIs".

This implementation is "dumb" to me. Feels like the only innovation is using SSE, otherwise it's a `selector.onClick(() => {selector.outerHTML = await (fetch(endpoint)).json()});`. That's most of the functionality right there. You can even use native HTML element attributes instead of doing .onClick https://developer.mozilla.org/en-US/docs/Web/API/Element/cli....

I really don't see any benefit to using this.

Cool how do exponential back off, make sure that it auto connects on tab visibility changes, make sure when you replace stuff it keeps the same selection. I'm sure if you had enough of these you'll end up with 10 kilobyte shim

Ok? Not sure what's your point. I'm not saying the package is bloated or anything. I'm saying it's a very simple functionality that was considered an anti-pattern when Angular and React were coming up.

sprinkling event handlers all over and doing DOM manipulations and trying to pile jQuery plugins on other plugins ... that was the anti-pattern

saying nah, fuck this, let's just do a rerender is what happened, and going back to doing it on server-side is one way, but doing it on client-side is the "React way"

I don't know how old are you but I distinctly remember how big of a hard on everyone had for Angular and then React and virtualdom. React actually brought some good things in how you engineered your frontend code. This thing goes back on that completely and forces you to mix and match your frontend code on both the frontend and the backend. I genuinely don't understand how one could seriously consider this for a large application.

I started with FrontPage '98, and copy-pasted DHTML into the source code soup to have falling snow on my homepage for the winter.

I have also no idea why people love template spaghetti! But of course it can work, and simply setting the bar lower might actually help projects against feature creep.

They said it’s from React, just the fact that you don’t have to deal with virtual DOM is almost guaranteed to get a 50% reduction