What's interesting to me, as someone who is currently learning Web development mid-career, is that I can see that vanilla JS is actually a really good option nowadays, but not necessarily available to anyone who's more established. Because it doesn't seem to have gotten good until fairly recently, and, for the most part, everyone had already made the important technical decisions before that happened.
So, even if it's not necessary now, there's not necessarily any escape. The problem with complex tech stacks is that, for a variety of technical and social reasons, it's much easier to add to them than it is to take away. You can't necessarily incrementally roll back any of the bits of an existing React-based site; such an effort is liable to spiral into a complete rewrite. It's relatively easy, though, to incrementally add new things in order to paper over whatever's bugging you at the moment.
The social story is similar. Coming from a position of knowing very little, the effort for me to learn the vanilla JS way of doing things is roughly similar to the effort to learn the React way of doing things. But, if I were already invested in the React ecosystem, that wouldn't be the case. I wouldn't just have to learn new tooling, I'd also have to re-learn my entire way of thinking about how to architect a webpage. Realistically, you can't, all else being equal, justify a radical re-tooling in order to achieve an incremental benefit like that.
Pedantry time: there is no such thing as a vanilla JS way of building web applications, in the same way there is no vanilla C way of writing compilers. JavaScript as a language does not concern itself with web browsers - that's the responsibility of the DOM API. But even ignoring that, there is no standardized or widely adopted way to build interactive web applications without frameworks.
I'm new here, so maybe I'm misunderstanding some Web developer jargon? I had assumed that, when someone says "vanilla JS" in a web development context, it was understood to mean, "the core language plus the standard browser APIs."
"Vanilla C" maybe isn't a perfect analogy because the language and standard library are both covered by the same spec. But I suppose I would argue that it means, "Just C and its standard library, not including, for example, glibc extras." I don't know what a C equivalent to React would be. Maybe a better analogy would be "Vanilla Java", with the intent being to imply that you aren't using Spring?
You are correct. "Vanilla JS" is typically compared to React/Vue as a joke. As in "React.js is 2kb but Vanilla.js is 0kb and super lightweight".
"Vanilla C" doesn't have the same context as far as I'm aware. In the same spirit I could imagine a comparison for C would be along the lines of "you could use SDL (Simple DirectMedia Library) for your indie game dev, but why bother when you could use vanilla C (code Vulkan 3D graphics API directly)".
True, except for the fact Javascript would have no reason to exist without a web browser. Do you remember when Netscape 2.0 was released? That's when Javascript was born. Its primary use cases were form validation and image preloading.
You've betrayed your bias in your choice of words, though: "app." And, for that matter, choosing the word "as" instead of "if."
I'm not personally building apps, and I'm certainly not building things that need to be single-page apps. I'm building websites. They may be dynamic, they may include interactive elements on the page, but they're still mostly just plain old websites with limited state to manage. Which is fine by me. I suspect, that, were it not for those social constraints I described up above, that would be fine for most websites.
One of the other problems with complexity is that it's addictive. You get a taste of it in a situation where you actually need it, and next thing you know you're afraid to go anywhere without it, because you're worried (or is it hopeful?) that you might need it again.
There is a gaping chasm between a website that needs some Vanilla JS and light interactivity, to the point where a framework like React is a necessity though. Like if all you're using React for is to pop open a side menu or render some lists, you've taken on a boatload of tooling overhead for pretty minimal gain. Performance isn't going to be the problem there, the issue is having to maintain a relatively cumbersome tooling ecosystem for the site. That's not a contrived example either, I've seen plenty of that going on.
So, even if it's not necessary now, there's not necessarily any escape. The problem with complex tech stacks is that, for a variety of technical and social reasons, it's much easier to add to them than it is to take away. You can't necessarily incrementally roll back any of the bits of an existing React-based site; such an effort is liable to spiral into a complete rewrite. It's relatively easy, though, to incrementally add new things in order to paper over whatever's bugging you at the moment.
The social story is similar. Coming from a position of knowing very little, the effort for me to learn the vanilla JS way of doing things is roughly similar to the effort to learn the React way of doing things. But, if I were already invested in the React ecosystem, that wouldn't be the case. I wouldn't just have to learn new tooling, I'd also have to re-learn my entire way of thinking about how to architect a webpage. Realistically, you can't, all else being equal, justify a radical re-tooling in order to achieve an incremental benefit like that.