Live data from Hacker News

The fate of "small" open source

nolanlawson.com

231–238 of 238 posts

Re: The fate of "small" open source

#232
I totally agree that the goal should be teaching. But I do wonder which code someone is more likely to actually read and understand: the LLM-generated one in their own codebase, or the one hidden in some npm package they installed to just ship things. I honestly don’t know. Careless devs probably won’t read either as long as it seems to work

I’ve been trying to encourage forking my libraries, or have people just copy them into their codebase and adapt them, e.g. https://github.com/mastrojs/mastro/ (especially the “extension” libs.) But it’s an uphill battle against the culture of convenience over understanding.

Re: The fate of "small" open source

#234

Less incentive to write small libraries. Less incentive to write small tutorials on your own website. Unless you are a hacker or a spammer where your incentives have probably increased. We are entering the era of cheap spam of everything with little incentive for quality. All this for the best case outcome of most people being made unemployed and rolling the dice on society reorganising to that reality.

I was searching a specific niche on Youtube today, and scrolled endlessly trying to find something that wasn't AI generated. Youtube is being completely spammed.

That was true even before llms

Re: The fate of "small" open source

#235
post #145

Earlier quoted context omitted.

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? Because javascript isn't compiled. Its distributed as source. And that means the browser needs to actually parse all that code before it can be executed. Parsing javascript is surprisingly slow. 70kb isn't much on its own these days, but it adds up fast. Add react (200kb), a couple copies of momentjs (with bundled timezone databases, of course) (250kb or something each) and som…

Your answer proves my point.

You explained why 70kb is bad by pointing out that 3000kb isn't particularly outlandish.

Re: The fate of "small" open source

#236
post #116

Earlier quoted context omitted.

What's your copy& paste solution to security updates?

Does left-pad have security updates? You may as well ask what's the security update solution for Stack Overflow answers.

Does every single small package have a guaranteed security profile of left-pad?

Re: The fate of "small" open source

#237
post #116

Earlier quoted context omitted.

What's your copy& paste solution to security updates?

The security maintenance of the ten lines of code I have read and copied into my code is the same as the ten lines of code next to it, that I have written myself.

It can't be the same. The package is public, so you get some benefit of other people reviewing and your tools notifying you of issues. Or do you really mean you ignore all that info?

Re: The fate of "small" open source

#238
post #219

> the era of small, low-value libraries like blob-util is over. Thankfully (not against blob-util specifically because I've never intentionally used it), I wouldn't completely blame llms either since languages like Go never had this dependency hell. npm is a security nightmare not just because of npm the package manager, because the culture of the language rewards behavior such as "left-pad". Instead of writing endle…

Another thing about Go, and more generally, the statically-typed languages, is that these utility functions are generally safer to get a once-over and a commit into the code base than in dynamically-typed languages. Something that joins an array of strings with a joiner in some non-trivial way is a lot easier to review when you don't have to worry about it getting an array of DOM nodes and a NaN for the join characte…

Bad take. In the first place, the appropriate time order of magnitude for how long static type checkers have existed for JS is "decades". In the second place, the function that "joins an array of strings with a joiner" is the wrong place to worry about whether that array is actually an array of DOM nodes or the joiner is NaN.
Post reply on HN