21–30 of 69 posts
Earlier quoted context omitted.
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).
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.
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).
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?
Earlier quoted context omitted.
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).
Not necessarily. Google just announced that, in the name of accessibility, they will start penalizing sites that use them. https://webmasters.googleblog.com/2016/08/helping-users-easi...
"To improve the mobile search experience, after January 10, 2017, pages where content is not easily accessible to a user on the transition from the mobile search results may not rank as highly."
They define what is acceptable and not right after. I like the move though !
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).
Even if I was the odd one and nobody else would mind those pop-ups: In the context of multiple experiments showing that a few hundred milliseconds additional page load time have a very real impact on engagement rates it stands to reason that interrupting the user experience with unrelated email sign ups should have a similar effect.
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).
Most of the code here is actually from lodash due to the use of `throttle`, not either of the projects you mentioned.
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.