Live data from Hacker News

Show HN: In-view.js – Get notified when DOM elements enter or exit the viewport

github.com

31–40 of 69 posts

Re: Show HN: In-view.js – Get notified when DOM elements enter or exit the viewport

#31
post #20

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?

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';

Re: Show HN: In-view.js – Get notified when DOM elements enter or exit the viewport

#32
post #29
post #16

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?

All the more reason to experiment with the proposed standard API and contribute feedback.

The advantages of standardization and eventual native implementation outweigh the immediacy of a JS-based API designed in relative isolation. Why should I invest time learning this micro-library, when the API is certain to be different from the native implementation? The documentation doesn't seem to even acknowledge the existance of the standard (did the author do any research before implementing a one-off library? I have no way of knowing.), much less explain why it differs from the proposed standard.

Re: Show HN: In-view.js – Get notified when DOM elements enter or exit the viewport

#33
I made something similar for use with Knockout.js. Love your clear code and efficient implementation! I will probably swap out my core logic for yours.

Some here have mentioned the webpack overhead, and suggested rollup.js. I've had great results with rollup for these teeny-tiny browser-focused projects.

Re: Show HN: In-view.js – Get notified when DOM elements enter or exit the viewport

#34
post #20

Earlier quoted context omitted.

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?

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

Re: Show HN: In-view.js – Get notified when DOM elements enter or exit the viewport

#35

Interesting project. I wonder if you might be willing to outline a few use cases?

One of the best use cases is lazy loading expensive data until the div is visible. Image loading, or even fetching a resource. You essentially get this for free in native apps (iOS/Android with recycled views) but there hasn't been a great way to accomplish this on the web. Note: this is definitely not the same as a recycled view. But can help accomplish one aspect

Yes, lazy loading is a good use case.

Echo.js (https://github.com/toddmotto/echo) is another small no-dependency library (1.89 KB minified), which detects elements appearing on screen, and goes a step further to swap the "src" attribute with a placeholder for lazy loading and unloading.

Disclosure: I've submitted a pull request to it.

Re: Show HN: In-view.js – Get notified when DOM elements enter or exit the viewport

#36
post #16

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)

Re: Show HN: In-view.js – Get notified when DOM elements enter or exit the viewport

#37
post #24

Earlier quoted context omitted.

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).

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

Re: Show HN: In-view.js – Get notified when DOM elements enter or exit the viewport

#38
post #20

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

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

Re: Show HN: In-view.js – Get notified when DOM elements enter or exit the viewport

#39
post #20

Earlier quoted context omitted.

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?

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).

Post reply on HN