I’m sorry the post came across this way. We didn’t intend to blame the users. The component API was virtually unchanged for five years, and when it was originally designed, we didn’t anticipate how it would be used, so the hooks were pretty low level and matched how React worked internally. These days we have a better idea of where we want to take React (I hope that my talk[1] may inspire you even though you already formed a negative opinion). The work we're doing now is just to fix the mistakes we made in the past with a gradual migration path.

>no wonder we're ending up with gobbledygook like "getSnapshotBeforeUpdate(...)."

I totally see what you mean but this particular lifecycle is for a very rare use case. If you have better suggestions for naming it please let us know—we have an open RFC process and you are welcome to participate there.[2] We didn’t separate it on a whim—it is essential to have a pure lifecycle like this to implement some use cases (like autoscrolling to new data) with asynchronous rendering[1].

>I ended up populating data via componentWillMount on the back-end. Terrible solution, but hey, it's the only one React has

You're right—but this solution doesn't solve async data fetching. It only works when the data is synchronously available, and per the post, in that case you can already use the constructor.[3]

>This will not work on the server-side because technically components never mount when doing SSR.

I think you might have missed this part of the post:

>In the longer term, the canonical way to fetch data in React components will likely be based on the “suspense” API introduced at JSConf Iceland. Both simple data fetching solutions and libraries like Apollo and Relay will be able to use it under the hood. It is significantly less verbose than either of the above solutions, but will not be finalized in time for the 16.3 release.

The mentioned “suspense” API is both much less verbose and actually was designed with server rendering in mind. It would let us fetch data on the server and on the client and suspend rendering until the data is ready (and show a placeholder if it takes too long).

The lifecycle changes in these blog posts are exactly the kind of work we need to do to make APIs like Suspense possible. Again, I encourage you to watch my talk[1], the second half of which demonstrates this API.

I hope this clarifies our position a bit, and I’m sorry if it seemed like we don’t care about our users. It took us about a month to write this blog post, and we know it still doesn’t address all use cases. We’ll take your feedback in mind next time we amend it. Thanks!

[1]: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...

[2]: https://github.com/reactjs/rfcs/pull/33

[3]: https://reactjs.org/blog/2018/03/27/update-on-async-renderin...