41–50 of 245 posts
Try typing a full word into each password box. Then, try to undo (Cmd/Ctrl-Z, etc). Backbone's undoes the typing, one letter at a time. React's behaves correctly and undoes the whole word. Good job, React (I still see "controlled" inputs on the web today falling prey to the former)
Which is literally the entire reason any framework or abstraction is chosen (most of the time IMO).
I'm ready for all the "what about x" comments, because I'm going to check them all. I'm choosing React over anything else right now because of how well my DevEx has been. I can say the same about Angular, you really need to know how Angular works to know what you're doing. That's the whole issue with these frameworks. At least React doesn't try to abstract too much
What do you mean? The DOM is abstracted away. Hooks are magical, and don't work like regular javascript functions. The scheduler, and the concurrent features are magical. The string pragmas are magical. It is all getting more and more magical, and you need a linter to keep you in line with the magic.
Compared to my confusion making sense of that project, I simply cannot imagine getting so confused orienting in a React project, even if it were done by an inexperienced person. It seems to me that the "extra" abstractions of React compel you to use them, and so things end up in reliable, sensible places.
The entanglements the author mentions feel like part of the benefit, I guess?
[1]: https://github.com/compdemocracy/polis/tree/edge/client-part...
Try typing a full word into each password box. Then, try to undo (Cmd/Ctrl-Z, etc). Backbone's undoes the typing, one letter at a time. React's behaves correctly and undoes the whole word. Good job, React (I still see "controlled" inputs on the web today falling prey to the former)
Seems more like personal preference.
> 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…
> 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?
Ah, you may be right. It's been a long time.
Does react still mess up the DOM and, for example, using Google Translate? I do use react but only for very specific well-defined reusable components and I use js events to message them. I try to keep it as simple as possible. I can't imagine creating an entire site with react.
One might argue that it is Google Translate that messes up the DOM for react :-)
I'm ready for all the "what about x" comments, because I'm going to check them all. I'm choosing React over anything else right now because of how well my DevEx has been. I can say the same about Angular, you really need to know how Angular works to know what you're doing. That's the whole issue with these frameworks. At least React doesn't try to abstract too much
> At least React doesn't try to abstract too much What do you mean? The DOM is abstracted away. Hooks are magical, and don't work like regular javascript functions. The scheduler, and the concurrent features are magical. The string pragmas are magical. It is all getting more and more magical, and you need a linter to keep you in line with the magic.
It's the definition of sunken cost fallacy: I mean, heck, I genuinely believe React is garbage, and yet I use it for just about every project because of its ecosystem and lazy "npm install " muscle memory.
> 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…
> 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?
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.