Comment by rektide | Hacker News Reader

Comment by rektide | Hacker News Reader

It's exciting & unsurprising to me that state is such an unsolved problem.

For the longest time React was kind of in denial to a large degree about what they were. They called themselves a View library. Hooks have definitely noticeably changed that relationship, & how people integrate app state with React, but the problem here of updating hasn't really changed all that much.

It's not a new thing either. A lot of the initial resistance to React & the VDOM was that it felt like unnecessary work. Because so many frameworks at the time were working towards two-way data-binding systems, which aren't necessarily but were often associated with with smaller, precise DOM updates. HP/LG's WebOS's underlying Enyo project was one high profile would be effort here.

Signals have definitely been a good re-grouping point, for reconsidering what the shape of things might look like, for trying to do a better job.

I'm a bit surprised we're still operating so much at a library level regarding reactive systems/signals. JavaScript objects have quite a lot of flexibility already, and the addition of Proxies added a lot of capabilities. Faint/distanct memory, but I think Proxies were justification for killing Object.observe[1]: now users could do whatever they wanted, so we no longer needed a JS native way to see objects change. Yet, we're still very library based, rather than trying to make objects themselves better, more reactable.

[1] http://web.archive.org/web/20200218195131/https://developer....

There is context which wages a war against debugging and testing, for one thing.

React has no real answer to state going sideways.

Then there is controlled/uncontrolled component which is an example of structural instability (what looks like a tiny change to your boss is a bigger deal than it should be) unless you ride the crazy train and use “plain ordinary javascript” to build a parallel system to move (some of) the state around.

One of the main reasons I was so hopeful for Object.observe was because it would have been a stable language feature to build better debuggers around.

Instead, it feels like most state management libraries ultimately end of writing their own Chrome extensions. Which now that I say that makes me curious: do any of these executions also let you observe/monitor server-side state management systems?

You can often use route params or location hash for communicating state sideways if shared context is overkill, with the benefit of making the state bookmarkable or accessible in the history.

That's only sustainable for small pieces of state or some mechanism to exchange that small piece of state for a more complete piece of state.

Right, the problem with React is it has no global answer for application state, instead it provides a toolbox with which it is possible to set up your own state handling but frequently you face structural instability where a small change in your app’s functionality require large architectural changes.

> or some mechanism to exchange that small piece of state for a more complete piece of state

using links to refer to information is, like, not a totally foreign concept to the web (and certainly granted: in some cases this issue of signaling via url can get quite ugly; but often it's not).

If you are having trouble testing context, you are _definitely_ doing context wrong.

To test the context itself: pass as children of the context components to render the context state.

To test the components within the context: create a context with mock functions/values.

React has no answer to state going sideways because React manages a tree of components, and you are not supposed to connect random branches of a tree. That would completely break the concept of tree, container/contained, and just convert everything into a graph, and graphs are much harder to deal with. BTW, HTML is a tree, not a graph.

Controlled vs uncontrolled and the boss demanding a tiny change is just another case of bosses not knowing about how it works the system and imagining things and then demanding reality to conform to their imagination. Not an issue with React.

For the goals of the application you can push a button in one branch of the tree and it has an impact on many other branches…

That still means you have 3 different types of entities.

One where the event originates (knobs), one where it will gets translated into actual UX effects (DOM updates, API fetches, whatever, lets call these servos and gauges), and one place where the business logic lives that transforms between the low-voltage input signal and the high-voltage output driver power.

Without that transducer you have incompatible things.

Yes, many times this is a trivial thing, and that's usually when it can be done internally to the component.

That is one of the many partial answers that works some of the time but not all of the time.

For relatively simple applications you can push all the state high up to the root of the tree or near the root of the tree and have it flow down with props.

There is a complexity hierarchy and around the time people woke up to AJAX (there were a few years when it was just a ‘evil Microsoft thing’) I was writing apps that were highly dynamic, the extreme example is an IDE with property sheets or something like Adobe Photoshop where an arbitrary number of components need to ‘react’ when a piece of data changes. It is bad enough when there is a status bar and four other parts of the UI determined by management that need to be updated when a piece of data changes (could become five or six tomorrow). it is worse when the user can instantiate arbitrary components (say for a knowledge graph editor or a geospatial intelligence tool) that ‘listen’ to event changes.

Prior to 2010 I was building apps like that and developing special purpose frameworks to do exactly as you say in GWT, Silverlight and such. There was no support for such things at the time, no async/await, management and other devs had no idea of the ‘race conditions’ that could happen when data could either come out of a cached copy or get fetched.

In those cases I spent a while struggling to understand the problem and developed systems for handling state in complex applications so when I look at React, Vue and most of those (with the possible exception of MobX) I want to ask “where’s the beef?” because these frameworks are not adequate to the problem and people don’t seem to understand they are no adequate to the problem (it comes from Facebook, how bad can it be?)

Most of the reason why people think "React is OK" is that they are writing apps (99% of them) that are so simple they don't need React. If you're writing apps that really need React, than React doesn't seem OK.

> it is worse when the user can instantiate arbitrary components (say for a knowledge graph editor or a geospatial intelligence tool) that ‘listen’ to event changes.

Your application is effectively "anything can modify anything", which is the previous step to "anything modifies anything", I/E big ball of mud. React's answer to that is "keep all the state in a small component" (small ball of mud) or "keep the state in a tree" (one-direction bindings, prevent state graphs).

This makes React discourage (I/E makes harder and puts friction) graph-based state, as it is the most direct path to big ball of mud.

This doesn't solve your problem, but definitely helps push 99% applications away from the big ball of mud. The fact is that for your 1% case you need the big ball of mud, and, in your case, pushing away from it doesn't help.

I'll push back on that.

In those two applications I joined failing projects that really were a "big ball of mud" and got them working. I didn't just figure out a working solution to the async updating problem, I became intimately familiar with seductive non-solutions.

The problem with the discussion about React is that 99% of the use cases of React don't need to be an SPA. If it's possible to SSR your application you don't need React! Those applications I worked on were dramatically more complex than today's SPA because they needed to be SPAs!

Back in the 1990s people would define a web form in a static HTML page and then write a separate CGI script to handle the form. If there was an error in handling the form the CGI script was unable to redraw the form with an error message and the values filled in because the CGI script didn't contain the form.

Around 2000 or so people realized the answer to this was for the form to drawn by the same script as the form handler, and the script would choose to either draw the form or the next thing after the form based on the inputs it received. Ruby on Rails institutionalized this around 2005 and misappropriated the name "model-view-controller" for this.

Not long after 2010, for reasons I still don't entirely understand, the web design shops in my county transitioned from successfully writing quality RoR apps to attempting to write "simple" Angular apps. How to do error handling for forms on the server side got forgotten like the formula for Damascus steel and instead people started writing SPAs to do what would have been a trivial task in a server-side application except now the application is "a tiny pebble orbiting a supermassive black hole made out of dark matter".

People who are happy with today's SPA frameworks are happy because they are developing applications that don't need to be an SPA. Once you get into the range of applications that really need an SPA they let you down.

SPAs exist because of the developer experience and user experience, the support for complexity is an added bonus.

Everything can be done with SSR, but some things are terrible with SSR (oh, you need real-time updates? have some meta http-equiv refresh header, and observe the beauty of the page going blank and re-rendering every second).

Before you ask about the developer experience: it's about having developers that can focus their brainpower into animations and interaction design without having the expectations of having to know SQL.

4 letters. HTMX.

Or look at https://www.phoenixframework.org/ to see what a web framework would look like if real-time updates mattered. (That said I do find that simple IoT applications like a volume knob for my smart speakers in party mode or that can toggle my lights do work well with websockets + mobx + React.)

As for DX, I think waiting for "npm run start" to get out it's own way is a large enough decrement that I don't have to get into all the many problems w/ JS build systems.

I will grant that React is nice for an animation-heavy UI and I play video games enough that I appreciate such things. Another thing I like about React vs similar competitors is that the rendering model is flexible enough to enable things like react-three-fibers which is another reason for me not to invest in Vue, Svelte and things like that.

As for user experience isn't it the dark truth that Google and Facebook want "as many UI redraws as possible?" Let's face it, the honest clickthrough rate on ads is indistinguishable from zero but when you visit some site like anandtech it is by no means accidental that the layout rerenders endlessly because each rerender is a chance that a click on a link is transmogrified into a click on an ad. It's covert click fraud and is a large enough decrement and between that and the endless staring at spinners and waiting things to load any possible increment in user experience is at best hypothetical.

(e.g. in another window I have a completely SSRed app that uses HTMX. It uses zero spinners, runs as fast or faster than a desktop app, and never has the UI move around mindlessly. I grant it would be cool if it had some more animation but would I trade that for rock solid responsiveness?)

HTMX definitely chips at some of the use cases of SPAs. What percent of cases? I don't have that answer.

And yes, Phoenix is a very interesting thing, but it's most likely only viable because of it being Erlang under the hood (needs a process running for each client, hence ultra cheap Erlang processes being a good fit).

> when you visit some site like anandtech it is by no means accidental that the layout rerenders endlessly because each rerender is a chance that a click on a link is transmogrified into a click on an ad

I think you went a bit too far into the conspiracy theory there. An element for which the height is not defined (via HTML or CSS) gets rendered usually to 1x1 pixel, which forces a redraw if the element turns out later to have width and height (like an image that takes half of a second to download). Which, IMO, means web developers are not bothering to put sizes in delayed-loading elements, which points a bit more to the incompetence side than the malice side. But ads probably not specifying width and height would also indicate significant malice, can't rule that out.

the "MVC" nomenclature came from traditional desktop apps, no? RoR just followed suit.

So, I always "hated" RoR, because it was full of hidden conventions and regular black magic. At least PHP was globally simple and primitive, even if locally ugly and complex.

I still remember Misko's early(est?) Angular announcement video, it was just part of GTAC [google test automation conference], and the whole thing was about testability.

https://www.youtube.com/watch?v=gQclnI_8Vmg

It was seen as natural separation of concerns, it was seen as - finally - breaking free of the big bulky backend (of GWT and the shackles of semi-autogenerated frontend code) the frontend runs on the browser anyway, it needs to manage its own state anyway, etc, etc.

Of course this only emphasizes your point, that a good ~95% of the sites are not like this, they shouldn't even try to manage state on the frontend.

> Once you get into the range of applications that really need an SPA they let you down.

Yep. I wholeheartedly agree.

Reply on news.ycombinator.com