Using the Platform

The other day I was listening to the latest Shop Talk Show podcast while out for my morning run. They had Jen Simmons on the show, talking about (among other things) the standards process. It’s a great conversation, as you would expect—Jen’s super smart and has been doing great, meaningful work for a long time.

Among the things that she discussed is the care that has to go into new browser features because once shipped, it’s there for good. Most of us don’t have to worry about things to that same level because:

…you can always delete all your code later. You can always say, ‘Oh, this thing I shipped quickly for my project, that was a bad idea. Let’s obliterate it and re-do it better later.’ But with the web, there’s two things. One, we don’t get to change it and ship it again later, almost ever. If we hurry up and we ship subgrid, and subgrid is crappy, there’s no, like, fixing it. We’re stuck with it.

This permanence to the web has always been one of the web’s characteristics that astounds me the most. It’s why you can load up sites today on a Newton, and they’ll just work. That’s in such sharp contrast to, well, everything I can think of. Devices aren’t built like that. Products in general, digital or otherwise, are rarely built like that. Native platforms aren’t built like that. That commitment to not breaking what has been created is simply incredible.

Jen’s other point, too, is an important one to remember:

…And the other thing is that we’re not solving for one website. We’re not solving for facebook.com, or youtube.com, or codepen.io or for…whatever. We’re solving for the entire web and every use case ever all at the same time.

She gives an example, later on, discussing how even something seemingly simple, underlines, becomes so much more intense when you need to solve for everyone:

Well, what about these languages that are typeset vertically? What is the typography in Japan? What’s needed for this kind of script that is completely different than the Latin alphabet? And there’s a long conversation about that and then, ‘Wow, we’re shipping something that actually works for all the languages and all the scripts around the world.’ Or it almost does and there’s a few pieces missing but we’re dedicated to going ahead and finishing those pieces as soon as we can.

There’s a lot of thought and consideration that goes into deciding what makes its way into this incredible platform and what doesn’t.

Another person I have a ton of respect for and who has been doing incredibly important work for a long time is Alex Russell. In particular, he’s put an absurd amount of time and energy into advocating for being careful about the overreliance on JavaScript that is leading to much of the web’s current performance issues.

I thought about Jen’s comments when I saw one person stating that Alex was trying to “sell you on fairy tales of Use the Platform”.

I don’t want to single that person out because I’m not here to encourage a pile-on, but also because they’re hardly the first person to express that general sentiment. But, that statement about the “fairy tale of Use the Platform” has really stuck with me, because it feels…wrong.

So much care and planning has gone into creating the web platform, to ensure that even as new features are added, they’re added in a way that doesn’t break the web for anyone using an older device or browser. Can you say the same for any framework out there? I don’t mean that to be perceived as throwing shade (as the kids say). Building the actual web platform requires a deeper level of commitment to these sorts of things out of necessity.

And as some frameworks are, just now, considering how they scale and grow to different geographies with different constraints and languages, the web platform has been building with that in mind for years. The standards process feels so difficult to many of us because of the incredible amount of minutiae that becomes critical. That security issue that might maybe be a problem? Maybe you feel comfortable taking that risk but when you’re creating something that everyone, everywhere is going to use, it becomes a valid reason for not shipping.

People talk a lot about the web being accessible or performant by default, and while it’s not perfect, it’s also not that far from being true. Creating the platform means you have to prioritize these things.

If you care at all about reaching people outside of the little bubbles we all live in, using the platform can’t be a fairy tale: it has to be the foundation for everything that we build.

That doesn’t mean that foundation is enough, or always right.

Are there limitations? Absolutely! There’s a reason why we still have a standards body, 26 years or so after HTML was first specified: because the work isn’t done and never (knock on wood) will be. (It’s also why I find it very encouraging that folks like Nicole Sullivan are hard at work to identifying some of the things we need frameworks for that should probably be in the browser instead.)

The web thrives on a healthy tension between stability and the chaos of experimentation. It’s perfectly fine, and necessary at times, to use tools to augment issues and limitations we may have on the web. I have no problem with that at all.

But it’s important that we do so very carefully because there are definite trade-offs.

To create the standards that make it into the platform, careful care is given to each and every feature to minimize the security risks. Every new feature has to be carefully considered from an accessibility perspective to make sure that not only does it not cause harm, but that assistive technology has all the information it needs to be able to provide people with a usable experience. Performance has to be top of mind for each new standard, to ensure that shipping it won’t cause undue bloat or other performance issues.

And each of these things must not be considered simply in one single context, but for all sites and across geographies, languages, devices, and browsing clients.

Can you say, with confidence, that the same level of care is given in the tools and frameworks we use or build?

Use the platform until you can’t, then augment what’s missing. And when you augment, do so with care because the responsibility of ensuring the security, accessibility, and performance that the platform tries to give you by default now falls entirely on you.