131–140 of 245 posts
> 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 frustratio…
> 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 frustratio…
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 loo…
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.
> 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 frustratio…
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 loo…
You can use other frameworks for the other 1% of apps
The article overlooks the problems that made React popular:
- Composition: Composing components is easier and more efficient in React. Backbone’s render function assumes "this.$el" is mounted and available in the DOM. That makes composition difficult: you cannot simply nest one component inside another without managing the DOM lifecycle of subcomponents. You don’t need 1.000 components to feel the pain.
- Event handling: You can’t pass an event handler as a string, so the events object must be paired with the selector to locate the element. Any structural changes require updating selectors or managing unique IDs.
- State management: Re-rendering components when state changes becomes messy in Backbone fairly quickly. That mess is why Angular 1 gained popularity. React simplifies this further by enforcing a one-directional state flow.
- Efficient DOM updates: Even if you implement composition and state management ad hoc, you still must update the DOM efficiently to avoid layout thrashing and related issues. React isn’t immune, but these problems are typically easier to handle.
- Other features: Implementing useful capabilities from scratch, like lazy loading parts of components (for example, suspense) or building hybrid apps with server-side rendering, requires significant work.
I'll argue that nowadays, if you want to use vanilla JS with templating support, lit-html (not the full framework, just the template part) is a much better choice than Backbone.
Earlier quoted context omitted.
> I do think it is chosen unthinkingly in scenarios where it isn’t necessary Does this genuinely matter beyond (borderline dogmatic) perfectionism? There are plenty of things that make products or projects bad, and I'd say, at most, the choice of framework is incidental. It only becomes symptomatic when you have an axe to grind.
IMO, yes. There are a lot of people out there with underpowered devices or slow internet connections (including me when I’m on the subway!) and modern web dev practices that output MBs of JS for simple things are a terrible experience. Just not one experienced by the developers on super fast computers and wired internet connections. Try browsing the web with Chrome’s network throttling and CPU throttling enabled. It…
> 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 frustratio…
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.
As you say many people do not understand how important, vital and bizarrely _non-obvious_ uni directional data flow was.
If you look at the React code, it's 99% "just" JavaScript and HTML. The only proprietary function is `useState`, and even the people who have never touched React probably understand what `useState` does in this code without having to open the docs.
Also, in the Backbone code, half of the application relies on the string selector `.space-y-2`. So if someone in your team changes this class (or add it on another element), and forgets to ctrl+F `space-y-2` and change the string everywhere else, half of the application is broken. Also the layout/style for the checks list is repeated twice (in `render` and `updatePassword`), so if someone forgets to change both, the UI will be inconsistent once the user enters their password. And this a 50 LOC app… imagine now the same problems in a 10k+ LOC app. Maintenance hell.
I don't understand how the author wrote those two examples, didn't see the problems with the Backbone version and conclude there is no differences between both frameworks. React solved the problems present in the Backbone version.
> 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 frustratio…
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.
> React looks cleaner. It reads better at first glance. I've struggled to get past this. I don't find it easier to read, and the js and html mixed together is just icky. But I think this is an uncommon opinion, and that surprises me.
1. It's easy to differentiate the composed DOM from JS logic, since any logic is expressed in JS rather than mixed into the JSX DOM.
2. JSX maps directly to the JSDOM API.
> 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 frustratio…