The web is not desktop applications. The network is always there, the network is slow, the network is asynchronous. The network can fail. You cannot abstract over this with a clever library. Unless you don't care about pushing out 4mb of javascript before first render, you can't ignore it.
The front-end is not a server based application. It's relatively straightforward to just echo out some html from a server. This works pretty well, and conceptually it's easy. But the UI has events. Events are asynchronous. You cannot abstract over this. It cannot be ignored. Unless all you need is the off the shelf components and no custom interactions, animations or logic.
Every UI framework for the front end is aimed at solving a specific problem, a specific complexity. Before adopting ANY of them, you have to seriously ask yourself if you actually have that problem before just jumping on the bandwagon- in most cases, in my experience, you probably don't. But by adopting some "framework" you've just added a problem. you've added a complexity. If you had the problem, it might be worth it. You might have netted less complexity.
But probably not.
Browsers have come a long way in 10 years, if you haven't been paying attention. Most of the cross browser problems have disappeared unless you're using new things like web sockets, web rtc or indexedDB, or something crazy like that. The browser is already a UI framework with all the basic widgets, text layout, image manipulation, audio processing, etc. etc.
From a perspective of a user of your website or service, ask yourself what value something like react is really adding.