>Overall, I'm not 100% sure I made the right choice, but I only have to live with it for two years.
People are great at short term thinking, and tend to be terrible at long term thinking. Just some anecdata: I had a look at some source code for a 10+ year old web app before JS libraries were popular. I could understand perfectly how a click on a link resulted in a URL hash change and how the hash change resulted in updates on the page. Nowadays it would be written off as coding your own framework since web developers can't be trusted to code without a framework anymore. But it worked with the least amount of indirection possible and it was simple to understand 10 years later. Web apps today just get rewritten every two years.
Don't worry, the simpleness and adequateness of plain old JavaScript (+ maybe jquery) and basic web techniques is re-discovered like every 5 years. Right now, we're at the height of the React hype cycle which just means we're approaching its imminent downfall due to generational forces (though I still do like some aspects of React specifically).
Sorry to sound defaitist, but like you say, the goal of React (and AngularJS, vue, ...) is to simplify web frontend development and improve maintainability. But these cost benefits are offset by their (absurd, IMHO, for most use cases) upfront complexity and thus can't possibly be attained within two years. Also, the desire to work in an agile fashion where everybody should be able to do everything (back- and front-end work) works against expert/thermonuclear front-end development tools.
A critical point about these types of frameworks it that their benefits wont necessarily outweigh the complexity they bring to every project, and specifically they are likely to be needlessly complex in smaller projects.
In larger or long-term projects though the ability to use formal conventions to break down an app into components that have solid documentation already written on how to do this or that in a way that will scale and extend is quite valuable.
Additionally being able to reach out to a large community of developers who use similar conventions and plugins is quite valuable for troubleshooting those 10%/90% problems or finding a drag-n-drop solution that's compatible with your stack.
Yes, you can understand a 10+ year old web app's JavaScript, but that's because there was very little JavaScript on it to begin with.
I used to write a lot of jQuery, and in my experience once the code on a page became longer than ~500 lines, it became significantly more difficult to wrap one's head around.
With the new tools the baseline for understanding the code is higher, but if you meet that baseline then you can grok code that is much more complex.
>Overall, I'm not 100% sure I made the right choice, but I only have to live with it for two years.
People are great at short term thinking, and tend to be terrible at long term thinking. Just some anecdata: I had a look at some source code for a 10+ year old web app before JS libraries were popular. I could understand perfectly how a click on a link resulted in a URL hash change and how the hash change resulted in updates on the page. Nowadays it would be written off as coding your own framework since web developers can't be trusted to code without a framework anymore. But it worked with the least amount of indirection possible and it was simple to understand 10 years later. Web apps today just get rewritten every two years.