Everything is a circle in web development. It appears to take about five to ten years for developer personnel to turn over close to 100%.
And so the cycle continues, with old ideas dusted off or rediscovered, the original flaws in them rediscovered, the reaction to those flaws, traveling well-trodden paths, then the reaction to the reaction, "best practices" shaking out, an explosion of complexity, and then someone burns down the baroque cathedral of ideas with, if we're lucky, a slightly less flawed version of the original old idea.
I've now done ASP.NET long enough to see WebForms come in, reach high tide, recede before the new hotness of MVC, MVC decline in favor of WebApi with monstrosities of JS frameworks in front of it, and now Razor Pages are coming back in as a simpler alternative, with concepts that an old WebForms developer from fifteen years ago wouldn't raise an eyebrow at.
Actually that is exactly what I thought when they introduced RazorPages as well.
I really like .NET Core but this RazorPages is just single worst "improvement" for the .NET Core platform.
I even remember watching the presentation on BUILD conference and nobody applauded at this "feature" when they graciously introduced it and you could feel the cringe. Scott even had to say "Isn't this awesome!?? Come on!".
No, Scott, it's not awesome. It's going backwards.
As some people who have been paying attention said from day one: other than the component model and unidirectional data flow, what makes React stand out is that it's ultimately a way to describe a UI in terms of functions that output a component tree. Whether you apply that component tree to the browser DOM or use it to generate static markup makes no difference (or to glue together native components as with React Native).
A lot of the more complex features only make sense in an interactive context (i.e. when rendering in the browser) but React is a great choice for server-side rendering too. And unless your initial rendering logic is as complex as the Netflix landing page's and the interaction logic is as trivial, you can just hydrate what the server spits out and go on from there.
The difference is that historically we used one code base to generate the initial markup and another to breathe life into it. With React we can do both with the same code. And in this case Netflix just skips the client-side rendering in favour of a tiny bit of JS (which means they're still using the same language which is still better than the mess we had in the early '00s).
