Comment by noosphr
9 hours ago
I see this as an absolute win. The state of micro dependencies of js was a nightmare that only happened because a lot of undereducated developers flooded the market to get that sweet faang money.
Now that both have dried up I hope we can close the vault door on js and have people learn how to code again.
The best outcome was things like jquery and then lodash where a whole collection of small util functions get rolled in to one package.
Oh god, without tree shaking, lodash is such a blight.
I've seen so many tiny packages pull in lodash for some little utility method so many times. 400 bytes of source code becomes 70kb in an instant, all because someone doesn't know how to filter items in an array. And I've also seen plenty of projects which somehow include multiple copies of lodash in their dependency tree.
Its such a common junior move. Ugh.
Experienced engineers know how to pull in just what they need from lodash. But ... most experienced engineers I know & work with don't bother with it. Javascript includes almost everything you need these days anyway. And when it doesn't, the kind of helper functions lodash provides are usually about 4 lines of code to write yourself. Much better to do that manually rather than pull in some 70kb dependency.
The problem with helper functions is that they're often very easy to write, but very hard to figure out the types for.
Take a generic function that recursively converts snake_case object keys to pascalCase. That's about 10 lines of Javascript, you can write that in 2 mins if you're a competent dev. Figuring out the types for it can be done, but you really need a lot of ts expertise to pull it off.
I agree the JS standard library includes most of the stuff you need these days, rendering jquery and half of lodash irrelevant now. But there's still a lot of useful utilities in lodash, and potentially a new project could curate a collection of new, still relevant utilities.
3 replies →
Your first sentence cheers that we're moving from NPM micropackages to LLM-generated code, and then you say this will result in people having to learn to code again.
I don't see how the conclusion follows from this.
There will be many LLM-generated functions purporting to do the same thing, and a bug in one of them that gets fixed means only one project gets fixed instead of every project using an NPM package as a dependency.
There will be many LLM-generated functions doing the same thing, in the same project, unless the human pays attention.
I've been playing a lot recently with various models, lately with the expensive claude models (API, for the large context windows), and in every attempt things are really impressive at the beginning, and start going south once the codebase reaches about 10k to 15k lines of code. Even with tools split out into a separate library and separate documentation at that point it has a tendency to generate tool functions again in the module it's currently working on over taking the already defined one in the helper library.
You mention that you don’t see how this could result in developers that write code. Then you immediately follow that with fixing bugs.
Yes, use of LLMs is still developers not writing original code, but it’s still an improvement (a minor one) of the copy/paste of micro dependencies.
Ultimately developers aren’t going to figure out writing original code until they are forced to do so from changed conditions within their employer.
Now you got vibe coder
I don't quite understand your argument. Wasn't the post about how users might replace transparent dependencies with transparent LLM drop-ins? I don't see how having an LLM to do the same job would enable someone to learn more. They're probably the kind of person who will ask the LLM to perform a refactor when problems arise, so they won't learn that much through osmosis.