You's the Platform!

Hi, my name is John. I work at Netflix, and today I'm going to talk about the web platform. So, a common refrain we hear as web developers is that we should use the platform. But what is the platform? Who decides what's going to go into it? How do browser implementers decide what they're going to do and what they're not going to do? Can we, as UI developers, have a say in what that looks like? And the answer is yes. You is the platform. This is something that's actually open to all. And we're going to walk through an experience I had to show you how easy it is to get involved.

So, if we think about code, code lives on a spectrum, right? We've got our applications, we're writing on the far left, we've got things we use, like React, kind of in the middle. And then we've got the web platform, the DOM, HTML, those kinds of things. I don't know about you, but they feel to me like something that's just kind of there, right? It's good stuff for the most part. Occasionally you got to work around something weird. But it's just the world we live in. And so, if we wanted to change something, we might view it as sort of a graph like this. It can be very intimidating to think about changing things on the upper right side. A lot of expertise needed, a lot of process. Whereas things on the left side, that's easy, that's comfortable. We do that every day. And then open source libraries, frameworks, that's kind of in the middle somewhere. But this experience I had over the last year has totally changed this perception for me.

So, about a year ago I was at a remix meet-up. So, remix, if you're not familiar, it's a full stack framework for React that lets you build just really great web applications that perform really well. I was doing some work in Netflix to support this internally. So, at the meet-up I was demoing some apps I built around this. So, I've got a little to-do app I wrote. The app isn't very impressive, but it showcases some remix features like progressive enhancement and optimistic UIs, and it's using Netflix component libraries and running on Netflix infrastructure. And as I was demoing it, embarrassingly, the app was broken. And the app had worked before. So, this is something new, something had changed. And what had happened was it actually upgraded to the latest version of Remix about a week prior. So, before I get into the bug, I want to talk about how Remix deals with mutations.

So, typically, mutations are always modeled with forms. So, this row, for example, is a form that lets you complete or update or delete one of your to-do items. And so, there's a couple little widgets here for kind of toggling completion or deleting things. And when I demoed the app, those two widgets were broken.

What's interesting is because of progressive enhancement, you can turn off JavaScript and it actually still worked correctly. So, it was only broken when JavaScript turned on. And the reason why is the Remix team had fixed the bug, but in the process kind of introduced a slightly different bug. So, the form data submission process they had prior to this, it would clobber potentially other inputs, right? So, if you had a submit button with a name, if you had another input of the same name, the submit button would just override what you had. And so, they fixed that to say, no, we're going to append whatever the submit button has at the very end of the form. Now, for most forms, this would never matter. For my form, it actually did. Because I was relying on the order that things were serialized based on their order in the DOM. So, I had a default submit button when you hit enter, the completion icon was actually a submit button. So, you notice it has a name, it has a value, and that'll set the right name and value for completion. And the delete button was also a submit button with a name and a value. And those would actually override other values I had later in the form. And so, because now they were serialized in a different order, on the server side, it was being handled incorrectly.

Now, you know, most people would say, okay, whatever, I'll just tweak my form, that's that, and move on. But I'm not normal, right? And that's why I'm giving this talk today. But, you know, I was looking at this, and I'm thinking, you know, this regression will not stand. You know, this regression will not stand, man. I did not want to change my form. I didn't want to have to do something just because, you know, they were wrong, right? And so instead I went and wrote a big, ugly component so that I didn't have to. Right? So I've got some hidden input shenanigans. That way I can still have my buttons work the way I wanted. This is kind of gross, but let me keep my form the way I wanted. But getting back to our spectrum, right? Like I'm operating over in my code here, but like libraries and frameworks, that's a little bit approachable. I've done a little open source. Maybe I could help things along in Remix land. You know, so libraries, right? It's pretty low on that graph.

And so the first thing I did is I thought, you know, I should actually file an issue. So the next day I went ahead and opened an issue on the Remix repo and said, hey, here this is a bug, you know, like, be, be cool to fix that someday. And I left it at that.

But a couple of weeks went by and I thought, you know, it would actually be cool to fix this bug. So I want to give back a little bit, it's not, it seems like an easy bug, how hard could it be, right. It ended up being a little bit involved, right.

So as it turns out, you know, browsers do know how to construct a form data object from a form, but they don't know how to specify the submitter in the right position. So to work around this, I thought, OK, one option would be I could actually implement form data construction myself. So I looked at the spec and kind of copy pasted the text of it and then implemented it, which is like 300 lines of code, which is kind of a bit much. So then the second approach I went with is like maybe I can do those hidden input shenanigans, but do that remix. And that was a lot less code. But again, it's a little janky. I don't know if it's the best approach, but I feel a little better now because actually six months ago, Sebastian added basically the same thing to React proper with the form action stuff they added. So not terrible. I'm in good company, but I wasn't altogether completely happy with these approaches, but I wanted to get a discussion going with the Remix team to see if we could fix it.

And while I did this research, I realized that smart browser people had been looking into this before. They realized there was actually a missing feature in the browser, in the spec, as far as how this could work because like I said, forums, browsers know how to submit them and know how to properly put the submit button in there. But when you're constructing a forum, a forum dataset from a forum, the form data object didn't know how to do that. There wasn't a way to specify the submitter. And so they kicked around some ideas as far as how that might look, what's the best interface, but nothing really had happened since 2019. And so I thought, okay, that's good to know. Maybe someday I can use that. That'll be cool. But in the meantime, I had another problem with my PR.

So I made these changes, but the Remix team was in the midst of refactoring a whole bunch of stuff and kind of graduating this functionality from Remix into React Router, which meant I couldn't make those changes there, and they'd have to actually land in React Router at some future date when that was done. So I kind of left it in a holding pattern, and a couple of months went by and finally the changes landed in React Router, and so I was able to make those PRs over there instead of in Remix. But then I had a new problem, right? So React Router does its testing with Jest and JS DOM, and there were some missing features, missing functionality in JS DOM. So if you haven't used JS DOM, it's a really great library. Powers Jest, React testing library. It's primarily authored and maintained by Dominic, super smart guy, and I think of him as a JS DOM, so now you can too.

I got to say, though, working on JS DOM was one of the most positive experiences I've had in open source. So Dominic was super responsive, super kind, super patient with a lot of things I was working on and my questions, and so working on JS DOM, the repo, was fantastic, and I highly recommend it if you get a chance. So I got those changes in, and there were a few other things I learned about JS DOM along the way.

So JSDOM, the repo, is a really great implementation of a browser in JavaScript. So what that means is it's following the same specifications, it's testing the exact same way, and it's using the same interfaces that browsers use to generate their JavaScript bindings. So that was interesting. And learning about this, I'm getting more and more familiar with specifications and the process of how these things work, and it got me thinking, like, maybe I could help that form data thing along. The browser people recognize the need, maybe we can get that discussion going again and someday actually use that. But again, like, specifications. This is super intimidating, super daunting. How do you even do that? Like, that's at the top right of the graph. I don't know how. How does this work, right? So let's talk about some of the groups.

There's the World Wide Web Consortium. They've been around since the beginning of time. And if you think about things like CSS or ARIA, they're driving those specifications and helping make the web better by building these standards. And there are various ways you can get involved, so I'd suggest following these links, checking out their GitHub, you can go comment on drafts and things like that. Another group is the Web Hypertext Application Technology Working Group. So this group was formed by browser vendors and other interested individuals, kind of an effort to move the web along in a more pragmatic way, a pragmatic way in touch with what web developers need. And if you think about the core things we use, like the DOM HTML, these are all work streams driven by this group. And they are also on GitHub, and so each of these specifications is actually a GitHub repo, which is interesting. Additionally, there is another repo to check out called the Web Platform Tests. This is really cool. So the entire web platform is tested through the web platform tests. And what's really great is this is a repo that's shared by all the implementations. So they push and pull in every direction. So if a new feature lands, it'll have tests here that the browsers then all use as part of their test suite. So I went back to this discussion, and I realized it wasn't just a discussion, it was a GitHub issue on the XHR repo. And this is looking more and more familiar. It's a GitHub repo.

And I see they have a contributing guideline and pull requests and issues and things like that. And so I thought, maybe I could open a pull request. I don't know what's involved and how hard it's going to be and might have a lot of meetings and take a long time. But let me just try, what's the worst that could happen? So I open a pull request.

And there are two things I did in this PR. So I wanted to add Submitter to form data. So the first thing is to define the interface. What does that look like? So I went with one of the proposals on that XHR issue that I'd seen before, looked good. And added that to the interface that browsers use to generate their JavaScript bindings. And then the other part of the PR is to change the text of the specification so that an implementer or a web developer would know exactly how it could work and how it should work consistently across browsers. And then the other thing to do in this PR is to link to another PR for the web platform tests. And so I opened one of those and added a whole bunch of tests that looked like this to test my new form data functionality that I wanted in a browser. So this is just one example, but it looks very similar to other tests we might write in other testing frameworks in JavaScript.

So I opened those PRs and went to bed. And I was shocked the next morning to see an affirmative response from Aravin Kestra and the editor of the XHR spec, not only responding affirmatively, but also paying implementers from the three major browsers. And I never, like, a million years would have expected this. So it was super cool to see just how engaged and how involved they are and how helpful these individuals are in moving the web along. But so, you know, the thing about that is like, I didn't realize that browsers by and large drive the specification, not the other way around. So in order to make a change, you have to get buy-in from the browsers. And that's up here in the upper right as well. That's daunting. And then even if you do get buy-in, how do you get that on their roadmap to change? Like, this seems like it's gonna take a while. And so my spec pair was kind of languishing for a little while, and, you know, I don't want to be that person and like ping them and say, hey, can you look at this? What do you think, should we do it or not? Because they've got day jobs. I've got a day job. This is kind of a, you know, this is a nights and weekends thing. But I thought maybe I could help the process along. Maybe I could build a POC. And so I did that in JS DOM, and that was pretty straightforward. But I thought, could I actually do this in Chromium or something like that? And I have no idea what I'm doing. I mean, let's be honest here.

I'm a UI developer, I don't know, C++, yeah, I've done some in the past, but no, like, yeah, please no. But I went and looked at the Chromium docs. I looked at all of these great resources they have, and I found in about three commands I could have a working Chromium build locally. And while it took a while for the initial build, what I then discovered is I could do rebuilds in less than a minute. And that gave me the confidence then to start iterating.

And so over the course of a weekend, I was able to get it actually implemented in Chromium. And based on this positive experience with how their developer docs work and just how easy it is to get onboarded, I went and looked at Gecko. And in that same weekend, I was able to get it working in Firefox. And again, similar process there, super easy to get going, great developer documentation. So based on that, I thought, cool, let me go post something on the spec PR. Added the screenshots and pinged the implementers and they responded all affirmatively. Like, yeah, this is great. Let's make this change in the spec.

So we get the change made to the spec, but then the next thing is like, how do we actually make the change to the browsers themselves? How do we get involved in that process? And again, it's like, this is something I care a lot about. I mean, browsers are interested in doing it, but I don't want to like be annoying. And so I thought maybe I can actually go implement it. So diving deeper into their dev documentation and processes, I found it was actually pretty easy to kind of take those POCs and implement them. And so I got different PRs opened and merged in the course of one or two weeks.

So here's some takeaways I learned in working on all three browsers. So Chromium, here's kind of the quick hits. They use Gerrit for code review. CodeBase is C++. They've got really good dev docs. Just read them closely. All the testing is with web platform tests. The process is a little involved to get a change in, but not too bad. And so from the time that you land a change until it shows up on your kid's Chromebook, you're looking at about two months. Firefox, it feels pretty similar. They're using Fabricator. The process is a little lighter weight.

And so the actual time from merge to GA on your Linux laptop, it's like five weeks or so. And actually my favorite one was Safari. They're on GitHub. So that felt a little more comfortable for me. What I'm used to. And the process is very lightweight. The only thing I'd call out here is the time to GA, it's kind of an unknown. With Apple being a black box and their release cycles and that kind of thing. So you don't really know when it's gonna show up on grandma's iPad, but it will come out eventually. So I got those changes in and man, we're cruising along. This is exciting. I realized though, the other big thing is we gotta document this thing because nobody knows about it or knows how to use it. What's the point, right? So the documentation, this kind of feels a little intimidating, but we're cruising, let's go figure it out. And so MDN, as it turns out, it's also on GitHub. They've got really great tooling and documentation for getting started. So check out the content repo. You can pull down MDN and just run it locally. Another repo to look at is the browser compat data. So that feeds into those compatibility tables on MDN and can I use. So I went ahead and opened up here for those.

And so, yeah, got some stuff on MDN and got my Compatibility table going. And it was really fun to watch kind of over the course of a month or two as those columns turned green for the submitter as things landed, you know, went from experimental to actually being launched.

Now, while all this was going on, I did discover there was an issue in JSDOM. I had caused some problems, had to fix those. I also needed to go get React Router upgraded to use the latest Jest in JSDOM, so had to do that. But all told, by the time this all got through, we were now at a point where these changes for the submitter were in all the major browsers, the latest versions. And so I was able to go implement a much simpler fix for React Router.

What I ended up doing is just use a submitter if it's there. And if not, if it's an older browser, then we still go ahead and append the submitter entry to the end. Which is fine for 99.9% of the time. For anyone who cares, I actually have a polyfill that you can make it work correctly in all browsers. But again, there's probably like two people in the world that care about that. But yeah, it's very cool.

So I guess some takeaways. You might be looking at this like Dr. Malcolm kind of shaking your head at me, just because you can doesn't mean you should, right? But I honestly don't care. This was such a great process. And I was so impressed every step of the way with the people that I worked with, you know, from the library authors and maintainers all the way up through the browser and planners and the spec editors. Everybody was very kind, very helpful and very welcoming. And the processes that they've created are extremely streamlined and make it very easy for anyone to get involved. So, you know, whether it's like a little bug you wanna fix, you have an idea for, you know, improving the MDN docs, like whatever it is, you know, this graph is totally wrong, right? Again, I know your experience may vary from mine, but just from what I saw over the last year, I would redraw it like this. It's a much flatter graph, that little bump in the middle is not meant to throw shade, it's just, you know, it's more to show how great things are on the right side and what a great job they've done. And so, you know, I know I'm not the wrong person, you know, everybody tells me that and that's okay. But I'm also unremarkable, right? Like this is not rocket science that I was doing, this is very well-documented stuff and they've made it very easy to get involved. So if I can do it, you can too.