Live data from Hacker News

NPM and Left-Pad: Have We Forgotten How to Program?

haneycodes.net

261–270 of 887 posts

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#261

Earlier quoted context omitted.

With the advent of ES6 modules's selective imports and tree-shaking, that's definitely quickly becoming a better approach. With the old CommonJS modules, you need to be concerned about overall code size, which is where small, single purpose modules excel, and why this approach has proliferated to this degree.

I've been reading about tree shaking. I'm not at my laptop at the moment, so I can't settle this question by testing it. I'll toss it to the community: https://news.ycombinator.com/item?id=11349606 Basically, how does tree shaking deal with dynamic inclusions? Are dynamic inclusions simply not allowed? But in that case, what about eval? Is eval just not allowed to import anything? I've been reading posts like these,…

> Are dynamic inclusions simply not allowed?

Correct. One of the motivating factors for ES6 modules was to create a format that can be statically analyzed and optimized.

> Is eval just not allowed to import anything?

Correct.

See this excellent writeup for more details regarding ES6 modules: http://www.2ality.com/2014/09/es6-modules-final.html

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#262

Earlier quoted context omitted.

OR: you depend on a specific version of the library, that you know that works, and you have none of those problems.

You can't escape problems by bundling specific library versions. You just get a different set of problems. When you require a specific version of a library, you're making your code incompatible with anything that requires a higher or lower version of that library. You're also assuming there will never be a security fix that requires you to update your dependency.

More importantly, if you only use a specific version of a library, you're opting out of literally every one of the advantages of micro-libraries that people claim they offer. Tying yourself to a single version is the same as copy-pasting the code right into your project, except it doesn't force you to look at the code and vet it.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#263
post #58
post #7

Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…

Similarly, the `average` package on NPM is one that I came across: https://www.npmjs.com/package/average var average = require('average'); var result = average([2, 5, 0, 1, 25, 7, 3, 0, 0, 10]); console.log('The average for all the values is:', result); It's hard to not stare at that in complete disbelief; someone thought that it was worthwhile to create a package for determining the mean of an array of numbers.

That package is, at best, average...

ducks

(Edit: typo)

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#264

Earlier quoted context omitted.

This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/a…

You'd have a good point, if all of those tiny but probably useful modules were given the use you're describing. Discoverability though is so poor that most of those modules are most likely just used by the author and the author's co-workers. If a typical npm user writes hundreds of packages, how the hell am I supposed to make use of them, when I can't even find them? Npm's search is horrendous, and is far from useful…

Discoverability though is... poor seems like an argument for improving discoverability, not against having small modules.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#265
post #98

I find NPM packaging ridiculous. Awhile I go I used NPM on windows, where the folder hierarchy became so deep it broke windows file handling. I could not delete the modules folder. I had install a npm package which allowed me to delete it. I think this is fixed in new versions by flattening the hierarchy, but still.

I've been there. If I recall correctly, I found that a "rmdir /s" from a command prompt does the trick.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#266
Without addressing the wisdom or lack thereof of including dependencies for small functions, perhaps the problem of disappearing/changing small dependencies could be solved with an option along the lines of

    npm install   --save-inline
Which would just copy the dependency verbatim to . Maybe have a " is 100kb. Are you sure you wish to copy the entire source to instead of using a 'require' reference? y/n" prompt for the inevitable silly types who'd do it with Angular.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#267
post #5

I think it speaks to just how lacking the baseline Javascript standard library is. The libraries that come with node help, but all of this stuff seems like it should be built-in, or at least available in some sort of prelude-like standard addon library. The lack of either leads to all these (apparently ephemeral) dependencies for really simple functions like these. That said, I work with Java, Clojure and Python most…

I think in some ways a good standard library is a measure of programming language maturity. I remember when C++ had a lot of these problems back before you had the STL etc. In the early 90's it was a dog's breakfast.

We have a large internal C++ app at my work of that vintage (~1992) it uses its own proprietary super library (called tools.h++) which is just different enough from how the C++ standard evolved that its not a simple task to migrate our codebase. So now every time we change hardware platforms (has happened a few times in last 30 years) we have to source a new version of this tools++ library as well.

I find it amusing Javascript hasn't learnt from this.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#269
post #188

Earlier quoted context omitted.

I can't speak for him, but upgrading really old Rails apps can get complicated very quickly. Especially when you're going across multiple major versions and have to deal with significant changes in Rails behavior and broken gems. "Rebuild" might not be the most accurate way to describe the slow, steady incremental approach you're forced to take (you aren't redoing huge swaths of your domain logic, for instance), but…

Rebuilding for most cases seems silly to me. I've been working on a .net web app, that's been around since 2008. It's been continually evolved, so it's running on the latest MVC framework, uses microservices etc As result it's build up a huge amount of automated tests. The business logic has been built up from experience and is well tested even for odd cases. You throw away a lot of stuff for a rebuild.

I could not not-rebuild... All I had was a git repo.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#270
post #7

Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…

This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/a…

I don't see how your linked comment brings more to the table than the basic arguments for code reuse.

But naturally, with any code reuse there's a benefit and a cost to instance of internal or external reuse.

The Benefits for external reuse include ideal reliability as your describe as well as not having to create the code. The costs for external reuse include having your code tied to not just an external object but also the individuals and organizations creating that object.

I think that means that unless someone takes their hundreds of modules from the same person or organization and is capable of monitoring that person, that someone is incorporating a layer of risk to their code that they don't anticipate at all.

Post reply on HN