Hacker News Reader

Comment by weiming | Hacker News Reader

My pet peeve is each one of these (Webpack, Parcel, Brunch, $your_favorite_alternative) involves a very bloated node_modules folder and so many dependencies that no sane person with have time to verify by hand.

A vanilla install of Phoenix with Brunch yields a node_modules with 388 packages. What are the odds of one of them becoming rogue due to a hack, and how would I know?

Add to this the overall (perhaps perceived) fragility of having to maintain a node project and fumbling with JavaScript. Node was a great new thing for server-side stuff, but whose idea was it to start using it for building every single command-line tool?

View on HN

It's a common pattern in JS to use many small packages over fewer large ones. Some maintainers might take this too far, breaking their package up so that each function gets its own package. That is how you get 388 dependencies in complex packages.

A vanilla install of Phoenix with Brunch yields a node_modules with 388 packages

Look at what Phoenix (https://hexdocs.pm/phoenix/overview.html) and Brunch (https://brunch.io/) can do. To suggest 388 packages for all that stuff is too much is ridiculous - there's a lot of functionality, so there's a lot of code. The fact that it's not one huge, opaque blob is a good thing. Could they be implemented with less code? Maybe. Does that mean they'd be better for it? I don't think I've ever come across a reasonable argument that says 'less code is always better'.

You could very reasonably argue that you don't need all those features, and maybe the two things are bloated. I would suggest that means you've picked two things that do way more than you need, and you've not chosen your tech stack very well.

Phoenix is actually very agnostic as far as asset packaging goes, one can swap Brunch for Webpack or Parcel (or nothing) easily. So it's not to say those 300+ build-time-only node packages have anything to do with Phoenix (or Elixir, or Erlang's) ability.

there are many reasons while less code is better -- https://blog.codinghorror.com/the-best-code-is-no-code-at-al...

"very new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity."

More code, more bugs, more issues. 388 packages is ridiculous compared to practically every major system including operating systems. Javascript is Stockholm syndrome.

Using packages means less code, not more, since you're not rewriting the wheel every time.

Technically not if packages are just the misguided habit of "one package per function" seen in the Node ecosystem. Same amount of code, increased amount of complexity/meta-problems to deal with.

> Technically not if packages are just the misguided habit of "one package per function" seen in the Node ecosystem.

No. Using a package for a single function doesn't preclude code reuse.

Look at underscore.get package. You could write your own recursive key finder (which I have before), and so could every package author, and you'd have 10x the amount of implementations of a recursive key finder.

A single require of underscore.get by you and other authors means you have a single, well tested implementation with a million other users rather than 10 low quality ones.

Why not one package per line of code? One package per expression? Surely, someone will want to reuse var x = a + b.

   const {get} = require("underscore.get");

   get(obj, 'a[0].b', defaultValue);

If your language requires this [1] just to be able to subscript things without going bonkers, it may be time for a new language.

[1] https://github.com/NarHakobyan/underscore.get

> Why not one package per line of code?

Exactly. If it's a difficult line of code, with edge cases, requiring unit tests, etc. then sure. Algorithms are a great example of this.

Using your own example: how many badly written copies of https://github.com/NarHakobyan/underscore.get/blob/master/un... do you want?

Look at all what django does.

It has one dependancy.

No, there are 2 reasons for this dependency creep:

- the fact JS has a so few features and such a little stdlib. So everyone has to rewrite even basic stuff.

- the community culture toward stability, maintenance and future proofing is almost inexistent in JS.

Too many JS devs have only ever coded in JS. This give them have a very twisted, unbalanced view of programming.

Reply on news.ycombinator.com