[docs] add "What's Up With Web Platform" transcript
Change-Id: I86dbd5581e5070da3196d151f48863f8229f7295 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5069559 Commit-Queue: Nigel Tao <nigeltao@chromium.org> Reviewed-by: Rick Byers <rbyers@chromium.org> Cr-Commit-Position: refs/heads/main@{#1231635}
This commit is contained in:

committed by
Chromium LUCI CQ

parent
cb020a01a7
commit
4f3b1b2b0c
docs
@ -453,6 +453,7 @@ a video series of interviews with Chromium software engineers.
|
||||
* [What's Up With Mojo - Episode 7](transcripts/wuwt-e07-mojo.md)
|
||||
* [What's Up With Processes - Episode 8](transcripts/wuwt-e08-processes.md)
|
||||
* [What's Up With Site Isolation - Episode 9](transcripts/wuwt-e09-site-isolation.md)
|
||||
* [What's Up With Web Platform - Episode 10](transcripts/wuwt-e10-web-platform.md)
|
||||
|
||||
### Probably Obsolete
|
||||
* [TPM Quick Reference](tpm_quick_ref.md) - Trusted Platform Module notes.
|
||||
|
938
docs/transcripts/wuwt-e10-web-platform.md
Normal file
938
docs/transcripts/wuwt-e10-web-platform.md
Normal file
@ -0,0 +1,938 @@
|
||||
# What’s Up With Web Platform
|
||||
|
||||
This is a transcript of [What's Up With
|
||||
That](https://www.youtube.com/playlist?list=PL9ioqAuyl6ULIdZQys3fwRxi3G3ns39Hq)
|
||||
Episode 10, a 2023 video discussion between [Sharon (yangsharon@chromium.org)
|
||||
and Rick (rbyers@chromium.org)](https://www.youtube.com/watch?v=zFwSAMMCYxI).
|
||||
|
||||
The transcript was automatically generated by speech-to-text software. It may
|
||||
contain minor errors.
|
||||
|
||||
---
|
||||
|
||||
Chrome is how people access the internet and the web, so what exactly is the
|
||||
web platform? Is it just the internet? Today's special guest is Rick, who has
|
||||
worked on input, scrolling and was formerly the director of the Blink web
|
||||
platform team. Currently he's working on transactions.
|
||||
|
||||
Notes:
|
||||
|
||||
- https://docs.google.com/document/d/17jLBCyXFkbHCk81JayoRe93dkO3X4GncvIlLfDAD1WU/edit
|
||||
|
||||
Links:
|
||||
|
||||
- [What's Up With Mojo]
|
||||
- [What's Up With Open Source]
|
||||
- [What's Up With Processes]
|
||||
- [What's Up With Site Isolation]
|
||||
- [bit.ly/blink-compat]
|
||||
|
||||
---
|
||||
|
||||
00:00 SHARON: Hello, and welcome to What's Up With That, the series that
|
||||
demystifies all things Chrome. I'm your host, Sharon. And today, we're talking
|
||||
about the web platform. What is the web platform? Isn't that just the internet?
|
||||
How does Chrome fit into that? Here to answer all that and more is today's
|
||||
special guest, Rick. He's worked on input, scrolling, previously, he was the
|
||||
director of the Blink web platform team, and currently, he's working on
|
||||
transactions. Welcome, Rick.
|
||||
|
||||
00:25 RICK: Thanks.
|
||||
|
||||
00:25 SHARON: For the show. Cool. So let's start with, what is the web
|
||||
platform?
|
||||
|
||||
00:31 RICK: It sounds like an easy question, but actually, it's tough to say. I
|
||||
would describe the web platform as what's in a web developers mind when they're
|
||||
writing code. What are they targeting? What's the platform they're targeting?
|
||||
And I think we've had this long history, I think, as we work as Chrome
|
||||
engineers, we often think of, what's the platform we're creating through Chrome
|
||||
or through Chromium. And that's often quite different from the platform that
|
||||
the web developer has in their mind as they're writing code. It's some kind of
|
||||
union or intersection of all of the browsers that their users might be using.
|
||||
|
||||
01:01 SHARON: Right. I think platform is going to be a term that's going to be
|
||||
very overloaded in this discussion, because I think when people who are working
|
||||
on Chrome think about platform, they think about, oh, does this work on Mac and
|
||||
Windows and Linux and stuff. So that's what platform means to them.
|
||||
|
||||
01:14 RICK: Native platform, yeah.
|
||||
|
||||
01:14 SHARON: But to people like web developers, that's not what platform
|
||||
means. I mean, it might be, right? There might be certain differences.
|
||||
|
||||
01:20 RICK: I think when you say web platform, you mean, what is the virtual
|
||||
operating system that a web application runs in, or a web page runs in.
|
||||
|
||||
01:28 SHARON: OK. And is that different from the web ecosystem?
|
||||
|
||||
01:35 RICK: I think so. I think when I hear the term web ecosystem, I think
|
||||
there's a lot of players in the web. So for example, say, frameworks, I would
|
||||
say React is part of the web ecosystem. They're not part of the web platform,
|
||||
in the sense that they're something that runs on top of the web platform. And
|
||||
then maybe the way I describe web platform is it's the thing developers are
|
||||
coding to. Maybe from that perspective, React is part of the web platform. But
|
||||
I use the term to think, like, what's the lowest level API surface area, the
|
||||
boundary between the user land of the web operating system and the kernel of
|
||||
the web operating system. But these frameworks, I would say, sit somewhere in
|
||||
the middle there. Developers might think of them as core to the platform
|
||||
they're using. But we wouldn't consider them part of the web platform.
|
||||
|
||||
02:10 SHARON: OK. And how does that relate to the open web, which is another
|
||||
term we hear around?
|
||||
|
||||
02:17 RICK: Yeah, I've heard a bunch of people complain that saying open web is
|
||||
redundant because the only web that exists is an open one. But sometimes it's
|
||||
useful to qualify, when we're talking about the web, we're talking about this
|
||||
consensus platform, effectively. It's the only major platform in history that
|
||||
it's not owned by - Linux, I guess, is an open platform that's not owned by -
|
||||
well, anyway, we could debate this for a long time, probably. Most computing
|
||||
platforms are owned by some company that just directs their future, where the
|
||||
web isn't. The web is open in the sense that anyone can build a browser. Anyone
|
||||
can try to convince people to use their browser. And through browsers and web
|
||||
standards, anyone can contribute to what the web platform is.
|
||||
|
||||
03:08 SHARON: OK. If that stuff seems interesting, we have an episode about
|
||||
open source, so check that out. This kind of thing is covered there a bit.
|
||||
Yeah, OK, so platform, in this case, in the past, we've talked about how the
|
||||
browser is like an operating system because that's what it is nowadays.
|
||||
|
||||
03:26 RICK: Yep.
|
||||
|
||||
03:26 SHARON: So I guess it makes sense, the browser runs on different
|
||||
platforms. But then it itself is a platform that other things now run on. And a
|
||||
lot...
|
||||
|
||||
03:32 RICK: It's like a meta platform, sometimes the term we use.
|
||||
|
||||
03:39 SHARON: Yeah, OK, that's what we're talking about. There are lots of
|
||||
browsers. The internet is a big place, so I hear. How do we make sure that
|
||||
things just work across all the different browsers, because most people, if
|
||||
you're just using the internet, you're like, I'll just open whatever my browser
|
||||
app is, and things just work. And that's kind of crazy.
|
||||
|
||||
03:59 RICK: Yeah, it is.
|
||||
|
||||
03:59 SHARON: Can you tell us a bit about what goes into making all that work?
|
||||
|
||||
04:05 RICK: The easy, obvious answer here, of course, is standards. But
|
||||
actually, I think people overemphasize. I think there's a lot of things that go
|
||||
into making that work. And you think, actually, this existed to some extent
|
||||
before we really had web standards in the form they're in today, right? So I
|
||||
would say, in some sense, competition and cloning. The web has this long
|
||||
history of when someone wants to make a browser, the first thing they do is
|
||||
they try to make something that works with existing web pages. And so they'll
|
||||
just go outright copy the behavior of other browsers. And I think that's how
|
||||
the web has always evolved. And then standards are a tool to help make that
|
||||
easier and avoid IP legal risks in doing that. But I think it's important that
|
||||
we see standards as just one of many tools that we use to help create, the term
|
||||
we would use, is an interoperable web, right? A web that developers can expect
|
||||
that it mostly behaves consistently, regardless of where their user is coming
|
||||
from. But there's lots of other tools that we use. The other one that I think
|
||||
is really undervalued is conformance test suites. For most of my time working
|
||||
on Chrome, we saw Chromium's test suite as our primary thing that we were
|
||||
passing. I mean, yeah, there was the ACID test. There were other test suites
|
||||
that we ran. But over the last six years or so, we've really gone through this
|
||||
transition of saying, hey, for the web platform, our first class test suite
|
||||
really is this web platform test suite that we share with all the other browser
|
||||
vendors. The idea being that passing these tests is arguably maybe even more
|
||||
important than standards, or at least as important as standards to creating an
|
||||
interoperable web.
|
||||
|
||||
05:36 SHARON: Standards seems like a big topic. Maybe we'll get into that next
|
||||
time. But we'll talk about all the other stuff that goes into making the
|
||||
internet work for everyone approximately here. So with that, can you tell us a
|
||||
bit, briefly, just what part of, I guess, the internet is covered by web
|
||||
standards? Because in the last episode, we were talking about site isolation
|
||||
and how that's more of a browser-specific feature. It's more of an
|
||||
implementation detail because how it works doesn't really matter to the web
|
||||
developers. So can you tell us a bit about which parts of the browser relate to
|
||||
web standards and which part less so?
|
||||
|
||||
06:14 RICK: Yeah, I think of it in terms of what's the contract with
|
||||
developers. And it's tricky. It's important that there be a bit of a blurry
|
||||
line here, because it's part of what enables innovation and competition in the
|
||||
browser space is to ensure that browsers are free to vary their behavior in
|
||||
ways that they think their particular users might prefer compared to other
|
||||
browsers. But usually you can think of it in terms of, to what extent does it
|
||||
impact what code a developer needs to write. So for site isolation, there are
|
||||
some subtle edge cases maybe, where we had to make some platform changes. When
|
||||
exactly does the way different tabs interact with each other? And I forget the
|
||||
exact details, but you can do window.open to open a tab. And you get a handle,
|
||||
and you can talk to that window, right? So we have to make sure all that stuff
|
||||
works. But then there's other nuances of that we could choose to break to make
|
||||
site isolation work better.
|
||||
|
||||
07:16 SHARON: And so you mentioned, sometimes you do make what are called
|
||||
breaking changes. Can you just tell us about - briefly define what that is?
|
||||
|
||||
7:23 RICK: Sure. Yeah, it's especially challenging for the web platform. It's
|
||||
this very long-lived platform that's existed for a long time that has lots and
|
||||
lots of code written for it. If we insisted on making sure that all code ever
|
||||
written for the web continues to behave identically forever, I think we would
|
||||
quickly run into a place where we were stuck, where we couldn't change the web
|
||||
anymore. Sometimes even making something faster exposes a bug in an application
|
||||
that causes it to break. And so I think it's important that we try to, on the
|
||||
one hand, we have this responsibility that a web page written 20 years ago, you
|
||||
might find it on the Internet Archive or it might be on a server that's never
|
||||
ever going to be updated, we want almost everything that was written in the
|
||||
past to continue working. But we also want to make some exceptions. And this
|
||||
gets especially tricky as we start to say, for example, we want to improve the
|
||||
privacy of the web. How can we meaningfully prevent tracking cross-site if we
|
||||
can't make some breaking changes? So a breaking change just means the contract
|
||||
that we had with developers previously, we're now changing that contract.
|
||||
There's code that was written in the past that might now function differently.
|
||||
|
||||
08:28 SHARON: Yeah, this is something that - I haven't been a web developer,
|
||||
despite working on Chrome. But there are changes where it's like, oh, we can't
|
||||
do that. That's a breaking change. And I'm like, but we can just change it,
|
||||
right? And then if your website breaks, to what extent is that just on the
|
||||
developers to stay up-to-date with this web and the platform and things that
|
||||
are running on versus the trade-off of making sure that the web, at large,
|
||||
still works as expected? Because if you have an app, you get an operating
|
||||
system update and it stops working, you want people to use it, you have to keep
|
||||
updating, keep up-to-date, right? So where is that trade-off there?
|
||||
|
||||
09:03 RICK: I think it's a really tough balance. In general, I think we've made
|
||||
mistakes in the past. Sometimes I think we've had too much hubris in saying,
|
||||
hey, we can do what we want. I think the web's strength is the fact that
|
||||
there's so many developers building for it, so much code written for it. The
|
||||
web's strength is really this interoperability where you can write something
|
||||
and it can run everywhere forever effectively. So I think we have a big
|
||||
responsibility to keep breaking changes to the bare minimum. In practice, we
|
||||
have this whole process that we go through called - we have this process on our
|
||||
blink-dev mailing list, where if you want to propose a change to the web
|
||||
platform, you have to go through this public process where the trade-offs of
|
||||
that change can be debated. And specifically, for breaking changes, we have a
|
||||
set of things that we ask people to look at. And there's a doc, you can see it
|
||||
at [bit.ly/blink-compat] I wrote this doc years ago. And it was the guidelines
|
||||
that the API owners like myself and others would use to try to evaluate whether
|
||||
the benefits of a change seemed to outweigh the risks, or how do we quantify
|
||||
the risks of this breaking change. The simple example that people like to point
|
||||
to all the time is the UseCounter. What fraction of page loads use thing? At
|
||||
the very extreme, we've had a few cases where somebody wanted to delete an API,
|
||||
and we've gone, whoo, that sounds scary. What are you going to break? And we've
|
||||
checked our anonymized data from the field, and we found this API has never
|
||||
been called, more or less, basically, it's literally like never, or maybe there
|
||||
was a couple people loading a test page or something. And it's like, well,
|
||||
yeah, we should just change that. Why should we feel constrained by that? But
|
||||
it's overly simplistic to say, oh, if your page is used on more than 0.0001% of
|
||||
page loads, then you can't change it. It's a lot more complicated than that.
|
||||
But there's a lot of different signals we try to look at. But at the end of the
|
||||
day, the real test is let's try making this change and see what happens. And if
|
||||
it causes - if our data suggests it is going to be low risk and then we try it
|
||||
and we put it in Canary and Beta and we get reports that things are breaking,
|
||||
then we got to stop and we got to rethink.
|
||||
|
||||
11:11 SHARON: Yeah, I guess a lot of the difficulty of this comes from the
|
||||
internet being just a very fat-tailed place. And that's part of the risk. Yeah,
|
||||
so in terms...
|
||||
|
||||
11:19 RICK: There's also a very big difference in degree in different types of
|
||||
breakage. Sometimes you make a change and sites just stop working entirely. And
|
||||
that's a much greater risk. We've got to be a lot more careful with that.
|
||||
Sometimes we can design things where the severity of breakage is a lot more
|
||||
moderate. Maybe we've got a security hole in a particular case - there's one
|
||||
that we've been looking at recently where SVG images embedded in a certain way
|
||||
where they're using the spritesheet in a way that, first of all, is really bad
|
||||
for performance, but second of all, it leads to a security risk. And we found a
|
||||
few sites that are relying on this pattern. And when we fix it to have Chrome
|
||||
behave the same as WebKit, we see sometimes an icon doesn't show up. And it's,
|
||||
like, well, OK, that severity of breakage, that's not good. We don't want to
|
||||
make icon stop showing up. But the trade-off of get this performance and
|
||||
security win, we think, even though that might be on a higher fraction of pages
|
||||
than we would be comfortable saying is trivial, that's something where we say,
|
||||
well, actually, that one might be OK, because it doesn't really break the
|
||||
functionality of web pages as far as we can tell.
|
||||
|
||||
12:30 SHARON: OK. Yeah, everything is just a trade-off, right?
|
||||
|
||||
12:30 RICK: Yeah, exactly. All sorts of trade-offs.
|
||||
|
||||
12:35 SHARON: Yeah. So with all these changes, who out here is wanting these
|
||||
changes?
|
||||
|
||||
12:40 RICK: So it varies a lot. The easiest example to defend, I think, is
|
||||
privacy, right? Removing third-party cookies, that is a huge breaking change.
|
||||
And it's debatable.
|
||||
|
||||
12:46 SHARON: You can turn that on yourself, if you go into the settings and
|
||||
stuff, if you want to.
|
||||
|
||||
12:52 RICK: Yep. Yeah, absolutely. Yeah.
|
||||
|
||||
12:52 SHARON: It's in bug reports.
|
||||
|
||||
12:52 RICK: Yep. So in that case, I would say, that's really driven by our
|
||||
users. Our users want to use a web that involves less tracking. And so we're
|
||||
going to accept some breaking changes with a whole lot of different mitigations
|
||||
to try to minimize the cost. In that particular case, we have a user opt out
|
||||
where users can - we warn people and say, oh, you just reloaded this web page.
|
||||
Maybe it's broken because of third-party cookies. Do you want to click here to
|
||||
turn third-party cookies back on for this web page only, for example. So those
|
||||
are the kind of mitigations we can put in place. You can think of this too. If
|
||||
you've ever seen the pop-up blocker, this is one of the web's first non-trivial
|
||||
breaking changes is the web used to be allowed to open as many new windows as
|
||||
you wanted. And at some point, people realized, oh, we probably shouldn't let
|
||||
any web page open 10,000 windows.
|
||||
|
||||
13:36 SHARON: Right.
|
||||
|
||||
13:36 RICK: So maybe we should limit it to one window per click. But that was a
|
||||
breaking change. And so we introduced a pop-up blocker UI that could say, hey,
|
||||
this website is trying to open a pop-ups without you clicking, asking for a
|
||||
pop-up with a user gesture, would you like to allow it?
|
||||
|
||||
13:49 SHARON: This is one of those things that if you do it well, people don't
|
||||
notice, because I remember, somewhat, the pop-ups and all being a whole thing.
|
||||
And it's like, oh yeah, they just stopped being a problem one day. Cool.
|
||||
|
||||
13:59 RICK: Yeah, except when you're doing some company internal training and
|
||||
the first step in the training is turn off your pop-up blocker.
|
||||
|
||||
14:05 SHARON: Yeah. Yeah, well, what can you do? So the users here is a group
|
||||
who wants changes. What are other groups and entities that are wanting changes
|
||||
in functions and directions in the web?
|
||||
|
||||
14:22 RICK: So another really good one that's come up a lot is in the sake of
|
||||
interoperability. We've had some - sometimes, it's just, hey, we've got this
|
||||
bug, and some website's depending on it. One I was involved with is Gmail was
|
||||
depending on - I think we were parsing the CSS border-image property in a way
|
||||
that was defined in a draft spec that was never the official spec or something
|
||||
like that. And Gmail came to rely on this. And so there's not some user saying
|
||||
that they want this to behave better, but Firefox was conforming to the spec.
|
||||
And so we have to have this whole debate, well, this isn't good long-term. This
|
||||
is an interoperability problem on the web. Do we need to update the spec to say
|
||||
what Chrome is currently implemented should be supported everywhere? And we
|
||||
went - sometimes that's the right thing to do. But we went through discussing
|
||||
with Mozilla folks and other folks in the CSS working group, and we said, no,
|
||||
really that's just a bad design. And if it wasn't for a few sites depending on
|
||||
it, we would just do the right. So in that particular case, the big question at
|
||||
the time was, is it just Gmail? How many other sites are there? And this is
|
||||
before we had the ability to do site specific telemetry. We just landed a bit
|
||||
of a hack into Chromium to say, any time you see this weird border-image thing
|
||||
being used, check to see if you're on Gmail. And if you're not on Gmail, report
|
||||
a metric to say how often it's hit. And what we found was there was very few
|
||||
sites other than Gmail that was relying on this quirk. So we said, OK, we're
|
||||
not going to let Gmail hold back interoperability of the web. We're going to
|
||||
make this breaking change. And at the time, Gmail didn't want us to change it.
|
||||
It was a legacy Gmail product. It was their mobile product. They didn't have
|
||||
anybody working on it. But at the end of the day, it was the web standards
|
||||
community saying, this is how browsers should behave. And it's not reasonable
|
||||
to ask Firefox to go implement this hack, implement a bug, basically, for some
|
||||
website to work. So all browser vendors just agreed that we're going to support
|
||||
the spec here. And then once we did, once that was in Canary, we talked to the
|
||||
Gmail team, and they grudgingly agreed to go fix Gmail to rely on the spec
|
||||
behavior.
|
||||
|
||||
16:15 SHARON: Classic Gmail.
|
||||
|
||||
16:15 RICK: Yeah.
|
||||
|
||||
16:21 SHARON: So the spec, which spec is that? There's only one spec?
|
||||
|
||||
16:21 RICK: No, so this one was for border-image. But yes, this is the problem.
|
||||
I mean, sometimes - hopefully, in the best case scenario, every web platform
|
||||
feature has one spec somewhere, or at least a spec - usually a spec will have
|
||||
different versions, effectively. So in this case, it was CSS border-image. I
|
||||
forget which CSS spec it was in. But yeah, there would be a spec somewhere
|
||||
defining this as a semantics for border-image. But then it gets tricky, because
|
||||
sometimes, if you Google border-image spec, you might get a link to the W3C
|
||||
recommendation, which might be what the spec was, basically, four years ago.
|
||||
And there might be an editor's draft today that is different. And so one of the
|
||||
philosophies we have in Chromium that's a little controversial around this is
|
||||
that we really believe in a living web, living standards, the idea that the web
|
||||
is always evolving. And so we generally just use whatever the current editor's
|
||||
draft is of any spec. So it's usually not the first search result you will get
|
||||
for a spec. You often have to go and click on the editor's draft to see, oh,
|
||||
this is the version of the spec that we're trying to support in Chrome.
|
||||
|
||||
17:26 SHARON: OK. And who out here is responsible for these specs?
|
||||
|
||||
17:34 RICK: A lot of the times - I always say that feature teams working in
|
||||
Chromium, working on API features should feel like they have some
|
||||
responsibility over the spec, making sure that the spec and their
|
||||
implementation are consistent. And if you think the spec is wrong, it's your
|
||||
responsibility to go and start a conversation. But any spec, there's usually
|
||||
some group. Eventually, we want to get - I should clarify. A spec is just a
|
||||
definition of how an API should behave. And usually our intent with every spec
|
||||
is that it be on a standards track to become a standard. And a standard is a
|
||||
spec that's blessed by a standards development organization to be something
|
||||
that has multiple implementations conforming to it and has reached a level of
|
||||
maturity to say this should be considered a standard. The distinction there
|
||||
sounds a little academic. But it's important to know, we ship things in
|
||||
Chromium all the time based on specs that aren't yet standards. But we have an
|
||||
Intent to - our whole Blink process and the Intent to Ship email threads that
|
||||
we do are all about trying to ensure that the platform that we're creating in
|
||||
Chromium is moving towards a standardized one, is expected to become
|
||||
interoperable over time. And there's delicate balance to walk there because we
|
||||
don't want to slow the pace of evolution of the web. And we always say,
|
||||
Chromium's velocity can't be blocked by others. We don't want to say that
|
||||
anybody in the web standards community can say, no, this can't go into
|
||||
Chromium, because that's really important to competition between browsers, that
|
||||
browsers can ship what they think is right for their users. But at the same
|
||||
time, we want to trend towards a web that is interoperable and standardized.
|
||||
|
||||
19:17 SHARON: Right. Yeah, it seems like a balance there, because on one hand,
|
||||
you want a website to load on all these different browsers. But if they all are
|
||||
just implementing the spec, then what makes them different? And why pick one
|
||||
over the other?
|
||||
|
||||
19:29 RICK: Yep. Yeah, there's definitely a balance.
|
||||
|
||||
19:34 SHARON: In terms of the different organizations responsible for the
|
||||
specs, is there one organization with multiple divisions, I guess, branches? Or
|
||||
are there different organizations that are responsible for different areas?
|
||||
|
||||
19:46 RICK: Yeah, there's lots of different organizations. So we call it the
|
||||
SDOs, Standards Development Organizations. So we work a lot with the W3C.
|
||||
People are probably familiar with the W3C. People are maybe less familiar with
|
||||
a lot of the web's core functionality, so HTML and DOM, core things of the web
|
||||
have not been really driven by the W3C for a long time. There's a fascinating
|
||||
history. Chris Wilson could probably tell you more about this if you interview
|
||||
him at some point. But at some point, the W3C decided the web was for
|
||||
documents. And a group of browsers got together and said, we really want to
|
||||
make web apps. And the W3C said, the web is not for apps. And so they created a
|
||||
different SDO called WHATWG, the Web Hypertext Application - blah, blah, blah -
|
||||
Working Group, and basically, had to write a new HTML spec from scratch. And
|
||||
then that really became what all the browsers pointed at as the HTML. But for a
|
||||
while there, we had two different specs that were both labeled HTML. And people
|
||||
assumed that W3C HTML was what the web implemented, where, in fact, every
|
||||
single browser really implemented WHATWG HTML. And there was politics involved
|
||||
and all of that. But due to some great work by Shruthi and others, we got that
|
||||
worked out now. So now WHATWG and W3C collaborate, but still, HTML and DOM are
|
||||
really done in WHATWG. The JavaScript language is done in a different standards
|
||||
group called ECMA. Yeah, the IETF, like, lower level networking stuff, there's
|
||||
the IETF group. And yeah, there's a bunch of different standard groups. And
|
||||
even within W3C, there's different levels of maturity. There are working groups
|
||||
that produce these standard track documents. That's great for stuff that's
|
||||
fairly mature. But when you want to start exploring and trying to explore a new
|
||||
area and do something that's cheap to fail, that overhead doesn't really work.
|
||||
And so things start in community groups, which are much lighter weight process.
|
||||
So a lot of the new APIs that we do start in a group called the Web Incubator
|
||||
Community Group in the W3C. And the idea is that you can start with a small
|
||||
group of folks who are interested. And it's really, whoever is interested in
|
||||
trying to solve a problem can get together in this forum, and really, it's just
|
||||
about collaborating on GitHub trying to work together toward something that
|
||||
might eventually become a spec that could be on the standards track in a
|
||||
working group somewhere.
|
||||
|
||||
12:03 SHARON: And who are the people typically working in these organizations?
|
||||
Are they people who have day jobs working on a browser or other open source
|
||||
projects or what kind of things?
|
||||
|
||||
22:16 RICK: This is one of the things I love about working on the web. It's a
|
||||
wide variety, even more so than you'd see if you look at who's contributing to
|
||||
Chromium, right? There's people who contribute to Chromium just as a hobby in
|
||||
their free time. But it's mostly Google employees and employees of Microsoft
|
||||
and stuff like that. But in the standards world, I find there's a lot more
|
||||
independence. There's a lot more - there's people who will - contribution can
|
||||
be everything from chiming in on a few GitHub issues to being an editor of the
|
||||
specification. So the investment can vary quite a lot. But yeah, so, certainly,
|
||||
browser vendors invest a lot. A lot of spec work is done by browser vendors.
|
||||
But then also, the people using those APIs - so sometimes somebody will have a
|
||||
particular need for an API in their product, and they'll care enough about it
|
||||
to go and invest in either doing the standards work themselves or hiring an
|
||||
external consultant to go and do that standards work. My favorite example of
|
||||
that, if you've ever used CSS Grid, a lot of that work for Grid - I mean, I
|
||||
think a lot of the standards work was done by Microsoft initially. And I'm sure
|
||||
there's other browser folks involved. But at the end of the day, Bloomberg, the
|
||||
financial company, they have these Bloomberg terminals, right? They run an
|
||||
application that's just running inside of Chromium. And it's not really running
|
||||
on the web. It's just running inside of Chromium. But they're the ones who
|
||||
hired Igalia, which is a consultants company to go and implement this grid
|
||||
feature in Chromium and WebKit, I believe.
|
||||
|
||||
23:47 SHARON: Can you tell us a bit more about Igalia? Because if you look at
|
||||
changes - if you just look at the blame in Chromium code search, you see Igalia
|
||||
emails come up a lot. So who are they?
|
||||
|
||||
24:00 RICK: Igalia is the number one contributor to Chromium outside of Google.
|
||||
|
||||
24:00 SHARON: OK.
|
||||
|
||||
24:05 RICK: And they're a collective, which means they're a group of folks. So
|
||||
they're not a company, but you can think of them as an independent consultancy
|
||||
agency, basically, that are web browser or open source experts. They don't just
|
||||
do web, they do other stuff as well. But they're really open source experts for
|
||||
hire. And so, yeah, it's really cool. It means that any some company thinks,
|
||||
oh, I really wish the web was better in this way, but I don't know how to make
|
||||
that happen. They can just go hire Igalia. And there's others there's some
|
||||
other companies like Bocoup. And there's a few other consulting companies. But
|
||||
Igalia is the one that's really biggest into contributing directly to browser
|
||||
engines.
|
||||
|
||||
24:43 SHARON: Oh, neat. OK.
|
||||
|
||||
24:43 RICK: And Google, ourselves, sometimes we find it makes a lot of sense
|
||||
for us to just hire Igalia to do some work.
|
||||
|
||||
24:48 SHARON: Right, like the Mojo legacy IPC transition.
|
||||
|
||||
24:55 RICK: Yeah, some of our code health stuff, we've found it to be most
|
||||
effective to hire a guy to help us with some of it.
|
||||
|
||||
25:00 SHARON: OK, cool. I didn't know that.
|
||||
|
||||
25:00 RICK: Yeah.
|
||||
|
||||
25:00 SHARON: Neat. With the open source versus proprietary - I don't know,
|
||||
company browsers, how does Chrome versus Chromium fit into this whole web
|
||||
platform as a whole?
|
||||
|
||||
25:12 RICK: So in general, we want the platform to be consistent across
|
||||
browsers. So, I mean, Chrome and Chromium are already almost identical in a
|
||||
bunch of ways, in most ways. There are places where Chrome adds, and actually,
|
||||
I guess you could even argue, Chrome does add some things to the platform. So
|
||||
media codecs, for example, is H.264 is a video codec that requires a license.
|
||||
And so Chromium doesn't come with an H.264 decoder because you've got to get a
|
||||
license to have that. Whereas, Google Chrome pays the license fee in order to
|
||||
be able to ship an H.264 decoder. So in that sense, that is really an aspect of
|
||||
the platform. You have a web page that plays H.264 videos. That is a web page
|
||||
that will work in Google Chrome and not Chromium. But that's an exception. We
|
||||
don't like that. In general, we would try to avoid ever getting that situation
|
||||
ever again. But otherwise, from a platform perspective, you can expect them to
|
||||
really be identical.
|
||||
|
||||
26:10 SHARON: OK. With Chrome, and probably to a lesser extent, Chromium, but
|
||||
not really, there's a lot of people who use this browser. So how do people who
|
||||
work on Chrome try to maintain an open web and have everybody have a say in
|
||||
things, when if Chrome just went ahead and made a change, it would force other
|
||||
browsers to do a similar thing. And generally, we don't want that. So how do we
|
||||
balance that?
|
||||
|
||||
26:40 RICK: Yeah, there's a tricky balance. Like I said, ultimately, at the end
|
||||
of the day, Google feels accountable to our users to build the web that we
|
||||
think our users want. But we also feel accountable to the web industry, the
|
||||
ecosystem, to have an interoperable and standards-based web. And so one thing
|
||||
we try to do is we have this the Blink launch process I mentioned earlier,
|
||||
where a key part of that process is we want to make sure that any time we want
|
||||
to make a change to the web platform in Chromium, that change needs to be
|
||||
described in a way that others could implement, so that means a specification.
|
||||
And critically, it means a specification that has IP rights, that other people
|
||||
could implement it in a way that they're not likely to get sued for patent
|
||||
infringement for. But also, we want to have a public debate of the trade-offs,
|
||||
the maturity level of this, is this API well enough justified, is the
|
||||
specification a high enough quality. Any time we're shipping a new API, we also
|
||||
want to make sure that we have solicited feedback from others. So we generally
|
||||
will file standards positions. Both WebKit and Gecko, the Firefox engine, have
|
||||
a process for us to file a request for standards position to ask, hey, what's
|
||||
your opinion of this. And just because they don't like it doesn't mean we won't
|
||||
ship it. But we have a group of us called API owners, who, anytime somebody
|
||||
wants to ship a new API, we review these criteria - which, by the way, if you
|
||||
go to [chromestatus.com], you can see each of the features we're shipping. And
|
||||
you can see all the fields that people have to fill in, in order to request
|
||||
permission to ship a new API. And then the API owners review those and make a
|
||||
judgment call on whether the benefit of shipping this outweighs the cost or the
|
||||
risk that this won't be an interoperable behavior across browsers.
|
||||
|
||||
28:26 SHARON: OK, yeah. I feel like it's the kind of thing where the more you
|
||||
hear about it, the more you're just like, how does any of this work?
|
||||
|
||||
28:32 RICK: Yeah, it's kind of incredible. It feels like a lot of process
|
||||
overhead sometimes. And I really feel - we try to make it as lightweight as
|
||||
possible. We try to make it also - we want it to be an environment where it's
|
||||
OK to make - if you're posting to this mailing list that lots of people watch,
|
||||
and it's OK to make mistakes there. I've made a bunch of mistakes in some of my
|
||||
engagement on some of this stuff in public. So it can be a little nerve
|
||||
wracking sometimes working in public. I know Elly talked about that a little
|
||||
bit in open source as well. Yeah, but it's incredible at the end of the day, we
|
||||
do end up with a web that mostly works the same across browsers. In fact, I
|
||||
would argue, if you look at the whole history of the web, I would say that the
|
||||
web is probably more interoperable today than - I mean, it used to be that it
|
||||
was common for websites to say best viewed in. Best viewed in Netscape
|
||||
Navigator 4, right? And that was - it took a lot more heroics, I would say,
|
||||
back in the day to make a website that worked consistently across browsers,
|
||||
where now we have much more of a culture of each of the browser engines,
|
||||
generally, typically, prefers to ship only when there's a good quality spec and
|
||||
plausible interoperability between engines. But that's still relatively new
|
||||
when you think about it in terms of the whole history of the web.
|
||||
|
||||
29:54 SHARON: With the point of the web being more interoperable than before,
|
||||
now with things being, like, you see Chromium based things in the most random
|
||||
places, right? Cars, that space thing...
|
||||
|
||||
30:11 RICK: Yeah, SpaceX.
|
||||
|
||||
30:11 SHARON: Right. All sorts of devices, embedded systems, and all that kind
|
||||
of stuff. So how has that kind of thing - more things becoming internet enabled
|
||||
and connected - I was trying to buy a washer, and only one model was not
|
||||
internet connected. I was like, I don't need this. But anyway.
|
||||
|
||||
30:31 RICK: I have a blender that runs a version of WebKit maintained by
|
||||
Igalia.
|
||||
|
||||
30:38 SHARON: Yeah.
|
||||
|
||||
30:38 RICK: It's pretty cool, because it has a screen that you can pull up
|
||||
recipes on, stuff like that.
|
||||
|
||||
30:44 SHARON: OK. Yeah, so now that all these other things are now computers,
|
||||
that not that long ago, only computers were computers, how has that affected
|
||||
the web platform? Because a lot of times, in - so my mom works in navigation,
|
||||
which affects a lot of this stuff. And sometimes you'll hear things like, why
|
||||
is this using Chromium? So how has the craziness increase of the uses of
|
||||
Chromium, how has that affected the web platform?
|
||||
|
||||
31:11 RICK: Yeah, it's interesting. We created Chromium to be a great web
|
||||
browser. And we've often been faced with this struggle, we wanted Chromium to
|
||||
be open source. We wanted people to get whatever benefit from it that they
|
||||
could. We wanted them to use it for other reasons. But we've also found it to
|
||||
be important to really stick to the principles, what is Chromium for? And so we
|
||||
say, Chromium is intended to be a web browser. And people use Chromium in other
|
||||
environments, like, you can use Electron as an application platform. You can
|
||||
build Slack or VS Code or whatever. I think Darin talked about this a bunch in
|
||||
his...
|
||||
|
||||
31:52 SHARON: You watch the videos. Wow.
|
||||
|
||||
31:52 RICK: Of course I did. [LAUGHTER] But I think that's awesome. But it's
|
||||
dangerous, I think, to think that, hey, we should just make Chromium. Chromium
|
||||
should be a project that should be an operating system for everything. And so
|
||||
instead, what we've sometimes found ourselves saying is, hey, you're using this
|
||||
for a fork of the web, therefore, you should use a fork of Chromium. So I mean,
|
||||
even e-readers, some e-readers like EPUB format is CSS with some bespoke
|
||||
additional things in it that aren't available in web browsers.
|
||||
|
||||
32:25 SHARON: Right.
|
||||
|
||||
32:25 RICK: And so we've said, hey - at least, it was at some point. I don't
|
||||
know the current state. Maybe this has changed. There's TVs that have web
|
||||
browsers built into them. And then they have some non-web extensions to the web
|
||||
platform for their TV platform. And so in all those cases, our principle is,
|
||||
hey, it would make it - it would be an unreasonable maintenance burden on
|
||||
Chromium to support all of these different use cases. Think of your CQ. We've
|
||||
got enough bots on the CQ already, right? If we had to have bots for all these
|
||||
different...
|
||||
|
||||
32:55 SHARON: TV, fridge, blender.
|
||||
|
||||
33:01 RICK: Yeah, exactly, from every different manufacturer, every different
|
||||
version, right?
|
||||
|
||||
33:01 SHARON: Yeah.
|
||||
|
||||
33:01 RICK: So we think it's great if people want to use Chromium for other use
|
||||
cases than what it is intended, which is building browsers. But that's not a
|
||||
cost we're willing to then impose back on the upstream repository.
|
||||
|
||||
33:14 SHARON: Right. Yeah, I guess that's another trade-off too, of just
|
||||
simplicity and hand-in-hand security versus features, because just from what I
|
||||
see, there's so many cases where it's like, oh, we needed this. And there's
|
||||
just all these edge cases. And it's very hard to reason about. And you pay for
|
||||
that, in terms of security and just how long it takes to figure out what to do,
|
||||
what you're doing.
|
||||
|
||||
33:41 RICK: Yeah. And we saw this. I mean, this is a trade-off that I think any
|
||||
open source project needs to make. It's reach versus complexity or something.
|
||||
And I remember back when Chromium was using WebKit as our browser engine,
|
||||
WebKit did support a variety of different use cases that Chromium didn't
|
||||
support. And it did, for example, there were - I forget the number - there was
|
||||
five or six different build systems that you could use to build WebKit. And so
|
||||
when you added a file, you had to go and update five or six different build
|
||||
rules, right? We take it for granted now that you just have to update one GN
|
||||
file. But for those of us that worked in the WebKit days, and I'm guessing
|
||||
maybe it's somewhat better now. But I'm sure there's still an aspect of that.
|
||||
And it's a trade-off, right? There's a benefit of, you can get broader reach if
|
||||
you're willing to support a wider variety of configurations. What toolchains do
|
||||
you use? We've taken a pretty hard hardline stance on Chromium supports Clang.
|
||||
And Igalia's heroics notwithstanding, they do a lot of work to make sure that
|
||||
GCC can still work. But officially, Chromium just supports Clang because it's
|
||||
already so complicated to reason about all of our different dependencies, that
|
||||
we want to take every opportunity we can to say, hey, the core of the project,
|
||||
we're just going to pay these costs and try to avoid these multiplicative
|
||||
matrices of test environments.
|
||||
|
||||
34:57 SHARON: Yeah. Yeah, I think, looking at things now and learning about how
|
||||
things are now, it's like, oh, everything is so hard. But then you hear about
|
||||
stuff like this, you're like, oh, things used to be so much worse.
|
||||
|
||||
35:02 RICK: Yeah, and that was - I mean, another aspect of the complexity here
|
||||
is where do you define your repository boundaries? Chromium is a
|
||||
self-contained, well, it's not self-contained. Chromium is designed to be a
|
||||
browser, pulls in a bunch of third-party dependencies. So, for example, V8, our
|
||||
JavaScript Engine, comes from a different repository. But the Chromium UI and
|
||||
the web platform Blink sit in one repository today. It used to be, obviously,
|
||||
when we were using WebKit, that was a different repository. Apple owned the
|
||||
WebKit repository. We would pull it into Chromium. But then it would mean,
|
||||
those of us who work back in that day, a lot of changes you wanted to make, you
|
||||
had to do these three-sided patches, where it's like, oh, you're going to want
|
||||
to use something in - let's see, how did this work? Man, this was a long time
|
||||
ago. You had to add some code to Chromium, some scaffolding for some APIs that
|
||||
WebKit might call into. And then you'd go and you'd land the WebKit patch that
|
||||
could call into those Chromium APIs. And then you had to go land the Chromium
|
||||
patch that would call into the WebKit API. So it was pretty common that one
|
||||
feature that would be one commit for us today would be three separate commits
|
||||
in the old days. And if you want to make a breaking change, man, that's even
|
||||
harder. You're trying to change the protocol between WebKit and Chromium,
|
||||
you've got to basically add a new version of the API into Chromium first, and
|
||||
then update in one commit. And then your next commit, you have WebKit call into
|
||||
that new one. And then your third commit could go remove the old one. And it
|
||||
was just - there's a trade-off there. It's more generality, but a lot more
|
||||
complexity.
|
||||
|
||||
36:28 SHARON: Oh, my goodness. [LAUGHTER] Right, so now that we have reduced
|
||||
some of that complexity in that way, it's like, if you have a bigger spaces,
|
||||
you fill it with stuff, right?
|
||||
|
||||
36:40 RICK: Yeah, that's true.
|
||||
|
||||
36:45 SHARON: Now that difficulty has been taken away, what difficulty has
|
||||
moved in to replace it?
|
||||
|
||||
36:45 RICK: I mean, we've just added a lot of code, a lot of complexity. The
|
||||
web platform's gotten a lot more complicated. Again, this is a trade-off that
|
||||
people would debate. As we've gone to try to meet more and more use cases on
|
||||
the web, we've made the web platform more complicated. We've added more APIs
|
||||
that can do different things. You could argue, should I be able to build a
|
||||
website that controls my LEGO robot over Bluetooth, or maybe you could just
|
||||
say, that's not a use case we care about on the web. This is something we
|
||||
actively debate, we disagree with other browsers on. On Chrome, partly, we take
|
||||
the security philosophy of saying, well, we would rather our users are using an
|
||||
API that could have some abuse risk than installing a native application that
|
||||
almost certainly is riskier.
|
||||
|
||||
37:33 SHARON: Right.
|
||||
|
||||
37:33 RICK: So again, there's a trade-off to be struck. But the complexity
|
||||
cost, the burden that we're creating on the whole web platform by having all
|
||||
this complexity in the long run, is it actually paying for itself? Reasonable
|
||||
people will disagree on that.
|
||||
|
||||
37:47 SHARON: This is more of just a miscellaneous curiosity question. But in
|
||||
terms of the people debating these kinds of things, who are actively working on
|
||||
standards and all that kind of stuff, do you have an idea of ballpark how many
|
||||
people across various organizations and individuals...
|
||||
|
||||
38:05 RICK: That's a good question.
|
||||
|
||||
38:05 SHARON: Are doing it? Because when I first joined Chromium and stuff, a
|
||||
lot of people work on Chrome. But it's not as many people as you would think
|
||||
for how widely used it is. Anytime you're using the internet, Chrome is in
|
||||
there somewhere, probably, like Chromium. And for that amount of use, it's
|
||||
like, oh, there's not a ton of people working on this.
|
||||
|
||||
38:24 RICK: I would say, if you just say for the web, what's the set of folks
|
||||
who are working on trying to evolve the web platform, the web standards
|
||||
community. And I assume we'd probably go all the way down to HTTP. And it
|
||||
depends a lot where you draw the line.
|
||||
|
||||
38:36 SHARON: Right.
|
||||
|
||||
38:36 RICK: Because there's a ton of people, for example, in the identity
|
||||
community that talk about different standards for identity that browsers don't
|
||||
necessarily understand. It's built on top of the web. So if we exclude all that
|
||||
and we just say, like, number of people involved in trying to evolve the
|
||||
specifications that make up the web platform, my guess would be somewhere on
|
||||
the order of probably less than 10,000. It's probably more than a couple
|
||||
thousand. But yeah, that'd be my guess.
|
||||
|
||||
39:07 SHARON: Yeah. Because that's somehow both more and less than I expected.
|
||||
I don't know what I expected.
|
||||
|
||||
39:13 RICK: Yeah, I mean, that might be an overestimate. I mean, you go to a
|
||||
conference, like, W3C TPAC is W3C is annual conference. And I think - I don't
|
||||
know the numbers off the top of my head. But I think there's often a couple
|
||||
hundred people there.
|
||||
|
||||
39:19 SHARON: OK.
|
||||
|
||||
39:25 RICK: Right. So those are probably the most - and including virtual
|
||||
attendees, I think it's 200 or 300 or something like that. Anyway, I probably
|
||||
should know those numbers off the top of my head.
|
||||
|
||||
39:31 SHARON: I don't think - that doesn't seem like that useful information to
|
||||
have.
|
||||
|
||||
39:37 RICK: I think it's a really good - it's a really interesting question. If
|
||||
you think of the web as this organic ecosystem, like, we're talking about web
|
||||
ecosystem. So you can think of - and it's almost like this living, breathing
|
||||
entity that changes over time. Some basic questions like, well, how big is it?
|
||||
How many people are contributing to it? How much money is going into evolving
|
||||
the web ecosystem? For the most part, we just don't know. And also, then you
|
||||
could ask, well, is that good or bad? Does society as a whole benefit when more
|
||||
money goes into making the web better? Or actually, would society benefit more
|
||||
if there was this is a more stability and there was more constraint and the web
|
||||
was changing less? There's really hard questions. And I think it's just like we
|
||||
see with climate or any question about natural ecosystems, it's a very complex
|
||||
system that's just incredibly hard to reason about. Oftentimes, the best you
|
||||
can do is be scientific and go do a study. Change something and see the
|
||||
reaction.
|
||||
|
||||
40:34 SHARON: Right. Yeah, I mean, it's very crazy to think about because a lot
|
||||
of the web is available just for free. And you're not paying for it, but it all
|
||||
works. There's a lot of work that goes into it and keeping it running. So
|
||||
what's going on there?
|
||||
|
||||
40:52 RICK: It's really fascinating to think about the economics of this. For
|
||||
every platform, what's the economics that led to this platform existing? And
|
||||
early computing, it was really about device sales. You would buy an IBM
|
||||
mainframe or something, and the cost of buying that mainframe would go to build
|
||||
the operating system, I'm assuming. I didn't use computers back then. But
|
||||
certainly, like, Windows, Windows was funded by - you buy a PC, and you pay for
|
||||
a Windows license. So you're really buying the operating system. Where does the
|
||||
money come from for building browsers? The reality today is that there's
|
||||
multiple reasons why companies might want to build browsers. At Google, one of
|
||||
the reasons we invest in browsers is because we want to make sure that Google
|
||||
services can have a platform that they can run on, a stable platform for you to
|
||||
be able to use Gmail or whatever. But, of course, search engines are a big part
|
||||
of that as well. A lot of browsers are funded by search engines, at the end of
|
||||
the day.
|
||||
|
||||
41:52 SHARON: Yeah. That makes sense. Anyway, that's very complicated. That is
|
||||
not my day job, at least. So we will not talk about things we don't know about.
|
||||
Yeah. We have a bit of time left. Do you have any just general fun stories
|
||||
about web platform things and the time you've worked on it? Hot takes, we like
|
||||
those.
|
||||
|
||||
42:09 RICK: Yeah, what was the one I was telling you I was going to tell you
|
||||
about?
|
||||
|
||||
42:14 SHARON: Oh.
|
||||
|
||||
42:14 RICK: I forgot now.
|
||||
|
||||
42:14 SHARON: OK. Something about a breaking change?
|
||||
|
||||
42:19 RICK: Yeah, I don't know.
|
||||
|
||||
42:19 SHARON: OK.
|
||||
|
||||
42:19 RICK: I mean, one of my fun - just going back to this question. We were
|
||||
talking earlier about compatibility. And it's interesting to me, whenever a new
|
||||
browser gets started, it's always a big challenge to go make it work with the
|
||||
existing web. And once a browser becomes popular, then somehow it becomes less
|
||||
of a challenge. It's like, oh, developers are going to do the work now to make
|
||||
sure that it works in this browser. And so it was, I think six or seven years
|
||||
ago or something, and I was doing some work for Gmail. And I was seeing how
|
||||
hard it was to make Gmail work reliably across websites. And we're also talking
|
||||
with, I think this was the time when Microsoft decided to build their Edge HTML
|
||||
browser engine. They were basically building a new browser engine from scratch
|
||||
and trying to make it be compatible for the web. And we realized, man, a lot of
|
||||
our ideals about, hey, the web is standards-based and whatnot, like, it was
|
||||
falling down in practice, right? The web was actually - Edge HTML was having to
|
||||
basically reverse engineer a lot of things and put a bunch of behavior into
|
||||
their engine that wasn't in any spec anywhere. And we realized, holy crap, this
|
||||
is actually a really big problem. We realized that we really weren't taking
|
||||
this idea of conformance testing as a first class property of the web. If we're
|
||||
trying to design the web to be a coherent platform, it's like software
|
||||
engineering 101 to say, if you want a reliable platform, that platform needs to
|
||||
have a test suite. And we really didn't have a test suite for the web back
|
||||
then. Things like web platform tests existed back then. But we weren't treating
|
||||
it as a first class part of our engineering process. And so we had this dream
|
||||
back then to say, we need to put this as a first class part of our engineering
|
||||
process such that whenever we change the web, we're always making sure that we
|
||||
are contributing to this test suite. We imagined a future where any time
|
||||
anything ever went into the web, it was always getting added to this test suite
|
||||
so that conforming to this test suite was your test whether or not your browser
|
||||
could actually run the web. Anyway, I bring this up just because, to me, it's
|
||||
mind-blowing to realize, back then, that seemed like such an impossible task.
|
||||
And I'd say, now, we've really crossed this threshold where all the browsers
|
||||
now see conformance test suites, web platform tests, and some of the other
|
||||
projects have their own test suites, as a first class part of the engineering,
|
||||
the way we engineer the web. So I would say we've really up-leveled the
|
||||
engineering of the web to be more disciplined. And I think everyone who's
|
||||
worked on the web platform over the last 5, 10 years should feel proud of how
|
||||
it's now engineered more like a real - not, congratulations, we have a test
|
||||
suite.
|
||||
|
||||
44:49 SHARON: So for engineers who work on Chrome or other browsers, for a lot
|
||||
of them, they don't really ever interact with the open web part of it, right?
|
||||
So even in navigation, which seems like it affects a lot of stuff, very rarely
|
||||
does it intersect with open web facing stuff.
|
||||
|
||||
45:08 RICK: If you're lucky. I don't know about you, usually it intersects
|
||||
accidentally, right? I don't know about you, but every time I've had an intern
|
||||
or a Noogler, and we said, oh, this would be a good starter bug. And it's
|
||||
turned out, it's like, oh, this is going to be a one week bug as your starter
|
||||
bug. And it's turned out, oh, it turns out when they went to fix it, some weird
|
||||
web page somewhere broke. And it turned into a six month project of
|
||||
understanding the compatibility constraints and trying to find a way to do it
|
||||
in a way that doesn't break websites.
|
||||
|
||||
45:32 SHARON: OK, yeah, that is my everyday life. Not necessarily always for -
|
||||
more importantly, I guess, even for where I am, having a solid understanding of
|
||||
how the web platform works is not strictly necessary for getting a lot of
|
||||
things done. For some things, it is. So for people who don't really interact
|
||||
with the more open web standards, that side of things, what do you think they
|
||||
should know about the open web for just being someone who works on a browser?
|
||||
|
||||
46:03 RICK: That's a good question. Certainly, there's a line of thought that
|
||||
anybody working on a browser should try being a web developer. Try building
|
||||
just a little hobby website. But I don't know if that's - I think there's some
|
||||
benefit to that. When I started on Chrome, I said, how am I going to work on
|
||||
Chrome? I haven't built for the web - I think the line I used, I did some work
|
||||
for a website development company back in the mid '90s. So I was like, hey,
|
||||
last time I built for the web, tables were new. So I went to work - that's why
|
||||
I was working on Gmail for a little while. I was trying to get myself
|
||||
experience in what it's actually like. And actually, that served me really
|
||||
well. That helped me see that we were missing this big problem with
|
||||
interoperability. But I don't think it's necessarily for everyone. I think it's
|
||||
very reasonable to say that you don't need to be an expert. Being a web
|
||||
developer and being a browser engineer are very different jobs. And I don't
|
||||
consider myself an expert web developer at all. And so, I think, in general, it
|
||||
is totally fine to be an expert in browser navigation, for example, without
|
||||
being an expert in web development. It might get harder - depending maybe if
|
||||
you're lower in the stack, it's probably easier. For example, if you work on
|
||||
the layout system or the style system, you probably need to at least have some
|
||||
understanding of web design and how you would use the style system to make UI
|
||||
in different ways.
|
||||
|
||||
47:32 SHARON: Yeah, because I think, since working with a bunch of security
|
||||
folks, a lot of them do have compatibility-based aspects to their job of just,
|
||||
how do we make the HTTP headers, for example, kind of thing. And then, like,
|
||||
oh, I don't know how any of this works, OK.
|
||||
|
||||
47:58 RICK: I mean, one thing I'll say is anytime - I found it useful for me,
|
||||
working on browsers for - it's been 13 years now, I guess - is when I've worked
|
||||
on a problem, I very often start on MDN. And I say, oh, here's a bug that
|
||||
somebody's filed. What is this web platform API that they're using? And I've
|
||||
often gone back and forth between MDN, Mozilla Developer Network, is the API
|
||||
reference docs for the web. And it's pretty darn good. It does a good job of
|
||||
explaining. I would never start with a spec, even for somebody that's - the
|
||||
specs go into the minutia detail. They're not intended for web developers.
|
||||
They're intended for browser engineers. So I usually go back and forth between
|
||||
MDN and then a simple editor like JSBin or something, where you can just take a
|
||||
chunk of HTML and CSS and JavaScript and just paste it over here and just hack
|
||||
on changing it. And I always find that to be the best way to learn.
|
||||
|
||||
48:44 SHARON: OK. All right, well, go and make some websites, guys. Yeah. All
|
||||
right, well, that was cool. Yeah, it's very neat to hear about how Chrome fits
|
||||
in with the web at large, because if you're working on a browser, it's like,
|
||||
OK, this is my project, my job, whatever. And if you don't interact with the
|
||||
rest of - if you're not in one of these other - working on a thing that is open
|
||||
web facing, it's easy to forget about all of that. Like, oh yeah, this is part
|
||||
of the internet.
|
||||
|
||||
49:20 RICK: I think it's really easy to get focused on your area of expertise.
|
||||
And I think it's helpful to take a step back every now and again and look at
|
||||
the 10,000 foot view and realize, hey, collectively together, we're building
|
||||
this unique thing, this open computing platform that is, by far, the world's
|
||||
dominant computing platform. There's more web developers than developers of any
|
||||
other platform, I think, by an order of magnitude or something like that. And
|
||||
it's this crazy, messy, chaotic thing. It's like Wikipedia in a way, right?
|
||||
Most people would assume, it couldn't possibly work. But actually, when we get
|
||||
the incentives aligned right, it actually seems to work over time. And we're
|
||||
actually making this open platform that gets more and more powerful over time.
|
||||
It's pretty cool.
|
||||
|
||||
50:04 SHARON: Yeah, the topics I've been trying to cover so far have been like,
|
||||
these seem like very important things. And I feel like - it's like, oh, I
|
||||
should know about this. I don't, but I should. And this is another very good
|
||||
step along that journey. Thank you very much for sitting down, talking.
|
||||
|
||||
50:18 RICK: Thank you, it was fun.
|
||||
|
||||
50:18 SHARON: Yeah, have a good day.
|
||||
|
||||
50:24 RICK: Thanks, you too.
|
||||
|
||||
50:24 SHARON: There are two in person, and they're both - they're clearly a
|
||||
work in progress.
|
||||
|
||||
[What's Up With Mojo]: https://www.youtube.com/watch?v=at_35qCGJPQ
|
||||
[What's Up With Open Source]: https://www.youtube.com/watch?v=zOr64ee7FV4
|
||||
[What's Up With Processes]: https://www.youtube.com/watch?v=Qfy6T6KIWkI
|
||||
[What's Up With Site Isolation]: https://www.youtube.com/watch?v=OH-bt7spDgo
|
||||
[bit.ly/blink-compat]: https://bit.ly/blink-compat
|
||||
[chromestatus.com]: https://chromestatus.com/
|
Reference in New Issue
Block a user