Possible issue in "Components and Props" section of docs - functional vs. class components

[mbrowne]

The current documentation says:

The simplest way to define a component is to write a JavaScript function:
[...]
You can also use an ES6 class to define a component:
[...]
The above two components are equivalent from React’s point of view.

I just encountered a contradictory comment from @trueadm, an engineer on the React core team:

In React 16, functional components are quite a bit faster than class components. On a side note, this optimization is something we’re aware of and have been talking about a bit recently. :)

https://medium.com/@trueadm/in-react-16-functional-components-are-quite-a-bit-faster-than-class-components-1afca4931d7c

Does this mean that the possible future optimizations for functional components that were mentioned in previous versions of the docs and blog posts have now been implemented? If so, this should be mentioned in the docs (and probably should have been in the release notes for React 16 too, but I don't see it mentioned there).

If this has indeed been implemented, then it should also be noted that this is a micro-optimization that still pales in comparison with using PureComponent (or your own efficient shouldComponentUpdate() logic), as explained in facebook/react#5677 (comment):

For complex components, defining shouldComponentUpdate (eg. pure render) will generally exceed the performance benefits of stateless components. The sentences in the docs are hinting at some future optimizations that we have planned, whereby we won't allocate an internal instance for stateless functional components (we will just call the function). We also might not keep holding the props, etc. Tiny optimizations. We don't talk about the details in the docs because the optimizations aren't actually implemented yet (stateless components open the doors to these optimizations).

[trueadm]

Functional components in React 16 don't go through the same code path as class components, unlike in previous version where they were converted to classes and would have the same code path. Class components have additional checks required and overhead in creating the instances that simple functions don't have.

These are micro-optimizations though and shouldn't make a huge difference in real-world apps – unless your class component is overly complex. I've not benchmarked functional components vs class components with the latest version of React, but it would be interesting if someone did to see the differences today given the amount of tweaks that have happened in JS engines since I last benchmarked.

[mbrowne]

Thanks @trueadm - very good to know, even though it's a just a micro-optimization. So it's as I said above - using PureComponent would make a much bigger difference.

I still think both of these points should be mentioned in the docs. It's misleading to just say, "The above two components are equivalent from React’s point of view" and leave it at that. That introductory section isn't the right place to get into tiny nuances of performance differences, but it could have a link to a more advanced section with notes about performance. I might submit a PR.

[rickhanlonii]

Going to close this as the docs are completely different now, and the performance note doesn't seem relevant in 2025. Also we recommend all components be function components in the docs already: https://react.dev/reference/react/Component