Hacker News Reader

Comment by onion2k | Hacker News Reader

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.

View on HN

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.

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?

Reply on news.ycombinator.com