3 ms·

I disagree with at least one of the authors critiques: "Issue 1: React components are difficult to reuse in complex interactive web projects. Such a lightweig

by htormey 10y ago

I disagree with at least one of the authors critiques: "Issue 1: React components are difficult to reuse in complex interactive web projects. Such a lightweight component is very handy in rendering plain and static webpages. Nonetheless, when there are interactions between one component and another, passing callback functions as parameters are inevitable. Particularly for webpages with complicated structures, we have to nest dozens of components from the inside-out, where those callback functions are passed through from parent to child components across layers and layers. The only outcome for applying React framework in complex interactive web projects is that the codebase would become too messy to maintain." Out of the box React is relatively spartan, which is great for small projects. At scale it only really comes into its own when used in conjunction with other things such as Redux and its wonderful ecosystem of middleware. In this kind of situation, I would advise using something like Redux and following the advice of Dan Abramov (Redux creator). He wrote a wonderful article on how to split functionality between components and containers: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.6xmuhf2rx https://medium.com/@dan_abramov/smart-and-dumb-components-7c... I think this is a great pattern to follow for larger scale projects. "It is well-known that React is a great tool for implementing simple interactive websites, but how does it apply on complex interactive front-end projects?" Facebook seems like a pretty complex website to me and they are all in on React. As to his points about the virtual DOM performance, I'd love to hear a more experienced web dev chime in on that as my area of expertise is native development.

RonanTheGrey 10y ago
Redux (and various projects in its ecosystem) resolves alot of the criticisms in the article. To this: > As to his points about the virtual DOM performance, I'd love to hear a more experienced web dev chime in on that as my area of expertise is native development. His example of an <li> with a <ul> is wrong. Setting that aside.. Depending on the operation and the browser, you can do anywhere between 2000-100000 more operations per second in a virtual DOM than in the browser DOM. The complaint that complex render functions are wasting precious resources is valid, which is why documentation makes it very clear that these functions should be as simple as possible and produce no side effects. Remember - library, not a framework. Additionally, it belies the question of - why are you writing a complex render in the first place. In a well-structured app, components would be reasonably small and render functions relatively simple, for varying definitions of 'relatively.' That is, you aren't doing complex number crunching in the render. When I do React perf optimization, one of the most common errors I see people make is have render functions full of complex logic and branching render paths. If you are doing that, your component can be further broken down. Apparently Facebook is built on over 100,000 individual React components. Damn.
- htormey 10y ago
  I agree. Redux resolves a lot of his criticisms thats why I really didn't get why the author dismissed it so quickly: "For example, besides the four facets above, the state management problem of React is non-negligible. If we introduce a third-party library such as Redux to deal with the state, the framework would become tangled and the number of layers would increase." Given how widely used Redux is with React I would have expected him to expand on this point some more and provide a meaningful critique. It's a shame that the other parts of his series have not yet been translated into English. Perhaps he elaborates on what he means by the above statement.

by htormey 10y ago

RonanTheGrey 10y ago

Redux (and various projects in its ecosystem) resolves alot of the criticisms in the article. To this: > As to his points about the virtual DOM performance, I'd love to hear a more experienced web dev chime in on that as my area of expertise is native development. His example of an <li> with a <ul> is wrong. Setting that aside.. Depending on the operation and the browser, you can do anywhere between 2000-100000 more operations per second in a virtual DOM than in the browser DOM. The complaint that complex render functions are wasting precious resources is valid, which is why documentation makes it very clear that these functions should be as simple as possible and produce no side effects. Remember - library, not a framework. Additionally, it belies the question of - why are you writing a complex render in the first place. In a well-structured app, components would be reasonably small and render functions relatively simple, for varying definitions of 'relatively.' That is, you aren't doing complex number crunching in the render. When I do React perf optimization, one of the most common errors I see people make is have render functions full of complex logic and branching render paths. If you are doing that, your component can be further broken down. Apparently Facebook is built on over 100,000 individual React components. Damn.

htormey 10y ago
I agree. Redux resolves a lot of his criticisms thats why I really didn't get why the author dismissed it so quickly: "For example, besides the four facets above, the state management problem of React is non-negligible. If we introduce a third-party library such as Redux to deal with the state, the framework would become tangled and the number of layers would increase." Given how widely used Redux is with React I would have expected him to expand on this point some more and provide a meaningful critique. It's a shame that the other parts of his series have not yet been translated into English. Perhaps he elaborates on what he means by the above statement.