6 ms·

React is well designed and a nice work. It's the idea behind it that is totally flawed and doomed.

by MrBra 11y ago

spicyj 11y ago
What?
sergiotapia 11y ago
It's a shame you were downvoted, I enjoy technical discussions here. Can you elaborate why you think React's approach is bad?
- MrBra 11y ago
  Because it's built on the assumption that just because DOM access is slow, then it's a good idea to just add another layer of JS in order to provide a cached-like faster DOM access speed, rather than focusing on fixing DOM access speed issue itself. React augments the complexity of a stack that it's already too complex, to an unneeded, non-sustainable and dev-unfriendly way in which we are supposed to use HTML tags inside JS scripts. React is just a Facebook's own short-sighted solution to slow DOM manipulation. The fact that it is OSS doesn't make it necessarily a good thing. React is not a product of love for a greatly engineered system, but obviously just a product of FB's understandable necessity to work faster "today and here", in order to keep bringing home their daily profit. React is not a solution, it's a patch, a ugly one. We are not forced to like it just because FB made it and made it OS.
  - _pmf_ 11y ago
    Succinct and to the point.
  - mynegation 11y ago
    I wish you would start with this argument, instead of the one that looked very much like trolling. Can DOM be faster? Maybe so. Does that mean React is a bad idea? No. In fact, React is Multiple Buffering[1] in the age of DOM. It is not that DOM is slow, it is that change of DOM triggers the layout and layout is inherently slow, because it is complex. If you do not need re-layout on each DOM change (and most of the time you do not), React allows you to batch changes in a very clean way. [1] https://en.wikipedia.org/wiki/Multiple_buffering https://en.wikipedia.org/wiki/Multiple_buffering
    - deleted 11y ago
      [deleted]
    - throwaway41597 11y ago
      There isn't a relayout on each DOM change. Changes trigger layout when you read DOM properties such as clientWidth or when the event loop loops.
  - iamstef 11y ago
    The DOM is slow meme confuses me. Yes, if one isn't careful, one can get into trouble. But the same is true for all platforms/frameworks/concepts/religions. As it turns out, the fastest way to build + update DOM, is with the DOM... #mindblown (its also the only way ;)) I believe the actual pain felt, is one of ergonomics. This is largely related to what MrBra mentioned, it turns out a complex stack is complex I suppose we just need to keep fighting the entropy us developers like to add.
  - abritinthebay 11y ago
    I do not know where to start with this. Not one single part is true and all of them come from a very misinformed and misguided understanding of both the DOM (and what it is, why it's slow) and React. It's hard to unpack all of it without writing an essay.
  - brentvatne 11y ago
    > Because it's built on the assumption that just because DOM access is slow, then it's a good idea to just add another layer of JS in order to provide a cached-like faster DOM access speed, rather than focusing on fixing DOM access speed issue itself. The virtual DOM is just an implementation detail. In my eyes, React's big feature is that it is a declarative, component-based UI model. Look at React Native or ComponentKit - they are not built around the idea that CocoaTouch is slow, but rather that there are simpler ways to do UI than the traditional imperative approach. > React augments the complexity of a stack that it's already too complex, to an unneeded, non-sustainable and dev-unfriendly way in which we are supposed to use HTML tags inside JS scripts. In my experience, as I mentioned above, React actually provides a fantastic abstraction that makes it simpler to build UIs. I haven't found it to be dev-unfriendly at all, the opposite actually - I find that it is a highly pragmatic, productive and pleasant way to work. But I suppose that's a matter of preference. What do you find unfriendly about it in particular? > React is not a product of love for a greatly engineered system, but obviously just a product of FB's understandable necessity to work faster "today and here", in order to keep bringing home their daily profit. This point I must disagree with absolutely. I have had many interactions with people who work on React and from my point of view it is indeed a labor of love as much as any I've seen on an OSS project. Do you have any examples that you can point towards to back up your assertion? Just watch presentations by any of the React team members and you'll see that there are real people behind it that care deeply about it. Better yet, talk to any of them in person and see how excited they are! This isn't a heartless top-down mandated project by a massive organization to squeeze more money out, but rather it started off as a skunkworks project by a single engineer in his spare time who thought that UI could be simpler, that caught on within the company because it turned out to be a great idea. > React is not a solution, it's a patch, a ugly one. > We are not forced to like it just because FB made it and made it OS. Well, isn't the world beautiful, so many different opinions! I'm extremely curious what your preferred tooling is, or any suggestions you have to make React better. Maybe you could write a longer form essay to elaborate on your criticisms above?
  - enraged_camel 11y ago
    You don't have to JSX inside your render function. You can use React's built-in factories. Other than that, getting around slow DOM manipulation is only one advantage of React. There are many others, such as making it super easy to reason about complex code, for example by not having to worry about the excruciating details of how multiple event handlers that are bound to the same element will behave. Separating the state from the DOM itself is a brilliant idea and the elegance with which React accomplishes this disproves your claim that it is simply an "ugly patch".
  - mandeepj 11y ago
    >cached-like faster DOM access speed I don't think they are caching DOM. Instead of deleting and adding new elements, they are just changing the old ones to reflect the changes. Adding new elements are expensive. If anyone thinks I am wrong then please provide a documentation link to the correct material [EDIT] Not sure why some people try to be rude here. Where is your zeal to ask and learn?
    - abritinthebay 11y ago
      It's basically like creating a diff patch, so you're close.
      - amelius 11y ago
        It is like this: 1. Create full new version 2. Run a diff with the old version 3. Patch Because of 1, it is bound to be slow (in a computational complexity sense). Based on the popularity of React and its wide acceptance, I wonder if people learn computational complexity theory anymore these days? PS: yes I know there are tricks to make 1 faster, but these are really hacks (require extra thinking and are error-prone) and deviate from the original "React" philosophy (they are basically the old style of doing things), so these don't count.
        MrBra 11y ago
        What would it the the new style of doing things, for the non-academic rest of us ?
        lobster_johnson 11y ago
        Part of implementing an efficient React app is making sure that prop/state transitions are minimized. Coincidentally, this is also (abstractly) true about any UI technology, not just React. But React sacrifices a little bit of speed in order to make the UI declarative, as opposed to the finicky, error-prone and messy way we used to do it before with frameworks like Backbone. Have you actually developed a large React app? Because you might be surprised at how fast React really is in practice.
  - arstin 11y ago
    Thanks for the effort :), but these points are simply unsound. Far from being a patch, React offers -one- standard model for writing UIs on any platform. Thus React at its core has nothing to do with the DOM (see React-Hardware, React-Blessed, React-Native, React-Canvas...React-DOM is just another rendering target). Also, in a real-world app React drastically simplifies actual code with the tiny tradeoff of adding a small amount of complexity onto "the web stack". If you actually care and weren't just trolling, you---or a reader who shares your uninformed intuition---might enjoy this wonderful high-level overview of what React is actually about: https://www.youtube.com/watch?v=H1vW1w8k7J0 https://www.youtube.com/watch?v=H1vW1w8k7J0
  - lobster_johnson 11y ago
    As others point out, this is provably false. React's use of a virtual DOM is merely an optimization. The same principle is used in many other areas: Double-buffered rendering in graphics engines, for example. Facebook clearly chose HTML syntax (JSX) to be familiar with how developers are used to interact with HTML, thus lowering the learning curve. As others point out, the JSX syntax is still beneficial when not targeting the DOM, as in the case of React Native. JSX is just a preprocessor, and no different than writing, say, Mustache templates. What React brings to the table is a framework for declarative UI components. Functionally, React components are no different than, say, Backbone views (indeed it's quite trivial to port a backbone view to a React component), but the data flow principles promoted by React (unidirectional MVC, immutability, declarativity, discrete state transitions) are different, and somewhat novel in the UI/MVC space. React is definitely not just a "patch". If you think that, you've clearly not studied it closely enough.
- amelius 11y ago
  See my comment elsewhere in this topic.
  - deleted 11y ago
    [deleted]

React is well designed and a nice work. It's the idea behind it that is totally flawed and doomed.

by MrBra 11y ago

React is well designed and a nice work. It's the idea behind it that is totally flawed and doomed.

spicyj 11y ago

What?

sergiotapia 11y ago

It's a shame you were downvoted, I enjoy technical discussions here. Can you elaborate why you think React's approach is bad?

MrBra 11y ago
Because it's built on the assumption that just because DOM access is slow, then it's a good idea to just add another layer of JS in order to provide a cached-like faster DOM access speed, rather than focusing on fixing DOM access speed issue itself. React augments the complexity of a stack that it's already too complex, to an unneeded, non-sustainable and dev-unfriendly way in which we are supposed to use HTML tags inside JS scripts. React is just a Facebook's own short-sighted solution to slow DOM manipulation. The fact that it is OSS doesn't make it necessarily a good thing. React is not a product of love for a greatly engineered system, but obviously just a product of FB's understandable necessity to work faster "today and here", in order to keep bringing home their daily profit. React is not a solution, it's a patch, a ugly one. We are not forced to like it just because FB made it and made it OS.
- _pmf_ 11y ago
  Succinct and to the point.
- mynegation 11y ago
  I wish you would start with this argument, instead of the one that looked very much like trolling. Can DOM be faster? Maybe so. Does that mean React is a bad idea? No. In fact, React is Multiple Buffering[1] in the age of DOM. It is not that DOM is slow, it is that change of DOM triggers the layout and layout is inherently slow, because it is complex. If you do not need re-layout on each DOM change (and most of the time you do not), React allows you to batch changes in a very clean way. [1] https://en.wikipedia.org/wiki/Multiple_buffering https://en.wikipedia.org/wiki/Multiple_buffering
  - deleted 11y ago
    [deleted]
  - throwaway41597 11y ago
    There isn't a relayout on each DOM change. Changes trigger layout when you read DOM properties such as clientWidth or when the event loop loops.
- iamstef 11y ago
  The DOM is slow meme confuses me. Yes, if one isn't careful, one can get into trouble. But the same is true for all platforms/frameworks/concepts/religions. As it turns out, the fastest way to build + update DOM, is with the DOM... #mindblown (its also the only way ;)) I believe the actual pain felt, is one of ergonomics. This is largely related to what MrBra mentioned, it turns out a complex stack is complex I suppose we just need to keep fighting the entropy us developers like to add.
- abritinthebay 11y ago
  I do not know where to start with this. Not one single part is true and all of them come from a very misinformed and misguided understanding of both the DOM (and what it is, why it's slow) and React. It's hard to unpack all of it without writing an essay.
- brentvatne 11y ago
  > Because it's built on the assumption that just because DOM access is slow, then it's a good idea to just add another layer of JS in order to provide a cached-like faster DOM access speed, rather than focusing on fixing DOM access speed issue itself. The virtual DOM is just an implementation detail. In my eyes, React's big feature is that it is a declarative, component-based UI model. Look at React Native or ComponentKit - they are not built around the idea that CocoaTouch is slow, but rather that there are simpler ways to do UI than the traditional imperative approach. > React augments the complexity of a stack that it's already too complex, to an unneeded, non-sustainable and dev-unfriendly way in which we are supposed to use HTML tags inside JS scripts. In my experience, as I mentioned above, React actually provides a fantastic abstraction that makes it simpler to build UIs. I haven't found it to be dev-unfriendly at all, the opposite actually - I find that it is a highly pragmatic, productive and pleasant way to work. But I suppose that's a matter of preference. What do you find unfriendly about it in particular? > React is not a product of love for a greatly engineered system, but obviously just a product of FB's understandable necessity to work faster "today and here", in order to keep bringing home their daily profit. This point I must disagree with absolutely. I have had many interactions with people who work on React and from my point of view it is indeed a labor of love as much as any I've seen on an OSS project. Do you have any examples that you can point towards to back up your assertion? Just watch presentations by any of the React team members and you'll see that there are real people behind it that care deeply about it. Better yet, talk to any of them in person and see how excited they are! This isn't a heartless top-down mandated project by a massive organization to squeeze more money out, but rather it started off as a skunkworks project by a single engineer in his spare time who thought that UI could be simpler, that caught on within the company because it turned out to be a great idea. > React is not a solution, it's a patch, a ugly one. > We are not forced to like it just because FB made it and made it OS. Well, isn't the world beautiful, so many different opinions! I'm extremely curious what your preferred tooling is, or any suggestions you have to make React better. Maybe you could write a longer form essay to elaborate on your criticisms above?
- enraged_camel 11y ago
  You don't have to JSX inside your render function. You can use React's built-in factories. Other than that, getting around slow DOM manipulation is only one advantage of React. There are many others, such as making it super easy to reason about complex code, for example by not having to worry about the excruciating details of how multiple event handlers that are bound to the same element will behave. Separating the state from the DOM itself is a brilliant idea and the elegance with which React accomplishes this disproves your claim that it is simply an "ugly patch".
- mandeepj 11y ago
  >cached-like faster DOM access speed I don't think they are caching DOM. Instead of deleting and adding new elements, they are just changing the old ones to reflect the changes. Adding new elements are expensive. If anyone thinks I am wrong then please provide a documentation link to the correct material [EDIT] Not sure why some people try to be rude here. Where is your zeal to ask and learn?
  - abritinthebay 11y ago
    It's basically like creating a diff patch, so you're close.
    - amelius 11y ago
      It is like this: 1. Create full new version 2. Run a diff with the old version 3. Patch Because of 1, it is bound to be slow (in a computational complexity sense). Based on the popularity of React and its wide acceptance, I wonder if people learn computational complexity theory anymore these days? PS: yes I know there are tricks to make 1 faster, but these are really hacks (require extra thinking and are error-prone) and deviate from the original "React" philosophy (they are basically the old style of doing things), so these don't count.
      - MrBra 11y ago
        What would it the the new style of doing things, for the non-academic rest of us ?
      - lobster_johnson 11y ago
        Part of implementing an efficient React app is making sure that prop/state transitions are minimized. Coincidentally, this is also (abstractly) true about any UI technology, not just React. But React sacrifices a little bit of speed in order to make the UI declarative, as opposed to the finicky, error-prone and messy way we used to do it before with frameworks like Backbone. Have you actually developed a large React app? Because you might be surprised at how fast React really is in practice.
- arstin 11y ago
  Thanks for the effort :), but these points are simply unsound. Far from being a patch, React offers -one- standard model for writing UIs on any platform. Thus React at its core has nothing to do with the DOM (see React-Hardware, React-Blessed, React-Native, React-Canvas...React-DOM is just another rendering target). Also, in a real-world app React drastically simplifies actual code with the tiny tradeoff of adding a small amount of complexity onto "the web stack". If you actually care and weren't just trolling, you---or a reader who shares your uninformed intuition---might enjoy this wonderful high-level overview of what React is actually about: https://www.youtube.com/watch?v=H1vW1w8k7J0 https://www.youtube.com/watch?v=H1vW1w8k7J0
- lobster_johnson 11y ago
  As others point out, this is provably false. React's use of a virtual DOM is merely an optimization. The same principle is used in many other areas: Double-buffered rendering in graphics engines, for example. Facebook clearly chose HTML syntax (JSX) to be familiar with how developers are used to interact with HTML, thus lowering the learning curve. As others point out, the JSX syntax is still beneficial when not targeting the DOM, as in the case of React Native. JSX is just a preprocessor, and no different than writing, say, Mustache templates. What React brings to the table is a framework for declarative UI components. Functionally, React components are no different than, say, Backbone views (indeed it's quite trivial to port a backbone view to a React component), but the data flow principles promoted by React (unidirectional MVC, immutability, declarativity, discrete state transitions) are different, and somewhat novel in the UI/MVC space. React is definitely not just a "patch". If you think that, you've clearly not studied it closely enough.
amelius 11y ago
See my comment elsewhere in this topic.
- deleted 11y ago
  [deleted]