LLMs give us the opportunity to work on more complex projects and gain fuller understanding of the problem space and concepts. Or create tons of slop. Take your pick.
The fate of "small" open source
141–150 of 238 posts
Re: The fate of "small" open source
#142 Given that some 80% of developers are now using AI in their regular work, blob-util is almost certainly the kind of thing that most developers would just happily have an LLM generate for them. Sure, you could use blob-util, but then you’d be taking on an extra dependency, with unknown performance, maintenance, and supply-chain risks.
Re: The fate of "small" open source
#143This author assumes that open sourcing a package only delivers value if is added as a dependency. Publicly sharing code with a permissive license is still useful and a radical idea.
A copyleft license is much better because it ensures that it will remain open and in most cases large companies won't use it, making sure they will have to shell out the money to hire someone to do it instead.
Re: The fate of "small" open source
#144Earlier quoted context omitted.
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.
Not really familiar with TS, but what would be so weird with the typing? Wouldn't it be generic over `T -> U`, with T the type with snake_case fields and U the type with pascalCase fields?
Turns out in TypeScript you can model the conversion of the keys themselves from snake_case to pascalCase within the type system[0]. I assume they meant that this was the difficult part.
[0]: https://stackoverflow.com/questions/60269936/typescript-conv...
Re: The fate of "small" open source
#145Earlier quoted context omitted.
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. Exper…
Unless you're part of the demoscene or your webpage is being loaded by Voyager II, why is 70kb of source code a problem?
Not wanting to use well constructed, well tested, well distributed libraries to make code simpler and more robust is not motivated by any practical engineering concern. It's just nostalgia and fetishism.
Re: The fate of "small" open source
#146Re: The fate of "small" open source
#147The level of apologetism with regard to ai is depressing in this article.
Re: The fate of "small" open source
#148Earlier quoted context omitted.
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. Exper…
> 400 bytes of source code becomes 70kb in an instant,
This only shows how limited and/or impractical dependency management story is. The whole idea behind semver is that at the public interface level patch version does not matter at all and minor versions can be upped without breaking changes, therefore a release build should be safe to only include major versions referenced (or on the safe side, the highest version referenced).
> Its such a common junior move. Ugh.
I can see this happening if a version is pinned at an exact patch version, which is good for reproducibility, but that's what lockfiles are for. The junior moves are to pin a package at an exact patch version and break backwards compatibility promises made with semver.
> Experienced engineers know how to pull in just what they need from lodash. But ...
IMO partial imports are an antipattern. I don't see much value in having exact members imported listed out at the preamble, however default syntax pollutes the global namespace, which outweighs any potential benefits you get from members listed out the preamble. Any decent compiler should be able to shake dead code in source dependencies anyway, therefore there should not be any functional difference between importing specific members and importing the whole package.
I have heard an argument that partial imports allow one to see which exact `sort` is used, but IMO that's moot, because you still have to perform static code analysis to check if there are no sorts used from other imported packages.
Re: The fate of "small" open source
#149Earlier quoted context omitted.
I don't think searching for answers to simple questions was a problem until Google nerfed their own search engine.
I don't understand this position, do you have direct evidence that Google actively made search worse? Before I'm misunderstood I do want to clarify that IMO, the end user experience for web searching on Google is much worse in 2025 than it was in say 2000. But, the web was also much much smaller, less commercial and the SNR was much better in general. Sure, web search companies moved away from direct keyword matching…
> In light of that, I'm much more inclined to believe that it's SEO spam becoming an industry that killed web search instead of companies "nerfing their own search engines".
"SEO" is not some magic, it is "compliance with ranking rules of the search engine". Google wanted to make their lives easier, implemented heuristics ranking slop higher, resulting in two things happening simultaneously: information to slop ratio decreasing AND information getting buried deeper and deeper within SRPs.
> do you have direct evidence that Google actively made search worse?
https://support.google.com/google-ads/answer/10286719?hl=en-... Google is literally rewriting the queries. Not only results with better potential for ads outrank more organic results, it is impossible to instruct the search engine to not show you storefronts even if you tried.
Re: The fate of "small" open source
#150Earlier quoted context omitted.
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. Exper…
Unless you're part of the demoscene or your webpage is being loaded by Voyager II, why is 70kb of source code a problem? Not wanting to use well constructed, well tested, well distributed libraries to make code simpler and more robust is not motivated by any practical engineering concern. It's just nostalgia and fetishism.
> why is 70kb of source code a problem?
It isn't but then everyone does it and then everyone does it recursively and 70kb become 300MB and then it matters. Not to mention that "well constructed, well tested, well distributed" are often actually overengineered and poorly maintained.