> Frameworks and plug-ins exist to allow this to be all plug and play
Too many are buggy and/or poorly documented and take lots of trial and error to get working as intended. And you create a dependency mess by including lots of pluggins/libraries. It may be quick up front, but can jack maintenance after say 5-ish years. Multi-K-lines-of-code libraries "rot" as environments change. If you can write a shop-tuned version in say 300 lines, do it, because it's easier to fix later. Select vendor libraries/pluggins judiciously.
IMO, aggressive npm install is the superset of the framework problem. We code review every line written by other developers at our company with a fine toothed comb, but will add a dependency from a massive advertising company or some dude in Russia without a second thought. It’s wild.
This is true and in experience happens far quicker than 5 years for JS frameworks. Most of the frameworks I learned 5-10 years ago are already effectively dead too.
But I think OPs main point stands, your far more likely to die by not shipping things early than by having to refactor occasionally. After 5 years 50% of businesses have failed [0] and this is far far higher for startups & side projects.
I just pulled in a class-based component into a modern React project. It just worked with no adjustment.
Now that's commitment to backward compatibility (and they can't have it any other way, they won't rewrite half of facebook just because their own framework changed).
> your far more likely to die by not shipping things early than by having to refactor occasionally.
Know your org. A startup has very different priorities than a bank, for example.
Small projects need different conventions than big projects, internal need diff than external, 200 user apps need diff than "web scale", etc. I'm more careful now to state the assumed environment because one size doesn't fit all. And fit your org, not your resume. Buzzword oriented programming is selfish; I've seen it make screwball messes.
But if that was the case, you would do that, resorting to other tools for something that tiny is silly and only really done by beginners. Something that tiny would also unlikely have bug or documentation issues.
There are some great tools that are poorly documented/buggy, yes, but they are quite rare and it's much easier to use them and fork the repo (if inactive) than to build from scratch.
This idea that you avoid creating a dependency mess by writing more of your own work, isn't the entire truth. The dependency is just internal, and far more likely to have poor documentation than open source plugin #4159. So you really haven't solved or avoided the problem at all.
It's pretty easy to find that the example I gave isn't gamed... A cursory search on GitHub can find a couple examples like dotenv [1] and npm's cli [2] both use it via an older version of nodejs/readable-stream [3].
> This idea that you avoid creating a dependency mess by writing more of your own work, isn't the entire truth. The dependency is just internal
The point is that it's better to depend on something simple and quickly fixable than something convoluted. Vendors/sponsors can and do go away.
If you have a skilled API builder, they know how to do KISS. If a specific need requires something that's not KISS-able, such builders will be honest about it and recommend a pluggin. But every shop and domain is different such there are indeed cases where throwing libraries at the problem is the right tool for that particular job.
Too many are buggy and/or poorly documented and take lots of trial and error to get working as intended. And you create a dependency mess by including lots of pluggins/libraries. It may be quick up front, but can jack maintenance after say 5-ish years. Multi-K-lines-of-code libraries "rot" as environments change. If you can write a shop-tuned version in say 300 lines, do it, because it's easier to fix later. Select vendor libraries/pluggins judiciously.