11 ms·
> 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 n
by picardo 11mo ago
> 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.
- jgalt212 11mo ago> 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 11mo ago1,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.
- aatd86 11mo agoDisplaying so many would require virtualization. No one is going to see a myriad of components all at once anyway. The slowing down part might be eager computations in partially optimized implementations. The same way we use pagination on the web, or lazy loading, etc... But I guess the question is whether that should be a default...
- amelius 11mo agoMaybe but it sounds like bad excuses. There are a myriad of examples anyone can come up with that require a UI library to simply be fast. For example, perhaps someone wants to implement minesweeper with checkboxes. Or build an "infinite" feed, or a settings panel showing thousands of settings of a system where you can filter with a filter box, etc., etc. You can argue against all of these cases, or you can simply rely on a fast UI library and be done with it.
- jitl 11mo ago1000 component should be trivial for a framework in 2025 without virtualization.
- aatd86 11mo agoHmmh... Warning: Lighthouse issues a warning when the page's <body> element has more than ~800 nodes (elements). Error: Lighthouse reports an error when the <body> element has more than ~1,400 nodes. Other Related Lighthouse Warnings Lighthouse also flags two other related issues, which often contribute to a large DOM: Maximum DOM Depth: It warns if your DOM tree has a nesting depth greater than 32 levels. Maximum Child Elements: It warns if any single parent element has more than 60 direct children. The general recommendation for optimal performance is to keep your page's total DOM node count below 1,500. source: https://web.dev/articles/dom-size-and-interactivity https://web.dev/articles/dom-size-and-interactivity These are "NODES", not even components as you say...
- jfengel 11mo ago1,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 11mo ago> 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.
- azangru 11mo ago> 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?
- picardo 11mo ago> Didn't they call it Flux rather than Flow? Ah, you may be right. It's been a long time.
- remixff2400 11mo agoFlow was a type checker (used to be Typescript vs. Flow debates early on before Typescript ended up with more support), Flux was the unidirectional data flow architecture.
- picardo 11mo ago> 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.
- aatd86 11mo agoShouldn't a state change should be purely event driven, and not dispatch its own events as side effect? That avoids reetrancy and is an easy rule to adopt...? Or am I misunderstanding the issue?
- picardo 11mo agoYou're right about that, but that wasn't common practice at the time. We learned about side-effects from Elm and Flux.
- austin-cheney 11mo agoComponents 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.
- cindyllm 11mo ago[dead]
- qudat 11mo agoI’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
- austin-cheney 11mo agoI have had other people tell me this because they perceived state management as a challenging problem to solve. That is true of the big frameworks, but otherwise state management is a ridiculously straightforward problem easily solved.
- scotty79 11mo agoReact came to be because folks at Facabook couldn't get the label displaying unread notifications always to display correct value. This seems like ridiculously straightforward problem easily solved. Yet still many websites and applications today struggle with that.
- wooque 11mo ago>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 11mo agoYou can, but it's harder, React will at least nudge you away from doing that.
- ruszki 11mo agoPeople 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.
- CaptainOfCoit 11mo agoI 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 11mo agoYeah 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.
- Muromec 11mo agoAnd now everyone has phantom unreads again because it is cyclical and a different team is in charge of every other div
- hungryhobbit 11mo agoLook, 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.
- deleted 11mo ago[deleted]
- campbel 11mo agoI 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 11mo agoAt 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.
- panphora 11mo agoAuthor 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 11mo agoYes, 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 11mo agoThose 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
- deleted 11mo ago[deleted]
- robertoandred 11mo agoAlso 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 11mo agoWhat 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.
- robertoandred 11mo agoA single picture is going to be more than 100kb. Meanwhile, there simply aren’t web standards that match React’s capabilities.
- azemetre 11mo agoPictures get encoded and decoded by browsers much much faster than the ability to parse then execute javascript.
- acdha 11mo agoYou don’t need to know how JPEG or AVIF work internally to use an <img> tag. > Meanwhile, there simply aren’t web standards that match React’s capabilities. This isn't true for much of the web but it’s more deeply missing the point: if you’re building a web app, you need to learn the web APIs because those are what all web apps actually use. Adding intermediaries means that you have more things to learn, troubleshoot, and optimize. React’s value comes from managing the complexity of the code you write, which can be a real benefit for some projects but it doesn’t remove the need for you to know how browsers work.
- deleted 11mo ago[deleted]