What's reactivity in this context? How quickly a website responds? My personal experience is that fast backends with server side rendered HTML and a bit of dynamic sections are in practice MUCH faster than SPAs, 20 years after using Gmail for the first time. Gmail then was fast, 95% of modern SPAs are slow.

"State management" is a fancy way to say "your Javascript stores data in variables in some way, which are updated as and when needed".

"Reactivity" means "when those variables change, some generic code already exists to update the DOM instantly". As opposed to writing specific pieces of code to make those changes directly.

Unfortunately, with React, "updating the DOM automatically" generally means: you update the data; React recreates the entire DOM as a new copy in memory; React runs a diff checker to find out what changed from the real DOM; React makes each individual change in the real DOM. With React (or other virtual-DOM-centered alternatives) being used for the smallest of web projects, so many small sites do all that work when the procedure ought to be as simple as: you update the data; you update the DOM directly.

It comes down to inexperienced devs not being able to consider which tool is best for the job at hand, and just hammering nails into every web project in the same way.

I mean all you have to do is change the framework to a better one. Vue with Vapor mode, Svelte, Solid or Preact. These don't have a VDOM at all or use a super fast minimal one.

Signals are basically as fast as writing event handlers yourself but way less fragile and verbose. React is just shaping everyone's impression of all JS frameworks because it's very popular and very slow.

I used to be Reactpilled, but ever since I've tried Svelte, I haven't gone back.

Reactivity is updating the DOM whenever the underlying data is updated. That's one of the most basic reason for existence of all js frameworks. There's TC39 Signals proposal to bring that natively, but for now as said above the choice is either use a framework or recreate one. It's surprisingly easy nowadays using Proxy.

It’s always been easy to reactively update the DOM. I was doing that in vanilla JS before HTML5 had been formalised.

What the frameworks do is take this concept one step further to create a SPA (single page application) but I honestly think they’re an antipattern that needs to die.

The problems are ownership and provenance mainly, and that all DOM access is slow and requires syncing code internally.

Anyone can write code that tweaks nodes or uses templating, but doing it in a consistent way on a project with hundreds of thousands linea of code is challenging, especially if you also need performance and everyone's least favourite child: accessibility.

Sure you don't get some of this with frameworks, but they help a lot.

Well yeah, obviously frameworks are intended to provide a standard interface for projects that scale. But you’re describing a different problem to the one originally argued.

> Reactivity is updating the DOM whenever the underlying data is updated. That's one of the most basic reason for existence of all js frameworks.

Most web apps and websites do not have that much state variables (even though it may be a lot of data). So while React may offer a small dev speed boost, it’s consumed by the need to build stuff and a whole deploy pipeline to nurse.

Libraries like HTMX and Alpine can take care of most the boilerplate for old style imperative patterns. And backend frameworks like Rails, Phoenix, Laravel donhave their own implementation for data updates.

How I've done it is to use some kind of observer pattern, where you register listeners to state changes.

Whenever state is updated, the listeners are all called with the updated state and can update the UI and what not based on the new state.

I haven't profiled this and compared it to frameworks, but feels adequate for the relatively simple UIs I've done.

In a way that's where all frameworks start.

I click the upvote button and a number goes from 0 to 1. Somewhere else on the page a banner gets displayed saying you have upvotes.

Your javascript can target those 2 divs, ala doc.getElementById(counter).innerHtml and document.createElement.

Like that kind of works for simple stuff. But it gets more complicated fast. Reactivity is when your counter listens for change in the count and updates itself whenever that count changes.

That's why you wouldn't target those 2 divs directly, but have one dedicated place, in which you update the divs and call that place from any other place that needs to update the 2 divs.

Well, that's simplifying the situation, but as those situations become more and more in ones site, at some point one might switch to a mediator pattern, which kind of is very close to signal emit and listening for signals.

For this specifically I would have the "you have upvotes" banner in the dom already with a class display:none.

I consider it a huge advantage to have the code for both the counter and the banner in the same place. thisCounter++; thisBanner.className = "shown";

... But vanilla JS with the DOM already has event listeners... ?

You still have to set them up and twar them down and update the display in disconnected places.

Works well for a small bumber of things to update, quickly becomes unmanageable.

How many sites actually need reactivity? For most sites you can either use a bit of vanilla javascript or htmx.