GitHub: How we think about browsers

GitHub is currently shipping ES2019-compatible code, and will soon ship ES2020 code.

GitHub will soon be serving JavaScript using syntax features found in the ECMAScript 2020 standard, which includes the optional chaining and nullish coalescing operators. This change will lead to a 10kb reduction in JavaScript across the site.

Wow, won’t that exclude a whole bunch of browsers? No. Looking at the data, the majority of their visitors use the latest version of a browser, or the version before that (wow!).

This shows us that the promise of evergreen browsers is here today. The days of targeting one specific version of one browser are long gone. […] With that said, we still need to ensure some compatibility for user agents, which do not fall into the neat box of evergreen browsers. Universal access is important, and 1% of 73 million users is still 730,000 users.

To cater for older browsers they include some polyfills to plug the holes, but that’s not really needed:/p>

With JavaScript disabled, you’re still able to log in, comment on issues and pull requests, browse source code, search for repositories, and even star, watch, or fork them. Popover menus even work.

Yes, a thousand times YES!

GitHub: How we think about browsers →

What’s New in React Native 0.69

Photo by Lautaro Andreani on Unsplash

It’s been a while since I’ve done some React Native work, but the 0.69 release seems like a very welcome one: React 18, bundled Hermes, Fabric, TurboModules, and the JSI.

React Native 0.69 brings a ton of important improvements & updates to the table, with performance & memory usage being a major theme. Because some of the changes are opt-in, you’ll need to decide yourself which to enable and in what order. No matter which upgrade path or strategy you take, though, these changes bring exciting improvements to the React Native platform. It’s a great time to be a React Native developer!

What’s New in React Native 0.69 — How to Upgrade and Why it Matters →

 m-cli – Swiss Army Knife for macOS

m-cli is a macOS command line tool that lets you interact with utilities and applications entirely in Terminal.

Gives you a bunch of shorthand CLI commands that you can use, such as m finder showdesktop YES, m battery status, m dns flush, etc. These replace a bunch of custom aliases you might have set up in your dotfiles

 m-cli – Swiss Army Knife for macOS →

A Previous Sibling Selector

Jim Nielsen set out to style a bunch of links that appeared before hr elements. As the element tree – generated from a Markdown file – was entirely flat, there are no enclosing section elements to hook onto in order to select those links (using something like section p:last-child a:only-child).

The solution? The :has() selector:

p:has(+ hr) a:only-child {
}

This, again, proves that the :has() selector is way more than just a parent selector.

A Previous Sibling Selector →

Fun CSS-only scrolling effects for Matterday

In this post, Lynn Fisher walks us through the parallax scrolling CSS effects featured on the Matterday project. Does not use Scroll-Linked Animations (which is undergoing a spec rewrite) but transform hacks that rely on translateZ() to create a stack and scale() to correct the size again.

Fun CSS-only scrolling effects for Matterday →

The CSS Cascade: A Deep Dive (2022.06.09 @ CSS Day)

Me, speaking at CSS Day

On June 9 & 10, I was in Amsterdam for CSS Day – a conference I’ve been attending since it’s very first edition in 2013. This time – after a two year hiatus due to youknowwhat – I was very glad to be back! This time not as an attendee though, but as a speaker. In my talk I covered the details of the CSS Cascade, with a huge focus on CSS Cascade Layers.

CSS is short for Cascading Style Sheets. But what exactly is this Cascade, and how does it work? What are Origins? How do you calculate Specificity? And where do those new Cascade Layers you might have heard of fit in? And oh, what exactly happens when you use an !important somewhere?

In this insightful talk, we’ll take a look under the hood of browsers, and detail how they determine which CSS declarations to apply and which not.

The slides are up on slidr.io, and also embedded below:

The talk was recorded and will premiere on the CSS Day YouTube Channel on July 7 at 13:55. This recording might be of more help, as the slides themselves lack some explanation and supporting animations to tell the whole story.

☝️ If you’re looking a full content-recap of CSS Day, I would recommend the recaps by Grrr:

~

Elad, Amit, Adam, Hui Jing, and me
Elad, Amit, Adam, Hui Jing, and me

It felt great to be back on stage speaking to a real crowd again. There’s a great vibe going on during the conference, speaker dinner, and hallway track that simply cannot be matched by any virtual event. Meeting some CSS friends who I only know through Twitter in real life for the very first time, as well as meeting new people, and hanging out with some of my Google colleagues (who I, as a remote worker, normally only get to see through a screen), is an enriching experience.

~

Me, speaking at CSS Day

I would like to thank organizers Krijn and PPK for having me. Having organised events for almost a decade now, they know how to do it – even a totally new venue was no hurdle to them.

A big thanks to the other speakers as well for giving their talks – the quality, as per usual, was very high level. I’m honored to have been part of this stellar line-up, and hope I was able to meet the same level of quality.

I hope you all had fun attending my talk — I know I had making it (and whilst bringing it forward) — and perhaps you even learned something from it along the way 🙂

~

💁‍♂️ If you are a conference or meetup organiser, don't hesitate to contact me to come speak at your event.

Re-evaluating technology

Jeremy underlines importance of revisiting past decisions:

In recent years in particular it feels like the web has come on in leaps and bounds: service workers, native JavaScript APIs, and an astonishing boost in what you can do with CSS. Most important of all, the interoperability between browsers is getting better and better. Universal support for new web standards arrives at a faster rate than ever before.

But developers remain suspicious, still prefering to trust third-party libraries over native browser features. They made a decision about those libraries in the past. They evaluated the state of browser support in the past. I wish they would re-evaluate those decisions.

I’ve said it before: The web catches up.

Re-evaluating technology →