[picardo]

> For massive apps with 1,000 components on the same page, maybe React's complexity is justified. But what the other 99% of apps?

The number of components is not the only yardstick of complexity. Most of the complexity in building a UI comes from state management and how state changes are propagated across the store and the UI.

I worked with Backbone for many years, and I can distinctly recall the hours of frustration I had debugging a UI because it was freezing due to cascading state changes. That was because we were using Backbone Store, which had bidirectional data flow, and when one updated the store, it would trigger a change to the UI, which would change the state store, which would change the UI, etc.

You could argue that the real innovation of React was "unidirectional data flow," but React team made Flux architecture central to the framework, making it easier to adopt good practices, whereas Backbone remained store agnostic and even encouraged Backbone Store which used the observer pattern for many years. I think you should choose a framework that allows you to fall into the Pit of Success, and React was that framework at the time, and for my money, it still is.

[ruszki]

People don’t or even can’t remember how was front end development before React/Flux/Redux. You could easily had problems with state management even with less than 1000 LOC simple pages. Of course, you could mitigate it, but it wasn’t trivial at all.

[hungryhobbit]

Look, I wrote one of the only published books on Backbone, and it will always have a special place in my heart, but ... the OP has no idea what he is talking about.

Backbone employed a two-way data binding flow. You're responsible for updating the models (ie. state) (way #1) when the user triggers events, AND you are responsible for updating the DOM whenever the models (ie. state) changes (way #2).

In React, they used a revolutionary new paradigm (flux), making it so you only worry about one direction (updating the models/state in response to events); you never render anything (React renders everything for you in response to state changes)!

If you've tried developing a non-trivial site with both, it quickly becomes apparent how much that one difference completely simplifies a huge aspect of development.

[CaptainOfCoit]

I remember watching one of the first React demonstrations/talks, and the biggest selling point was literally "You have a web page with various elements, and some of them needs to keep in sync, at Facebook we have chat messages and notifications, and they need to be in sync regardless of where you are, even on the same page, how do you solve that?" and then outlined how having one place for the state to live solves that issue without resorting to two-way data-bindings, instead data only flows in one direction.

Not sure if React isn't being presented as such anymore, but that's still the problem I see React solving, not more, not less.

[treve]

Yeah I would argue that it's possible to do it well with Backbone, and you end up with something much leaner but it requires a really strong understanding of state/event flow and lot of discipline, whereas with React the correct way to handle this is the 'obvious' path, which dramatically lowers the barrier to entry.

[Marazan]

You just need 2 components with bidirectional binding to enter a world of hurt.

As you say many people do not understand how important, vital and bizarrely _non-obvious_ uni directional data flow was.

[sibeliuss]

Everything was so hard. Everything! Backbone was kinda fun to write though, I'll admit. But not fun at scale to manage.

[panphora]

Author here.

I appreciate the point about unidirectional data flow solving real problems, but I think we're trading one complexity for another rather than actually simplifying things.

Yes, cascading state changes with Backbone Store were frustrating to debug. But React's abstractions introduce their own set of equally frustrating problems: stale closures where your click handler sees old state, infinite useEffect loops because an object in the dependency array gets recreated every render, mysterious input clearing because a key changed from stable to index-based.

The difference is that Backbone's problems were explicit and visible. When something broke, you could trace the event handlers, see what fired when, and understand the flow. The complexity was in your face, which made it debuggable.

React's problems are hidden behind abstraction layers.

I'm not saying React doesn't solve problems. I'm questioning whether those solutions are appropriate for the 99% of apps that aren't Facebook-scale. Sometimes the explicit, verbose approach is actually easier to reason about in the long run.

[sibeliuss]

Yes, applying compositional patterns and one-way data flow is most appropriate for all apps, independent of scale. Why? Because developer A (author of app x) leaves company. Developer B gets hired. Developer B is onboarded in an afternoon because things can be understood at a glance thanks to functional patterns and one-way data flow.

Having built many large-scale Backbone apps, anytime someone new came on board it was really very, very difficult, no matter how many design patterns one applied.

React's innovation was making FP mainstream. And then teaching the value of simplicity, as a principle. And yah, if something broke, it might be a little opaque, but at scale and in general, things broke _way less often_.

This is also the reason why most devs are full-stack now. Back in the day backend devs wouldn't dare touch FE code, and now its "not so bad", and pretty much anyone can work all over the stack.

[rk06]

Those problems of react are only react's problems. Other js framework like vue/svelte/solid do not suffer from them.

You can use other frameworks for the other 1% of apps

[wooque]

>which had bidirectional data flow, and when one updated the store, it would trigger a change to the UI, which would change the state store, which would change the UI, etc.

You can hit the same problem with React. Circular state updates. State change->trigger useEffect->change state. I hit those when I had just started React.

[lmm]

You can, but it's harder, React will at least nudge you away from doing that.

[azangru]

> You could argue that the real innovation of React was "unidirectional data flow"

Isn't this just how the DOM works? Data flows down through attributes and properties; events bubble up?

> but React team made Flow architecture central to the framework

Didn't they call it Flux rather than Flow?

[flufluflufluffy]

The native DOM doesn’t have an idea of “data flow”, it’s just a big tree that you can modify in whatever way you see fit through its imperative API. For example you could add an event handler to a child node which directly modifies one of its ancestor nodes. With React, your “nodes” in the tree are functions. The child node has no idea about what its ancestors are, it only knows what it is passed as arguments (i.e. “props”). The only way implement a similar thing would be to raise the state/event handling code to the ancestor node, and passing relevant information down as props, thus giving the unidirectional data flow. Of course, if you really needed to, you could drop back down to the native DOM API, with React’s useRef and useEffect hooks, but the default behavior is this unidirectional data flow through function composition.

[picardo]

> Isn't this just how the DOM works? Data flows down through attributes and properties; events bubble up?

That's right, but this communication pattern causes serious complexity. Imagine trying to find out what triggered a state change. You would have to listen to every event source to find out. With Flux, all state changes were mediated by the reducer in the store. It made things a lot simpler.

[picardo]

> Didn't they call it Flux rather than Flow?

Ah, you may be right. It's been a long time.

[paulddraper]

There is no notion of components in the DOM (or at least there wasn’t, until after React), so there’s no sense of data flow.

There is a DOM tree, but parents don’t pass data into or receive events from children.

[austin-cheney]

Components are themselves a form of added complexity. The idea is to deliver a composed and self contained code island. To accomplish this you have a big ball of markup, presentation, event handling, business logic description, and then security and accessibility logic to compensate for the prior mentioned abstractions. What you see in your editor may not look like much, but just under the hood is a colossal mountain of foolishness.

Why do people prefer this? It doesn't increase speed of maintenance. Its preferred because its composable to a predefined architecture scheme the developer is comfortable with. That's it. Its just about comfort, but the complexity is through the roof.

Simple isn't free.

[vacuity]

From what you're saying, it sounds like components in this framework (React?) are not simple at all. A major hurdle in evolving a program is capturing and maintaining simplicity. The proof of whether something is simple lies in its composability, readability, and so on. If someone claims to have found a method of writing simple components, do not believe them if the simplicity is not evident. A truly simple solution would not be so burdened, and a somewhat simpler solution would be less burdened. Of course, simple still doesn't mean easy, because the Fast Fourier Transform may be simple, but I can't teach it to a 5 year old (or anyone, really).

Never religiously cling to statements such as "strictly separate presentation and content". These are all just guidelines to suggest simpler solutions, not hard rules that guarantee simplicity. They will sometimes be excepted.

There are such things as components, which compose strictly by interfaces and externalize separate details, but it is up to the programmers to realize them in their programs. Also, simplicity is a global property of a system. Nothing can be judged on simplicity in a vacuum.

All that being said, I don't have experience in web or UI in particular. Seems like logic is moreso a local thing, whereas presentation is moreso global (but may consider locally defined advice). State can be local or global.

[knollimar]

Composability is really valuable; you don't get bogged down in interconnectivity when your application gets really big.

You pay for it for smaller stuff, though, since that multiplicative coefficient is high.

[qudat]

I’m not sure i could disagree more with a statement.

Reacts innovation is simple: view is a function of state.

Before that we had to construct the ui imperatively where we managed state AND ui transitions to state changes. Now we mostly just focus on rendering a ui based on the snapshot of state we have. It is revolutionary (for ui dev), it is scalable, it is the reason why react STILL dominates the ui landscape.

React isn’t just popular because it’s familiar, that might be a component, but it ignores the historical and technological achievement it created

[campbel]

I did angular for many years and just recently came back to doing frontend work for a recent project. This is my experience with react, its not perfect and there are a few react-isms to learn, but it tends to make you do the right thing.

[CaptainOfCoit]

At one point I also moved from Angular to React, after moving from Backbone to Angular, and from "just" jQuery + jQuery UI to Backbone. After moving to React, I haven't found the need to move to something else, most of the alternatives are marginal improvements, while the difference before and after React is pretty drastic.

[jgalt212]

> For massive apps with 1,000 components on the same page

If have a 40X25 table on your page that's editable, that's your 1,000 components right there. But away from tables, it does seem overkill to have 1,000+ components on a single page.

[amelius]

1,000 components is my standard test for trying out a new UI library.

I recently tried it with Kotlin/Compose. Turned out that everything becomes noticeably slower with so many components, even if the components are in a scroll view and only a few of them are visible.

[jfengel]

1,000 is a lot, but not uncommon for a CRUD app. Especially when you start with a small one and the scope creeps. Users want one more feature, and one more field. Then it's time to replace some other CRUD app and you've already got this one going ...

[GeoAtreides]

> If have a 40X25 table on your page that's editable, that's your 1,000 components right there.

Why would you do it like that?! Just have a normal component for a table, and when the clicks on a cell, spawn (and teleport) an edit component over that cell.

[robertoandred]

Also can we stop pretending React is any more "complex" than any other rendering library. You can't get much simpler than () => <div>Hello, World</div>

[acdha]

What makes React complex is that your simple example pulls in 100KB of code and entire layers like the virtual DOM which increase the memory and CPU requirements while adding significant new concepts a developer has to learn to be productive.

That’s not to say that there aren’t benefits from that but it’s definitely extra complexity compared to using web standards.