mbrowne

I did a good bit of research on the performance differences between different kinds of React components and back in February and submitted a PR to the React docs: https://github.com/reactjs/reactjs.org/pull/645. If you want to read it (note: no one on the React team has reviewed this yet, but I was careful to confirm my findings): you can do so here: https://deploy-preview-645--reactjs.netlify.com/docs/optimiz....

Unfortunately there is a long backlog of PRs to the React docs waiting for review so I don't know if/when this info might be incorporated into the docs. Also React is evolving so fast that it would need to be updated, e.g. to mention memo, and given that fast evolution I can understand why there's a backlog. But I do hope that someone on the React team eventually has time to look at adding more explanation to the "Optimizing Performance" section.

Thinking about it some more, for function components I suppose this might be a good use case for a hook...

I am wondering how to avoid unnecessary re-renders using `contextType`. With the render props pattern, you could write a component e.g. <Subscribe> that subscribes to a store and accepts a prop to indicate the specific data dependencies of your component (similar to mapStateToProps() in redux -- here it could be called mapContextToProps()). It's nice to be able to use `static contextType` but it would re-render anytime any property of your context object changes (just as would be the case when using a Consumer directly). That might be fine for something like a theme but wouldn't scale to a more general state management solution.

On the other hand... https://lists.w3.org/Archives/Public/public-webapps/2014JulS...

Here's another article on why web components deserve a second look, even for React programmers: https://medium.com/@richardanaya/web-components-why-you-shou....

The author also wrote a library that simplifies using web components and offers an option for integrating with React: https://github.com/richardanaya/webblock/ (Haven't investigated it in detail yet, but it looks promising.)

I had some other doubts about the article as well, but didn't make any other comments yet because I am still researching React and web components. It appears you may be right that React does not force you into an overly coupled design, but I still think the article makes a good point about how people are writing React components (among many other library-specific component libraries) instead of native web components, which may be contributing to web components lagging behind. But I was just reading that web components can be used quite successfully as building blocks for larger React components or integrated with React in other ways, so I don't see why it has to be one or the other. And yes, sorry to call React a framework - I know it's a library and should not have called it a framework.

I thought this was a very interesting and thoughtful article. I appreciated that the article linked to Trygve Reenskaug's earliest article about MVC, since the real MVC vision and history is unfortunately not well-known today. But the article also seems to take the idea of separation of concerns a bit farther than Reenskaug himself did: the article "The Model-View-Controller (MVC): Its Past and Present" points out that "in simple cases, the Model, View and Controller roles may be played by the same object. Example: A scroll bar." (http://folk.uio.no/trygver/2003/javazone-jaoo/MVC_pattern.pd...)

However, I definitely agree that a framework that steers programmers toward always combining M,V, and C behaviors in a single component (as React arguably does) is highly problematic.

I highly recommend the link to the MVC pattern article above that explains some of the lost history and greater significance of MVC beyond just "separation of concerns". The core of MVC is much more human-focused: it's about better bridging the gap between the user's mind and the computer, so that the Model feels like an extension of the user's mind as they're using the system.

Note: Somebody posted a link to this article in a comment in an earlier thread (https://news.ycombinator.com/item?id=10606482) but I thought I'd create a new thread about it because although it was written last year, I think it deserves further discussion.