[Xeamek]

>React is so widely used it'll be kept on life support long after it has been supplanted by something better, if and when that happens.

React might be 10 years old, but it changed like 5 times during that time. Something built in first or second version of React is pretty much an entirely different framework at this point. (Would it even build with using the newset toolchains?). It's almost disingenuous to ignore that fact.

So while it's unlikely that there won't be a thing called "React" in the future, it's not that crazy of an idea.

[docmars]

React's first flavor (class-based components) are fully backwards compatible with today's React versions. It doesn't seem odd to me that a popular library identifies its pain points and improves its APIs & patterns over time. That's the beauty of open source software with large communities guiding their growth.

Today, it's moving heavily towards server-side rendering because the client-side / SPA format is already quite mature. Their approach with server components is an optimization path that uses concepts/patterns from already popular server-side languages and frameworks + templating, and blends them seamlessly with client-side development, giving engineers the best of many worlds.

This was a natural evolution from NextJS which popularized this way of using React, and it's giving engineers more choices in how they build + optimize their apps.

[skydhash]

> This was a natural evolution from NextJS

It’s just going back full cycle, with a few extra steps. And the only clear purpose is SEO.

[docmars]

No you're right, but the benefit is: a more consistent dev experience across client and server-side. Being able to write the same components in either environment for specific optimization purposes (static rendering vs. interactions) is a huge plus. It reduces the cognitive overhead of context switching between languages and technologies.