inconsistencies between WebKit and Blink. I think the Chrome way is the correct way, at least I heard Chrome DevRel people say that at conferences, that microtasks run directly behind regular tasks, and eventually you have the animation frame right before the paint. In WebKit I think there was some inconsistency around microtasks, I think there are no microtasks? I don't know exactly. And requestAnimationFrame actually triggers right on the other side, so after the paint has happened. Well that's not good. It's not that bad, I think in most places it works fine, but if you want to optimize your code and really have it be performant, I think sometimes timing problems around when that triggers and you want to really have predictable [timing].
How do you deal with missing JS features?
In most projects I have a fairly common stack of Babel and Webpack, and also Babel polyfills. Babel became very popular for all the syntax stuff in the last couple of years, and I kind of see it as a given now, even though I also think that now, a couple years after it really became adopted, maybe starting from 2020 it actually should be an option to think about, if you actually need Babel in your build stack, because a lot of it is supported now and is not as relevant anymore. But because I come from the mindset that I need to support all the way down to at least IE11, maybe even IE9, naturally if you want to support IE9 you're going to have Babel. Different combinations of core-js polyfills, either manually or through Babel polyfill. I tried out different solutions. There's a project from the New York Times, polyfill.io, that does testing for browser features and lazy loads the polyfills. I always thought that was interesting to consider but haven't worked with it yet because I feel like it's probably going to have network latency problems on really slow devices, so for now my approach is to keep the amount of polyfills we load in not too big, just see it as a necessary evil of probably 30% overhead of the bundle is just damned polyfills you don't need in modern browsers, but at least modern browsers are faster anyway and then you can allow the network overhead, but I also haven't done any numbers on that. It was easier on our build stack to do it like that.
Viewport issues
Made with FlippingBook - professional solution for displaying marketing and sales documents online