Based on that experience, I smile a little when I see people claiming that you can’t build significant web apps without a modern framework. Of course you can. The architecture for the app I mentioned has something close to a traditional MVC structure, uses a simple observer system for keeping everything in sync, and generally follows good modular design practices. Nothing about writing code for a web front end magically breaks all the UI ideas we’ve been using successfully in other environments for decades, and people have used those techniques to build UIs vastly more complicated than any web app ever written.
That all said, it’s also true that as the interactions between different parts of models and the rendering of views becomes more complicated in a UI, writing manual code to update the DOM via jQuery becomes tedious. I thought this article summed up the problem quite nicely with the code snippets and diagrams showing potentially SxR relationships between state and rendering when you manually and directly update the latter, compared with S+R relationships when you isolate each side with a good architecture.
So, I’d say the more interesting question if you’re building a not-small web app is whether you are better off building your own architecture or reusing someone else’s. That has the same trade-offs as any other framework decisions in programming; again there is nothing special about writing a web-based front-end really. On the plus side for a comprehensive framework, you get a lot of basic things much quicker than writing them yourself, and the popular frameworks have huge ecosystems built around them so a lot of not-so-basic things can be had relatively easily as well if you need them. On the minus side, in practice you will forever be constrained to work as the frameworks want, which can become a heavy burden later on if you do need to do things that aren’t a perfect fit, and you are locked into external dependencies with uncertain long-term support.
Something I find interesting about React is that although it’s often compared with big front-end frameworks like Angular, it’s really closer to a library than a framework. Fundamentally, you use React to do exactly one job: manage the rendering and events within a specific part of the DOM. It’s agnostic about where any underlying state comes from, what triggers updates to that state, what you’re doing in response to any events, or what you’re doing anywhere else in the DOM. The entire API for React doesn’t quite fit on a single screen, but a minimal working example only depends on three functions that feature in React’s defined interfaces, and even in real production code you probably won’t use more than a handful.
So if you’re the kind of developer who is concerned about bloat and dependencies but also wants to use good tools instead of reinventing the wheel, a library like React is probably a reasonable compromise between retaining control and long-term flexibility in your code but also automating things you really would waste quite a bit of time on otherwise. I suspect this balance is the main reason why it seems to attract favourable comments from a variety of developers, including those who generally don’t like the heavier frameworks and all that comes with buying into them.
Just by way of completeness, probably the most controversial aspect of React is the way it winds up with its version of HTML templates being embedded directly within the JS code (with some optional but convenient syntax that a preprocessor turns into real JavaScript). You aren’t likely to be getting one person/team designing your mark-up and styling and then having a separate person/team implementing your JS coding if you use React. In this respect it does also come with a degree of lock-in, because transferring those mark-up/template assets to another rendering library or framework later would be a chore. However, that’s somewhat true for most other template-rendering tools you might use as well, because they all tend have their own syntactic quirks, so I’m not sure it’s really worse than other reasonable choices you might make.
So in summary, you certainly can build web apps using manual, direct DOM manipulation via jQuery and the like, but you will also wind up inventing much the same kind of tools that many of these frameworks provide to a degree. There is a balance to be struck between retaining full control and flexibility vs. using good tools, just like any other programming with libraries and frameworks. As for React specifically, it really sits closer to the library end of the spectrum than a lot of modern JS frameworks, so if you do want a modern tool to help with rendering and managing events in your DOM but don’t like the big framework lock-in, it’s probably worth a little of your time to investigate whether it’s a good choice for your project.