Hacker News Reader

Comment by jackewiehose | Hacker News Reader

I think these one-line-packages aren't the right way to go. Either JS-developers should skip the package-system in that case and just copy and paste those functions into their own project or there should be more common used packages that bundle these one-liners. I mean is_promise() and left_pad() are not worth their own package. Packages-dependencies of 10000 packages for trivial programs are just insane.

Is someone going to fix that?

View on HN

>Is someone going to fix that?

Probably not. There is too much code in the wild, and NPM owns the entire JS ecosystem, and there has been too much investment in that ecosystem and its culture at this point for a change in course to be feasible.

The JS universe is stuck with this for the foreseeable future.

It's just a cultural problem. There's no reason why a library should abstract away `typeof obj.then === 'function'` if they want to check if something is a promise. Just write a one-liner the same way you don't pull in a `is-greater-than-zero` lib to check x>0.

The problem is when you try to level criticism at this culture and a cloud chorus of people will show up to assert that somehow tiny deps are good despite these glaring issues (a big one just being security vulns). And funnily enough, the usual suspects are precisely people publishing these one-liner libs. Then people regurgitate these thoughts and the cargo cult continues.

So there's no "fix" for NPM (not even sure what that would mean). I mean, anyone can publish anything. People just have to decide to stop using one-liner libs just because they exist.

Does it need much to change? I didn't mean to fix NPM. The problem is the non-existing standard-library. Just create one that everybody will use and everybody could cut their dependencies by thousands.

Several of these already exist, like lodash and underscore (which is a subset of lodash). After the rapid improvements on both the browser and node sides of the last couple of years (which filled in many of the blanks in this hypothetical "standard library"), they are less necessary than they may have been before. Also they can become something of a crutch. Fixing a bug a couple of days ago, I realized that an argument of Object.assign() needed to be deep-copied. Rather than adding a dependency for lodash or underscore or even some more limited-purpose deepcopy package, I just figured out which member of the object needed to be copied and did so explicitly. Done.

Another good way to not have to depend on big/tiny/weird modules published by others is to use coffeescript. So much finicky logic and array-handling just goes away.

Not everyone would use it, that's my point. The inertia behind the existing system is too great, especially in enterprise. All that would happen is that library would become just another Node package, and then you've got the "n+1 standards" problem.

The "nonexistent standard library" wasn't a problem in the days when javascript development meant getting JQuery and some plugins, or some similar library. It only became a problem after the ecosystem got taken over by a set of programming paradigms that make no sense for the language.

Yes, in my mind you'd have to change everything from the ground up, starting with no longer using javascript outside of the browser.

> Not everyone would use it

If the right people would provide the library, it would be used by enough people.

> Yes, in my mind you'd have to change everything from the ground up, starting with no longer using javascript outside of the browser

Whats the point of inside or outside of the browser?

The point is that different languages are best suited to different tasks. Javascript is a simple, very loosely typed scripting language with prototypal inheritance that was developed to be run in the browser. It's a DSL, not a general purpose programming language. Using it elsewhere for applications where another language with stronger and more expressive types would be more appropriate requires hacks like compiling it from another (safer, more strongly typed) language like Typescript, which still results in code that can be fragile because it only simulates (to the degree that a JS interpreter allows) features that the language doesn't actually support.

See the attempt to "detect if something is a Promise" as an example - the function definition for the package makes it appear as if you're actually checking a type, but that's not what the package does.

Most of the unnecessary complexity in modern JS, as I see it, comes from the desire to have it act and behave like a language that it simply isn't.

> It's a DSL, not a general purpose programming language

Sorry, but I fear that ship has sailed ;-)

And I've heard JS was developed by someone who wanted to give us Scheme (you can't go more general purpose than that) but had to resort to a more "friendly" java-syntax. IMHO javascript would be a great general purpose language if the ecosystem wouldn't be such a mess.

>Sorry, but I fear that ship has sailed ;-)

I know, I know. If anyone needs me I'll be in the angry dome.

Isn't this what "utility libraries" like lodash and jQuery (each for their respective domains) are for?

I see a lot of criticism to one-line packages, but IMO in the end what matters is the abstraction.

Thinking of the package as a black box, if the implementation for left-pad or is-promise was 200 lines would it suddenly be ok for so many other packages to depend on it? Why? The size of the package doesn't make it less bug-prone.

I see plenty of people who are over-eager to always be up-to-date, when there really isn't any point to it if your system works well, and so they don't pin their versions. This will break big applications when one-line packages break, but also when when 5000-line packages break. Dependencies are part of your source, don't change it for the sake of changing it, and don't change it without reviewing it.

> The size of the package doesn't make it less bug-prone.

Of course it does. It's more bug-prone just by being a package. More code is more bugs and more build-system annoyance is more terror (=> more bugs). If I only need one line of functionality I will just copy and paste that line into my project instead of dealing with npm or github.

> Dependencies are part of your source

I agree. If you see news about broken packages like this and you don't just shrug your shoulders your build-system might be shit.

It would be more ok if left-pad was part of a package called, say, text-utils which also included right-pad, etc. Same with is-promise, it sounds like it should be a function in a package called type-checker.

Reply on news.ycombinator.com