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'

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.