[const_cast]

What's the business usecase for incrementing a counter?

We can sit here all day and think up counterexamples, but in the real world what you're doing 99% of the time is:

1. Presenting a form, custom or static.

2. Filling out that form.

3. Loading a new page based off that form.

When I open my bank app or website, this is 100% of the experience. When I open my insurance company website, this is 100% of the experience. Hell, when I open apartments.com, this is like 98% of the experience. The 2% is that 3D view thingy they let you do.

[lelanthran]

> What's the business usecase for incrementing a counter?

Notification count in the top right?

Remaining credit on an interactive service (like the ChatGPT web interface)?

So, maybe two(!) business use-cases out of thousands, but it's a pretty critical two use-cases.

I agree with you though - do all normal HTML form submissions, and for those two use-cases use `setInterval` to set them from a `fetch` every $X minutes (where you choose the value for $X).

[yawaramin]

Notification incrementing is not purely client-side state though. It's triggered by an event coming from a server. Eg let's say you're on a product page and you click 'Add to Cart'. You want the cart icon's counter badge on the top right corner of the page to increment. With eg htmx when you click 'Add to Cart' we send a request to the server, it updates the cart state in the backend, then sends an HTML fragment response that updates the necessary parts of the page, including the cart item counter badge.

[const_cast]

In my experience it's just exceedingly rare to require this. My insurance company website has a notification thing, and it's actually static. You need to refresh the page, and considering how few and far between notifications are, and how common refreshes are, it works fine.

There's an entire domain of apps where you truly need a front-end. Any desktop-like application. Like Google Sheets, or Figma. Where the user feedback loop is incredibly tight for most operations.