
Oct 9, 2026 · 1 hr 5 min · 11 segments
Share Episode We welcome David Burns, Head of Open Source at BrowserStack and previously Mozilla, this week…
David BurnsGuestWarrenHostWe are in this space where the things that we're building are being utilized in browsers as a primary mechanism for interaction.
And yet, I always have found in my two decades of software engineering experience actually validating what shows up there is always the most difficult part.
Like I write a unit test on some backend code and it's a joke.
But as soon as it comes to, is the CSS working? Is the components actually showing at the right time? Is there gestures for mobile stuff actually working correctly? I mean, good luck.

Having worked on browsers for a decade, even browser engineers have that problem.

Browsers nowadays, or at least for the last decade, have effectively been operating systems in their complexity, right? And you can look at Firefox OS, Chrome OS, even WebOS before that, right? And it was amazing what you could do from rendering to interactions.

And then you have all of this on multiple operating systems to do things slightly differently where Again, browsers try and do a bit of massaging to it.
frameworks, right? Because it creates this abstraction layer that potentially you could use to get reliable results everywhere.
But the whole world of how like CSS implementations are just fundamentally different between the different frameworks that power each of the browsers and the classes that are built in or the flags or whatever that you're utilizing.
It still doesn't work out of the box for everything.

So there's a lot of problems that I think when we're developing software that we really struggle with.

CSS is a fantastic example, right? Like Peter Griffin trying to open the blind and you've seen how that goes wrong.

from the years and then standards got in the way and they started cleaning it all up.
We are in this space where the things that we're building are being utilized in browsers as a primary mechanism for interaction.
And yet, I always have found in my two decades of software engineering experience actually validating what shows up there is always the most difficult part.
Like I write a unit test on some backend code and it's a joke.
But as soon as it comes to, is the CSS working? Is the components actually showing at the right time? Is there gestures for mobile stuff actually working correctly? I mean, good luck.

Having worked on browsers for a decade, even browser engineers have that problem.

Browsers nowadays, or at least for the last decade, have effectively been operating systems in their complexity, right? And you can look at Firefox OS, Chrome OS, even WebOS before that, right? And it was amazing what you could do from rendering to interactions.

And then you have all of this on multiple operating systems to do things slightly differently where Again, browsers try and do a bit of massaging to it.
frameworks, right? Because it creates this abstraction layer that potentially you could use to get reliable results everywhere.
But the whole world of how like CSS implementations are just fundamentally different between the different frameworks that power each of the browsers and the classes that are built in or the flags or whatever that you're utilizing.
It still doesn't work out of the box for everything.

So there's a lot of problems that I think when we're developing software that we really struggle with.

CSS is a fantastic example, right? Like Peter Griffin trying to open the blind and you've seen how that goes wrong.

from the years and then standards got in the way and they started cleaning it all up.
The rest of this transcript — segmented and speaker-labeled, so you land on the exact moment something was said
Search every transcript — by keyword, by phrase, or by meaning, across every show Radar indexes
Trends — what is surging across podcasts, measured against its own baseline
Alerts — when a name you follow appears in a newly indexed episode
No account is needed to search Radar.