Please consider the UX of your state toggles. The red/green states will be difficult for color-blind users to discern and, color aside, it's tough to tell which is the active state.
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?
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.
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.
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?
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).
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.
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:
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?
Any time you're performing an operation on a scroll event, that is a risk. But this uses a single "scroll" event listener throttled to fire a maximum of every 100ms.
I just finished writing this little side project. It was inspired by the effect on http://oak.is. I'd love to get feedback in the form of issues & pull requests.
This is the first library I've written completely in ES6, which was a pleasure. I hope you enjoy it!
