I think the article misdiagnoses why folks don’t use the platform.
For Nolan’s <dialog> example, it’s a rare thing to be the first person on your team authoring a dialog. Someone’s already built it, battle tested it, and extended it with design requests over years. It doesn’t matter if it’s standard, more accessible, and simpler. You’re still duplicating a core component.
Spend social capital. Get time to migrate the core dialog component. After a brief fight translating entrance animations, it’s a clean port. Merge! … Hyrum’s Law deals a critical hit. Dropdowns and tooltips break across the app because tethered windows fall behind the dialog layer. Another part of the app is crashing from a listener binding to a now-missing click backdrop someone used to hijack an exit flow. Part of the app you didn’t even know about is borked because 3 years ago that team’s designer pushed a new dialog theme, powered by hubris and selector soup of overrides that no longer match.
None of this is hard, but it’s tedious and socially expensive. You just lost days to a change nobody* will notice.
*except your boss
I’ll assume Nolan’s intended audience is solo devs, design system maintainers, and folks working in greenfield projects. In that case <dialog> is perfect. There’s no baggage to fix. Yeet it.
But <dialog> is a strawman. It’s one of the easiest components these days! (Infinite thanks to browser people for making that sentence possible.) Try it with tooltips or dropdowns. Even assuming your targets support Anchor Positioning, Popover API, and Interest Invokers, you’ll lose days studying the APIs and all the nuance of how tooltips are meant to behave. And like the royal order of adjectives, there’s a lot of nuance completely invisible until it’s missing or written wrong.
If you power through, it still needs to be abstracted away from the platform. You don’t want teammates using @position-try to override flip conditions. At best, coworker Bob adds a prop out of frustration for having learned an obscure CSS paradigm just for your custom tooltip (grumble). At worst, they’ll actually use it and freeze you to that specific implementation.
Assuming the tooltip works, now it’s time for the long tail of evolving scope and edge cases. The design team wants arrows on the tooltip. Users can’t select tooltip text because it disappears when their mouse leaves the trigger. There’s a bug where italicized text inherits into the tooltip…
It wasn’t a waste; you get a prize at the end: whatever’s in your head and the undocumented equivalent of an abandoned npm package.
I’ve done this before. I love the platform. But in a work context, the only pragmatic answer is to install a package and move on with OKRs.
I think the article misdiagnoses why folks don’t use the platform.
For Nolan’s
<dialog>example, it’s a rare thing to be the first person on your team authoring a dialog. Someone’s already built it, battle tested it, and extended it with design requests over years. It doesn’t matter if it’s standard, more accessible, and simpler. You’re still duplicating a core component.Spend social capital. Get time to migrate the core dialog component. After a brief fight translating entrance animations, it’s a clean port. Merge! … Hyrum’s Law deals a critical hit. Dropdowns and tooltips break across the app because tethered windows fall behind the dialog layer. Another part of the app is crashing from a listener binding to a now-missing click backdrop someone used to hijack an exit flow. Part of the app you didn’t even know about is borked because 3 years ago that team’s designer pushed a new dialog theme, powered by hubris and selector soup of overrides that no longer match.
None of this is hard, but it’s tedious and socially expensive. You just lost days to a change nobody* will notice.
*except your boss
I’ll assume Nolan’s intended audience is solo devs, design system maintainers, and folks working in greenfield projects. In that case
<dialog>is perfect. There’s no baggage to fix. Yeet it.But
<dialog>is a strawman. It’s one of the easiest components these days! (Infinite thanks to browser people for making that sentence possible.) Try it with tooltips or dropdowns. Even assuming your targets support Anchor Positioning, Popover API, and Interest Invokers, you’ll lose days studying the APIs and all the nuance of how tooltips are meant to behave. And like the royal order of adjectives, there’s a lot of nuance completely invisible until it’s missing or written wrong.If you power through, it still needs to be abstracted away from the platform. You don’t want teammates using
@position-tryto override flip conditions. At best, coworker Bob adds a prop out of frustration for having learned an obscure CSS paradigm just for your custom tooltip (grumble). At worst, they’ll actually use it and freeze you to that specific implementation.Assuming the tooltip works, now it’s time for the long tail of evolving scope and edge cases. The design team wants arrows on the tooltip. Users can’t select tooltip text because it disappears when their mouse leaves the trigger. There’s a bug where italicized text inherits into the tooltip…
It wasn’t a waste; you get a prize at the end: whatever’s in your head and the undocumented equivalent of an abandoned npm package.
I’ve done this before. I love the platform. But in a work context, the only pragmatic answer is to install a package and move on with OKRs.
score 1 · canonical