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).
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.
Whenever you attach an event handler on scroll, it can impact page performance because the javascript needs to be evaluated before the scroll event can continue AFAIK...going from some old Paul Irish talk on performance. The #1 killer he found responsible for "jankiness" (that horrible scroll feeling where the page scroll is unresponsive and not 60 fps smooth) is by people attaching event handlers on the scroll event…
Whenever I rely on scroll information, I store the event info I need on the scroll event in some variable, and the logic that would normally be placed in the callback goes in a separate requestAnimationFrame loop. This way, even if it takes a few ms, it doesn't impact the scroll speed of the page. I wish more developers did this.
I would love if you are able to expand on this or give an example.
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?
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…
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.
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'?
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:
Depends on how you use it and on how much elements. I am not sure if this is even worth to be a library. Sometimes I am wondering why people want to use a lib for everything.
If it's not my own code, it's worth being a library.
And I don't want to spend my time learning to write it correctly to handle all case and be performant.
Whenever you attach an event handler on scroll, it can impact page performance because the javascript needs to be evaluated before the scroll event can continue AFAIK...going from some old Paul Irish talk on performance. The #1 killer he found responsible for "jankiness" (that horrible scroll feeling where the page scroll is unresponsive and not 60 fps smooth) is by people attaching event handlers on the scroll event…
"Whenever you attach an event handler on scroll, it can impact page performance because the javascript needs to be evaluated before the scroll event can continue AFAIK...going from some old Paul Irish talk on performance." This isn't true no. Scrolling is an asynchronous event, in this case meaning it will happen regardless (without waiting on any JS event handlers), the JS event triggers after its happened. This is…
It's not true in some cases, sometimes. It's still quite easy to cause performance problems listening to scroll events, because even if scroll is partially asynchronous, the webpage itself is not - the browser will wait to render new content if the page is blocked.
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…
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.
I hope this gets used for good, not evil. Lots of sites (you know, those sites, they crop on on HN from time to time) flash up "give me your email address so I can send you spam" boxes before I can read the blog post. Or when it thinks I've gone somewhere else when in fact I just opened it in a new tab. Or if a momentarily switched away. I mostly close blogs that aggressively try to sell me things, but sometimes I wa…
It's unfortunate. However, it's been shown over and over to have the best conversion rate for getting people's emails, so it's a trend that's only going to become more popular from here (until the next high conversion pattern is developed).
Whenever you attach an event handler on scroll, it can impact page performance because the javascript needs to be evaluated before the scroll event can continue AFAIK...going from some old Paul Irish talk on performance. The #1 killer he found responsible for "jankiness" (that horrible scroll feeling where the page scroll is unresponsive and not 60 fps smooth) is by people attaching event handlers on the scroll event…
Whenever I rely on scroll information, I store the event info I need on the scroll event in some variable, and the logic that would normally be placed in the callback goes in a separate requestAnimationFrame loop. This way, even if it takes a few ms, it doesn't impact the scroll speed of the page. I wish more developers did this.