I don't doubt any of that. But recently I had to choose a framework, and after evaluating all our choices, I ended up choosing plain ol' php, and as vanilla as we could get javascript. For a lot of reasons, but the most important ones were this:
- Next year, the new kid on the block will be the most amazing thing ever created (tm) and everything else will be obsolete (knockoutjs, angular just to name a few)
- If you pack everything now and leave the code untouched, in a couple of months there's a big chance half your tools will need upgrading (angular?) When you upgrade, half the things won't work and you will spend a ton of time fixing things that were perfectly working before, just to get the thing compiling again
-If, down the line, someone else has to take the work where we left, not having the exact development machines set up, they're going to have it much harder to make simple fixes.For example, in six months of development, a simple datepicker javascript library changed the way where it declares the locale config, and we needed to change every declaration of that function to make it work everywhere again. When a framework deprecates a function that you use while you're in development, you fix it. If someone has to pick the project two years later, they are f*
With "old" stuff this doesn't happen. Sure, if you pick php 3 code and try to run it in PHP 7 you'll find problems, but nothing like with webpack/yarn/whatever is doing the packing work this month
Nowadays is all Vue and react, a couple years ago it was Ruby, next year will be something else. In the end, whatever works for you will be good enough, but if you have to think in advance and try to get some future proof code, half the things that are 'what needs to be used right now', will be unmanageable legacy code a year or two down the line
(Just my two cents)