←back to thread

295 points todsacerdoti | 1 comments | | HN request time: 0.31s | source
Show context
noosphr ◴[] No.45949148[source]
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.

replies(5): >>45949409 #>>45949466 #>>45949548 #>>45949614 #>>45952603 #
SchemaLoad ◴[] No.45949466[source]
The best outcome was things like jquery and then lodash where a whole collection of small util functions get rolled in to one package.
replies(1): >>45950575 #
josephg ◴[] No.45950575[source]
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.

replies(4): >>45950988 #>>45951555 #>>45951828 #>>45951926 #
friendzis ◴[] No.45951926[source]
> 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.

replies(2): >>45953033 #>>45953624 #
1. zahlman ◴[] No.45953033[source]
> 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).

... Sorry, what does that have to do with tree shaking?