Okay, but can't you do that with HTML/CSS/JS? You can save collections of JavaScript functions, CSS class definitions, and HTML templates pretty easily. Re-using them is just a matter of copying them over to a new directory.
> Re-using them is just a matter of copying them over to a new directory.
And you lost me.
Is it possible to write reusable JS/CSS/HTML? Yes but the overhead is very frustrating and you will quickly find yourself building a custom framework to manage everything. Best to start with a framework from the start if you plan on having rich interactions. The speed at which I can move in VueJS is nothing short of amazing and the amount of reuse I get is extremely high, all without me having to manually manage a bunch of files/includes. With 1 TS import I can get all the HTML/CSS/JS for a component and safely use it in another component. At a minimum that would take 3 http calls in "vanillaJS" to fetch the html/css/js that I would need to maintain and update myself. SFC's are a game changer. Sure the browser might eventually support what I need but by that point I have no doubt that VueJS (or similar) will have lept further ahead.
It's the same reason I jumped on the 6to5/babel train early, it let me write my code in ES6 but still deploy to older browsers without waiting on everyone to upgrade.
Okay, so if I understand the main benefit is that you get to use a package manager and import statements? Also, don't you still need to manage tons of files, directories and config files in a React project? The React websites I've seen have way more complex directory structures than your average HTML/CSS/JS site.
I understand that at the start a pure HTmL/CSS/JS site appears easier (and to a large degree it is) but as soon as your project grows to a certain complexity the frameworks make life a million times easier. Also, once you’ve seen what the frameworks can do (handling the annoying stuff for you) it’s hard to go back even for simpler sites. Especially since we rarely know if a “simple site” is going to grow and need more functionality in the future at which point it would make sense to switch to a framework. Why not just start with the framework?
I’ve tried to go back to plain html/css/JS before and it’s a huge pain. I’m constantly thinking “ugh, this would be 2-3 lines of code in Vue but instead I have to manage all this stuff myself and it’s going to take 10’s of lines if not more. I’m not a fan of reinventing the wheel, also my skill set can be used everywhere if I write all my stuff in Vue instead of needing to context switch between smaller and larger projects (and again, small projects almost always grow so why not set them up for success?).
You could, but you'd be reinventing the wheel. You might start with some snippets you copy around, and every now and then you have to go back to all your previous projects to fix some change required in new browsers. So you might start using version numbers on your snippets you can figure out what you used when. But then you figure some HTML and CSS go really well together, so you try to put those snippets alongside each other and bundle them up. Your JavaScript probably needs to know which one of those HTML and CSS snippet bundles you are using, so you'll want to make sure that you specify which one you are using in your JavaScript.
At this point you're building a crappy version of a module and package manager, but all by yourself, nobody else is using your stuff, and you can't use their stuff either because it's not in your bespoke format.
All of the examples and concepts here are just inter-project related, but this applies within a project all the same.
You certainly can, and we did, with NodeBB. We use plain html, css, and js (with jquery) and a couple of bespoke components that work for our needs (templating engine, i18n, utils methods, etc.)
We call out to libraries when doing things that are better handled via a library.
Guess what, when you use a bespoke solution for common tasks, you end up with something that blows past every other competitor's benchmarks, without even trying.
