[rShergold]

It seems to be really common to sling mud at the JavaScript/NPM ecosystem from developers who work in other domains.

One of the big constraints we have in front end development is that every added feature adds to the bundle size of code we have to send down the wire to the end user.

When I worked in mobile app development third party libraries tended to be very large with many many features. Only a tiny fraction of that library ends up matching your use case. However when you build you end up bundling up the whole thing into your app.

JavaScript has more of a culture of many many small hyper focused packages. The logical conclusion being single function packages like left pad.

This has two benefits. One - you have less dead code in your final build. Two - if one of your dependencies is already using leftpad you essentially get to use it "for free".

If everyone did what you are suggesting you would find multiple instances of leftpad. One version you wrote. One version your dependency wrote. One version your dependency's dependency wrote etc.

[ginko]

>When I worked in mobile app development third party libraries tended to be very large with many many features. Only a tiny fraction of that library ends up matching your use case. However when you build you end up bundling up the whole thing into your app.

Surely there have to be tools to process dependency libraries to strip out any unused code.

[rShergold]

yeah it's called Tree Shaking. It's been a massive area of improvement over the last few years. However JavaScript being dynamic can be very difficult to effectively statically analyse.

A good example: There is a library called Moment for handling dates. Due to the way the interface was built it basically can't be tree shaken. It's an excellent library but it's on the heavy side. For a while now people have been moving to libraries like Date-Fns which are collections of individual functions. This library can be tree shaken as it's obvious which functions you are using and which you are not

[sime2009]

> JavaScript has more of a culture of many many small hyper focused packages.

> This has two benefits. One - you have less dead code in your final build. Two - if one of your dependencies is already using leftpad you essentially get to use it "for free".

This culture has really backfired in practice.

What we now have is a proliferation of packages which do the same thing. The problem is that it is less likely that your dependencies are going to be using the packages, even though desired functionality is the same. For example, if you have two dependencies which need to do HTML encoding, chances are that they choose different packages for that job. So now as an app developer you have to pay for both.

This combined with a culture which loves Semver but doesn't mind breaking backwards compatibility ("just update the major version!") gives a huge mix of packages which can't be fixed by tree shaking.

[austincheney]

As a front end developer with nearly 20 years of experience I can objectively call bullshit.

The problem is Invented Here syndrome and coddling. https://en.m.wikipedia.org/wiki/Invented_here

The reason this exists is due to a lack of leadership in the front end space. More specifically, a need to hire untrained entry level developers and deliberately not train them whether due to insecurity elsewhere and a complete inability to write documentation.

> If everyone did what you are suggesting you would find multiple instances of leftpad.

It was about 8 lines of code a child could write that you probably don’t need in the first place.

[rShergold]

I agree with a lot of what you're saying.

However if the threshold for not including a package is that it's 8 lines of code that would rule out using most of the functions in Lodash and Underscore.

If the threshold is not importing code a child could write that would rule out using Babel which was in fact literally written by a child.

[dimitar]

Dead code elimination can be done by a compiler like Google's Closure