Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. If you are spending time on authentication or forms or worker queue architecture, you’re wasting time. Frameworks and plug-ins exist to allow this to be all plug and play, so you can focus on building something potentially useful enough for people to pay for it.
Product market fit is generally achieved when you can’t keep up with demand for your product. “Can’t keep up” is generally an operational problem first, then a technical problem (the Do Things That Don’t Scale stuff catches up to you basically).
Scaling is a GOOD problem…as long as you actually have a business model. If you’re selling stuff but getting crunched by demand and your tech is cracking at the seams…hell yes! Pay people to fix the tech/replace the janky or slow stuff/automate manual things.
If you don’t have a business model, you can scale the shit out of some idea but not be able to afford to fix the issues coming from breaking out of your frameworks. Not to say you can’t eventually make this model work, you just have to raise a shit ton of money to do it usually.
Use frameworks. It’s not a debate. Don’t reinvent wheels when you’re trying to invent some new product idea.
Only work on the product.
> 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.
> shop-tuned version in say 300 lines
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.
You would think that, but this seven line NPM package has 68M downloads a week - https://www.npmjs.com/package/isarray
NPM statistics are easily gamed https://dev.to/andyrichardsonn/how-i-exploited-npm-downloads...
I don't doubt there are a lot of insignificant packages being used, again especially by beginners, I just don't buy it's to that scale
There's also the classic left-pad debacle - https://github.com/left-pad/left-pad/issues/4
[1] - https://github.com/motdotla/dotenv/blob/master/package-lock....
[2] - https://github.com/npm/cli/blob/latest/package-lock.json