41–50 of 69 posts
Earlier quoted context omitted.
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?
Just use https://www.npmjs.com/package/lodash.throttle
More than three years ago I created in-viewport and have perfected it since. https://github.com/vvo/in-viewport it's used on fortune 500 websites along with my lazyloader (https://github.com/vvo/lazyload).
There is an emerging standard called Intersection Observer that addresses the same use case: https://github.com/WICG/IntersectionObserver/blob/gh-pages/e... This is a really useful problem to solve. But, I would personally prefer to solve it with a polyfill for a standardized approach that will eventually receive native implementation.
I hear you. But, isn't this just an editor's draft spec? Only Chrome and Android have done any implementation at all. So, as far as I can tell, there's a chance this will never be fully implemented? And, because it's a draft, the spec could change significantly. Is that right?
Intersection Observer has been implemented in Chrome since 51, and Opera since 38. It's currently being implemented in Firefox ( https://bugzilla.mozilla.org/show_bug.cgi?id=1243846 ), and is "likely" from Edge (https://developer.microsoft.com/en-us/microsoft-edge/platfor... ).
in-view.js's API is certainly less likely to be the cross-platform API than Intersection Observer. Also, plenty of APIs are implemented by browsers at the editor's draft stage.
There is an emerging standard called Intersection Observer that addresses the same use case: https://github.com/WICG/IntersectionObserver/blob/gh-pages/e... This is a really useful problem to solve. But, I would personally prefer to solve it with a polyfill for a standardized approach that will eventually receive native implementation.
The repository you linked to, actually contains the official polyfill: https://github.com/WICG/IntersectionObserver/tree/gh-pages/p... (it should be about 6 KB minzipped)
Only yesterday I implemented this in an application, although a bit simpler (is the user < n pixels from the bottom of the document? then render more heavy stuff) so yeah, that's a pretty recurrent use case for a library like that.
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 that take more than a few ms to complete, thus reducing the frame rate of the page.
It seems like this library is throttling the evaluation of the event handler but you still need to be careful as to not solve one performance problem and create another. I know I personally hate slow scrolling web pages.
This seems like something that should be implemented in some as yet unreleased CSS selector. But that still won't stop people from abusing it.
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…
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).
I've found rollup, https://rollupjs.org/ , to be really useful for this.
Earlier quoted context omitted.
I've found rollup, https://rollupjs.org/ , to be really useful for this.
This looks nice. Is it as battle-tested as browserify?
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.