3 ms·

> is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package NPM doe

> is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package NPM does have an extra use case: Web development. Tree shaking in JS-land is still far from perfect and people don't want to (more like, are asked to) send as little as possible over the wire. So, different use cases, different trade-offs.

zaarn 9y ago
Yes but go can do tree shaking and will not include packages in the binary that aren't used (that also means parent packages if a subpackage does not reference those). I'm mostly pointing out that despite vanilla go's complete lack of version pinning, the community has (had to necessarily) step up and solve this by engineering. Tree Shaking in JS should be trivial if the parent package implements no code and imports should be easy if they aren't of a dynamic nature (ie, "require('package/' + variable)") I'm not sure what is stopping NPM or Yarn from doing this atleast in the packaging step
- egeozcan 9y ago
  > I'm not sure what is stopping NPM or Yarn from doing this at least in the packaging step You had already answered that on your previous sentence :) > go can do tree shaking and will not include packages in the binary that aren't used Again, different languages, different trade-offs. JS isn't statically compiled. This is a much harder problem to solve for JS. I'm talking from personal experience when I say that it still isn't completely solved (requires ES2015 module syntax and has many assumptions). Even Go has hard-time optimizing-away some code because of its limited type system.
  - zaarn 9y ago
    Go isn't limited by the type system per se. IIRC from the various papers on the matter, the only real way to get Go to stop dropping unused functions is to use the runtime and reflection packages since then Go can't tell what functions might be used and fields accessed. Though also IIRC the go compiler is decent at localizing this instead of stopping all optimization. >You had already answered that on your previous sentence :) Yes but NPM/Yarn should be capable of atleast dropping packages that can be statically proven to not be imported. That means if a package imports require("xy-" + variable) then you'll have to be clever but if a package consists only of static imports then you can shake a lot.

zaarn 9y ago

Yes but go can do tree shaking and will not include packages in the binary that aren't used (that also means parent packages if a subpackage does not reference those). I'm mostly pointing out that despite vanilla go's complete lack of version pinning, the community has (had to necessarily) step up and solve this by engineering. Tree Shaking in JS should be trivial if the parent package implements no code and imports should be easy if they aren't of a dynamic nature (ie, "require('package/' + variable)") I'm not sure what is stopping NPM or Yarn from doing this atleast in the packaging step

egeozcan 9y ago
> I'm not sure what is stopping NPM or Yarn from doing this at least in the packaging step You had already answered that on your previous sentence :) > go can do tree shaking and will not include packages in the binary that aren't used Again, different languages, different trade-offs. JS isn't statically compiled. This is a much harder problem to solve for JS. I'm talking from personal experience when I say that it still isn't completely solved (requires ES2015 module syntax and has many assumptions). Even Go has hard-time optimizing-away some code because of its limited type system.
- zaarn 9y ago
  Go isn't limited by the type system per se. IIRC from the various papers on the matter, the only real way to get Go to stop dropping unused functions is to use the runtime and reflection packages since then Go can't tell what functions might be used and fields accessed. Though also IIRC the go compiler is decent at localizing this instead of stopping all optimization. >You had already answered that on your previous sentence :) Yes but NPM/Yarn should be capable of atleast dropping packages that can be statically proven to not be imported. That means if a package imports require("xy-" + variable) then you'll have to be clever but if a package consists only of static imports then you can shake a lot.