To the best of my knowledge, React is indeed the first "mainstream" UI framework for JavaScript to be so fundamentally built around a virtual DOM. I think as a minimum the React team deserve credit for popularising the idea and for raising awareness of the underlying performance characteristics of browsers that make the idea relevant in practice.

That said, many of the "big ideas" that have been popularised among front-end web developers in recent years by big name frameworks are not even remotely new to the programming world as a whole.

For example, it's hardly news to anyone who's worked on browser-based UIs that DOM updates are often the bottleneck. However, back in the days of IE6/7 and the early versions of Mozilla or even Firefox and Chrome, JS generally and DOM updates in particular were far slower than they are in modern browsers. People have been writing UI code specifically to minimise DOM updates since long before the likes of Angular and React came along, because what is done today as a performance boost for relatively large and complicated pages used to be a necessity to get acceptable performance out of any JS-based UI at all (the major alternatives being either plugins like Flash or Java, which ran routine UI code much faster in those days, or doing pretty much all of the work server-side using old school web forms).

It's also hardly news to anyone who worked with client-server apps a few years ago, when again things were much slower and more specifically bandwidth was a fraction of what we enjoy today, that sending patches instead of complete data can be an easy performance win. (People have been using the rsync technique for a couple of decades or so.) In the early days of what we might now call web apps, before JSON won and everyone had numerous JSON-friendly persistence and data binding libraries to choose from, a comedian developed a format called XML that accidentally caught on when too many people didn't realise it was a joke. (See also: XMLHttpRequest, the standard tool for retrieving JSON data from servers everywhere.) In order to avoid half the development team retiring before the first test XML data had finished downloading on a typical project, we got pretty good at designing diff/patch formats for these kinds of nested data structures.

Put those two ideas together, and as you can imagine, a lot of web developers wrote a lot of ad-hoc tools whose basic purpose was to take some sort of change set for the underlying data model as input and figure out some sort of reasonably small set of DOM updates to match. The canonical example would be something like updating a container in your underlying data model, where you couldn't afford to rewrite a whole list or table element in your DOM for each inserted/changed/deleted element in the container, so you had to bundle up the changes transaction-style and then flag the DOM for a single update at the end.

Obviously we've learned a lot since the early versions of this, and today we enjoy templating and data binding libraries that can be dropped into projects with negligible effort but do the same jobs we used to spend many days automating on each new project, with all the usual benefits of consolidation and peer review that come from having generic libraries with many users and many contributors. No doubt some of the techniques used in modern frameworks like React are far more widely applicable and systematic than a lot of the old code we used to use. So in this sense, again, perhaps the React team deserve some credit for advancing the state of the art.