> The master Render() function draws all of the graphics according to the current state
What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source".
React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves.
This is why people came up with things like Flux/Redux/Reducers/Immutability, to handle this in a standardized way, but nothing is necessary.
>components should be simple and not store data in themselves.
That is a ”controlled component” model which is bad for interactivity, especially text inputs.
If every keypress triggers a state change and rerender, the UI will be slow and things like focus management become complex issues.
Without a rerender, it must now use a reactive binding to update the field value.
If you don’t want to update state on every keypress, your component must be uncontrolled, store its state internally (in the DOM) and update it to a parent store e.g. when the user stops typing (debounced) or moves focus out of the field. These are not trivial things either, and as a result, components get more boilerplate to handle the UX complexity. And of course, there are now UX pitfalls.
Indeed, these are reasons why reactive patterns exist. Now, if they just managed to abstract away the tedium.
I don't know what people generally recommend now, but for a long time the best practices with organizing React components had them connected to the store midway down the tree or higher, which definitely would have contributed to the UI slowness since it would rerender everything below that on each update. Push the store access down as far into the leaves as possible and you won't get anything noticeable, even though it is still doing more work than just accessing the DOM state as needed.
Also, focus management isn't really a thing in React, the vdom diffing means DOM nodes are updated instead of replaced so focus isn't lost or changed unexpectedly. There used to be a demo on the React homepage showing this, since the idea was very new to most people at the time - everything popular before it was just rendering template fragments to replace nodes and did have this problem.
> React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves.
"just" is doing a lot of heavy lifting here. Where do you store "pure" GUI state (button state, is expandable expanded, …)? Do you really want to setup Redux for this? (And no, the DOM is not an option in non-trivial cases.)
Might be naive, but this has always been a concern of the view-model for me. Every GUI change results in a VM change via event/command. The VM becomes gospel for UI state which means reducers are much simpler, and my actual model doesn't care if it is indeed a button, expando, radio button or whatever else.
Yes but it is easy to abuse/misuse IME, in that I think it requires one to maintain your own sense of discipline for the principle separation rather than the library/framework guide you into it. The threshold between UI and state management is comically easy to confuse.
Not dismissing it, mind, that inherent guidance is not something that is easy to achieve and I much prefer working with the likes of React than without.
I'm not defending this model anywhere. I'm just stating that React can do what applfanboysbgon suggested: "As a game developer working in my own engine, UI is unbelievably straight-forward: [...]"
> Here, we leverage the “quantum” feature to get exact pulse timings without resorting to cycle-counting
This is just a hard-real-time constraint that already exists in today’s computers and other devices.
For example: Audio playback and processing are a day-to-day operations where hard-real-time guarantees are necessary for uninterrupted playback, and every digital audio device already conforms to it. If the buffer is too slow you get playback errors.
People aren't criticizing the development philosophy in this subthread. This has been done by the article itself and by several people before.
What people are criticizing is the approach in pushing this philosophy into the ecosystem for allegedly personal gain.
The fact that this philosophy has been pushed by a small number of individuals shows this is not a widespread belief in the ecosystem. That they are getting money out of the situation demonstrates that there is probably more to the philosophy than the technical merits of it.
Agreed, it's an ecosystem-wide challenge. But React's dominance effectively cemented the 'build step as default' paradigm. When an entire generation of developers learns to `npm install` before understanding the DOM, the penalty for third-party drift gets baked into the architecture early. Delivering raw ES modules over a CDN structurally forces a lighter dependency footprint and pushes complexity to the edges.
Atomic packages brings more money to the creators.
If you have two useful packages it's hard to ask for money, even if they're used by Babel or some popular React dependency.
If you have 900 packages that are transitive dependencies the same couple deps above, it's way easier to get sponsorship. This is a way to advertise themselves: "I maintain 1000 packages".
The first guy that did this in a not-nice way was a marketing/salesperson and has mentioned that they did on purpose to launch their dev career.
TLDR: This is just some weird ass pyramid thing to get Github sponsors or clout.
My introduction to their Sriracha was in 1994, when the Puerto Rican cook at the Italian restaurant I worked at sent me to Stop and Shop for the "rooster".
Till hosing their relationship with Underwood Ranch (their sole provider of chili's) this was the only product in the marketplace (much like ketchup was always Heinz for a time). Absolute market dominance wrecked over not honoring your handshake deal with your ONLY supplier.
The latest batches by them are green, and no one wants them. The underwood version of the product is taking over --- it has a giant dragon on the bottle now, and what I look for now rather than the rooster.
I had a PM that was unable to work without AI. Everything he did had to include AI somehow.
His magnum opus was 30 extremely large tickets that had the exact same text minus two or three places with slight variations. He wanted us to create 30 website pages with the content.
The ticket went into details such as using a CDN, following the current design, writing a scalable backend, test coverage, about 3-4 pages per ticket, plus VERY DETAILED instructions for the QA. Yep: all in the same task.
In the end it was just about adding each of the 30 items to an array.
I don’t know if he knows, but in the end it was this specific AI slop that got him fired.
If you don’t have an engineering manager or tech lead able to back you on saying no to a PM, there is something seriously broken with that organization.
I recently had to clean up a mess and after days asking what’s in use and what’s not, turns out nothing is really needed, and 80 tracking pixels were added “because that’s how we do it”.
What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source".
React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves.
This is why people came up with things like Flux/Redux/Reducers/Immutability, to handle this in a standardized way, but nothing is necessary.
reply