Comment by nailer
11 years ago
Writing your own solution, when you could use a common widely known solution, exactly matches both writing your own left pad and inventing your own wheel.
> By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules.
If there was, it would have been published and people would be depending on it. Instead, people use the stdlib first, then big lego bricks like underscore, then (when they don't want the bulk of big lego bricks) smaller lego bricks. A single capitaliseMap() might be in there but it's a much more specific case than padding.
A 1-line of code module matches your needs exactly just for today. When you have 100 such modules which don't quite work and don't quite need after a month(quite a long time for a JS project to exist untouched), then your dependency hell shows its ugly head.
If you had years of experience in a wide array of technologies and languages, you'd be aware of that which is, and has been, obvious to the rest of us for the past 2-3 decades.
> A 1-line of code module matches your needs exactly just for today.
Nothing about function length determines utility. There are many one lines that match many people's needs repeatedly.
> When you have 100 such modules which don't quite work
This is worrying. How are you picking the modules you use? 100x popular modules from npm - with git repos, unit tests, READMEs, and hundreds of other users - beat 100x functions implemented in-house for NIH (or more likely, 100x functions copy pasted from Stack Overflow).
> If you had years of experience in a wide array of technologies and languages
Please don't assume things about other people. It's very rude, and it makes you look bad when you're wrong.
Worry not my friend. I'll take the risk of being wrong. Up to now, it seems that there's consensus on the fact that the JS/frontend world is the worst offender when it comes to engineering robust software.
At least there are JS programmers that seem aware of it and agree that this has to change. So there's still hope I guess.
5 replies →
But surely the really concerning part is despite their very wide usage, these dependecies turned out in some cases to be poorly coded functions indeed. Throughout this whole thread are examples where these one or two line "modules" have poor runtime performance, miss key cases in the one single thing they claim to do, and in the very worst cases, those small "modules" themselves are depending on many more "modules".
Diseases turtles all the way down.
> Throughout this whole thread are examples where these one or two line "modules" have poor runtime performance, miss key cases in the one single thing they claim to do, and in the very worst cases, those small "modules" themselves are depending on many more "modules".
Where? I've only seen the exact opposite: folk who don't believe in package management write their own naive 'reinvent the wheel functions' with those issues. Nobody I can see is quoting actual npm modules.