Hacker News Reader

Comment by dmbass | Hacker News Reader

Babel and webpack are megaoverkill for this and account for a good chunk of the 2k gzipped size. The actual library code is barely 140SLOC. There's a lot of room for improvement if this is intended to be a real standalone library (vs. a webpack/babel test).

View on HN

I've found rollup, https://rollupjs.org/, to be really useful for this.

This looks nice. Is it as battle-tested as browserify?

It's fairly new but The Guardian uses it for all their JavaScript (the creator works there).

tl;dr—don't use rollup with large untested dependencies

I've had projects that got really strange error messages when using rollup that completely went away when I switched back to Babel.

One "issue" with rollup is that it is not 100% semantically correct. Neither is Babel in all cases, but the creator argues that if you're not following exact semantics now, you're relying on your tests to ensure proper behavior, so use something that is at least more minimal and keeps your bundle size down.

So when you're writing code and bundling with rollup, you can pretty much ensure everything works fine, but as soon as you pull in an extensive third-party library you have no assurances that it has been tested with rollup and will work correctly in all cases. In the worst case, it will seem to work fine but in weird situations will actually error out. This was my experience with rollup.

I should clarify on my above comment, in rollup the semantics don't matter as much but if you're using Bublé instead of Babel, the semantics may very well come into play. In either case, I didn't have luck on a project until I moved fully to webpack+Babel.

Webpack's runtime overhead is tiny, babel's varies based on what polyfills you need but very little is included here.

Most of the code here is actually from lodash due to the use of `throttle`, not either of the projects you mentioned.

I believe Waypoints also does this same thing, it's a fairly mature lib. https://github.com/imakewebthings/waypoints

kudos for in-view's demo page though

Why is Babel overkill? It lets you write your code in ES6, which is a huge benefit for many reasons.

The fact that it's delivering 140 lines in 5.5kb. That's a lot of bloat! There are ways to write code in ES6 without that (see sibling responses).

Hey, author here. I'm very open to ideas to reduce bloat. It's 140 SLOC and ~1.1kb gzipped without lodash/throttle. I considered writing my own throttle, but wanted something more battle-tested.

Does Rollup produce a more efficient bundle in your experience?

rollup can only load the functions of lodash you actually use into your bundle

So can lodash. That's what the author is doing here by using

  import throttle from 'lodash/throttle';

rather than

  import { throttle } from 'lodash';

Just use https://www.npmjs.com/package/lodash.throttle

Can you point me to an explanation of the differences between the 'lodash.throttle' module and importing 'lodash/throttle'?

You should get about the same results using a bundler. Perhaps the lodash.throttle package is for reducing `npm install` time or reducing bloat if you check in your node modules?

lodash.throttle is a standalone zero-dependency package of just the throttle module. The `lodash` package is a collection of modules one of which is `lodash/throttle`.

You can generally get smaller bundles using `lodash/xyz` modules over the `lodash.xyz` packages because of plugins like:

https://github.com/lodash/babel-plugin-lodash

https://github.com/lodash/lodash-webpack-plugin

Though in the future lodash-webpack-plugin may support `lodash.xyz` packages too.

OP is using that already.

Not sure why I was downvoted, I think it's a valid point. To prove it, here's the functionality of your library in ES5 with a naive throttle function: https://gist.github.com/nathancahill/f7ea239306737f2075a94de...

Minified (1.49kb) and gzipped (677b).

Whether lodash functions should be used instead of naive functions is up for debate. My opinion is if the lodash functions are 5x the size of the entire library, it's probably best to not include it, or to include it as a build option (if the user's project already includes lodash for example).

No worries, lodash/debounce can be reduced further with babel+webpack plugins.

Assuming the current setup of babel+webpack the difference between your naive version is just ~0.5 kB.

Which still doubles the size of the library: ~0.6kb to ~1.1kb. So while it's just half a kilobyte, do that over and over, with nested dependencies and it really adds up.

But if your entire project uses Babel, those 140 lines will already be in your code and thus won't be added.

The only sibling response is rollupjs, which replaces webpack with ES6 import syntax. You still need bablel for the rest of the ES6 syntax.

> You still need bablel for the rest of the ES6 syntax.

Or Bublé[1] ;) which i've found to be much faster than Babel, even for relatively small codebases (~ a couple thousand LoC).

[1]: https://gitlab.com/Rich-Harris/buble

Reply on news.ycombinator.com