🎥 Responsive video, back again.
Scott Jehl is just out there doing that whole “let me just fix things for everyone on the internet” thing that he tends to do.
Support for using the
media attribute on the
video element, enabling responsive videos sources, was actually removed from both Chrome and Firefox long ago (no need to get into it, but safe to say it was some fall-out from the all the back and forth that occurred around the
picture element back in the day). Safari, however, continued to support it.
media attribute landing back in the spec, Scott went to work and landed a patch to re-add responsive video support to Firefox. The patch will be landing November 21st in version 120. A Chromium patch has landed, and looks like it’s set to roll out in version 120 as well.
It’s exciting to have this capability back to be with cross-browser support!
🚫 Unnecessary Polyfills
Polyfills play an important role in pushing the web forward. As standards, often slowly, role out to different browsers and platforms, they let us use new technologies responsibly, allowing for different levels of support.
But they do have a habit of sticking around long past their usefulness.
Marvin Hagemeister wrote about auditing npm packages and finding that they frequently pull in a lot of packages they don’t actually need anymore due to unnecessary polyfills.
Like, a lot. In the case of
eslint-plugin-react he brought the dependency count down from 97 to 15. For
eslint-plugin-import the count went from 87 packages to 17. Not too shabby.
In these examples, this impacts disk space, maintenance and potentially build times, but not really the user experience.
But the issue pops up for users as well. I still see sites using lazySizes and picturefill, despite the fact that we now have native support for the
picture element and
loading attribute in all major browsers, making both of these libraries anti-patterns today.
Tis a good reminder that there’s a maintenance cost associated with how we build, and we need to be careful to factor that in when we build so that we can allow for regular code health work.
🔜 perf.now() right around the corner
I’m biased, I know, but I get really excited when performance.now() rolls around each year. I have so many fond memories from the Velocity days of being surrounded by a ton of performance-focused folks for several days, and that’s what performance.now() has become as well.
It’s rare to find yourself surrounded by a ton of brilliant folks all focused on the same thing, but from so many different angles: browser engineers, people developing standards, working on performance at CDN’s, e-commerce performance, consulting on it—you name it. It’s cliche to say, I suppose, but it’s also so true—if performance.now() was nothing but hallway conversations, it would be well worth the price of admission.
Of course it’s not. The last talk seems a bit iffy, but the rest of the lineup is incredible. I’m really pumped for this one.
There are just a couple of in-person tickets left (at least, while I’m writing this), but if you miss out on those, you can also live-stream the talks remotely.
If you’re in Amsterdam, make sure to check-out the pre-event meetup as well. There are some really great talks lined up for that and somehow attendance is free.
Hope to see some of you there!