[philihp]

The appeal of React is that frontenders realized that the slow part of frontend is DOM manipulation. React keeps a virtual DOM, and only tells the browser to change those elements that actually changed. The big-picture explanation of this is it does this by maintaining data about your components, and it knows the difference between "state" things (that can change) and "properties" (that shouldn't ever change). Components are only rerendered when their data is dirty. Because React manages this for us, it saves us a lot of code and brainpower, while keeping our stuff fast.

I have been told that .NET works in a similar way, but with a key difference of that diffing happening on the server, so it isn't as fast. This is just hearsay, please don't take my word for it, I don't claim to know how .NET works.

What's with that 200+ line package.json? That's like a makefile, with everything already configured for you. Sure, it's a lot of tooling, but you could say the same about most software development tooling. Why is XCode 4 gigs? That's a lot of libraries just to create simple mobile apps. Back in my day, all we needed was a tiny WML XML 200 byte file to display to a cell phone. And yet, here we are, in the future.

[WickyNilliams]

.NET doesn't work like that. Why would a server have to diffing? It's outputting a string, no concept of the DOM.

Perhaps you're thinking of components (or "controls" as they're known) in WebForms for .NET? They had a component style architecture but everything about them was difficult to understand and hard to use. Compared that to React where components are cheap and easy to build/compose, to such an extent that almost everything even things which don't actually render their own UI) ends up as components in React.