CHRIS WILSON: Good afternoon.
I'm here to talk about
the history of the web,
from its humble beginnings
in the early 1990s
through the high and low points
in the browser wars to today.
And a lot of this talk, for
me personally, is nostalgia.
I hope there's a lot of--
see what impact history had
on today's web.
As George Santayana said, those
who cannot remember the past
are condemned to repeat it.
Let's definitely not do that.
I'm going to talk a lot about
Internet Explorer's history.
You'll find out why in a second.
But I still believe
a lot of this
drove getting us
where we are today.
But much like Mel Brooks'
movie, I have to skip a lot.
So the first deck I pulled
together for today I think
was about an hour and half long.
Hopefully I'll make it
through and land on time.
So hi.
I'm Chris Wilson.
I've been working on the web
platform a super long time.
I started over 26 years ago.
I co-wrote the Windows
version of NCSA Mosaic,
the first real
mass market browser
after Tim Berners Lee's browser.
I've been an engineer,
a PM, a lead PM, a GPM,
developer advocate.
I'm currently on the
TPGM team in Chrome.
I've worked on four
different browsers, I think,
and I've been a
Googler since 2010.
By the way, that's
since Chrome version 6.
Chrome version 6 shipped
a week after I started.
Don't take this the wrong way.
That sounds super impressive.
I don't think I'm the
smartest person in the room,
certainly not in this room.
I have been in the
room where it happened,
to borrow a Hamilton quote
for a second, many, many times
over the years,
which is pretty cool.
But-- so I want you to
all cast your minds back,
for some of you, before
you were born, to 1988.
1988 is when I went to
the University of Illinois
as an undergraduate.
And to give you a picture
of the internet at the time,
this chart is great.
You can't really
read the labels,
but 1988 it is here, basically.
And you'll note it
almost doesn't exist.
No one had really heard of
the internet at that point.
In fact, it was
still commonly known
as ARPANET in academic circles.
And my incoming
undergraduate class
was not issued email
accounts by default.
You actually had to go
to the computer lab,
ask for one in-person.
And, in fact, we logged
into our mainframe.
Like, people didn't usually
have the ability to connect.
And you had a time
limit of seven hours
a week on this mainframe system.
And I would usually
burn this up playing
Ultimate Larn, because
you only had seven hours.
I'd usually burn it up
in the first couple days,
and then I couldn't check
my email again till Saturday
morning.
Thankfully, engineering
students got a second account
that was not time restricted
on a different mainframe.
So clearly, I did pass my
computer science classes.
This was my first
internet terminal.
It was a cast off
terminal from a job
that I was working
at over the summer.
It was an HP 2622A terminal.
It had an integrated
thermal printer in the top.
It was awesome.
I connected this
to the University
of Illinois' system
via a smoking fast,
for the time, 2,400 baud modem.
For reference, I calculated
my cell phone gets something
like 6,000 times faster
connection overall LT,
and a 60,000 times
faster connection
when I'm on Wi-Fi at home.
Or it's about twice the
speed of my hotel Wi-Fi here
in Mountain View.
But this was just
a text terminal.
Like, the internet
was mostly text.
In fact, that's one of
the points I made here is,
it really was email, it
was was Usenet, it was IRC,
it was Gopher.
FTP was cool too, but
frankly, used a lot less,
except for sharing software.
Now don't worry.
My entire presentation is not
just Douglas Adams quotes.
There are a couple
more, I think.
But this is really--
this is something
to remember all the time.
Anything that's in the
world when you're born
or when you're very
young it's just normal.
It's the way the world works.
I have two daughters.
The internet is the
way the world works.
They don't even think about it.
Mobile devices?
Absolutely.
Anything that's invented
between when you're 15 and 35
is new, exciting, and you can
probably get a career in it.
And the internet, the
web, was definitely
invented between
when I was 15 and 35.
Now, I'm not really here
to say, get off my lawn
you young whippersnappers.
The web's been done.
Everything you can come up with
is against the natural order
of things.
The challenge is, really, how
do you take it and make it
so that you can adapt to
the natural order of things.
Think of what it can
become in the future.
Because otherwise, I turned
35 before Chrome was released,
so that would be a problem.
In 1991, I got a
part time job working
at the National Center for
Supercomputing Applications.
It's the last time I'm
going to spell that out.
The NCSA is one of the five
original NSF supercomputing
centers, and our group's
mission inside NCSA
was to build software
tools to enable researchers
to use the power of
the supercomputers
on their desktop.
So we did Telnet.
We literally built Telnet.
In fact, that's what I was hired
to do, work on the terminal.
Now keep in mind, this
was before Windows 95.
This was before Windows 95.
There was no TCP/IP
network stack.
PC Telnet was DOS software.
We had to eventually
build Windows software.
We also did visualization
tools and things like that.
Data loading and formatting
tools, that kind of thing.
But this fit right in when
we had this project come up,
where a couple guys came up
with this X Windows software,
called Mosaic, that let
you access this thing
that some guy in
Switzerland had come up
with called the worldwide web.
Used a prototype document
language called HTML.
That was kind of--
well, that was the
next 26 years my life.
I co-wrote the Windows
version of this.
Incidentally, NCSA Mosaic
had three versions, Mac, PC,
Windows, and X Windows.
They were totally different.
They did not share code at all.
We looked at each other's code,
but cross platform software,
not really a thing.
I also, this utterly ruined
the word mosaic for me.
If you say the word
mosaic, I will not
think of a piece of art.
But keep in mind,
again, we didn't have
network support in Windows.
Windows didn't have a
built in network driver.
Like, they didn't have sockets.
You could buy a separate
package that would add it.
Even Windows 3.11,
with networking,
I can't remember the toll name.
Windows for Work
Groups, I think.
It didn't have ti
TCP/IP built in.
Didn't have sockets.
It had networking, but through
Novell or something else.
So we already had our
own network stack.
We actually literally
wrote the device drivers
for network cards.
Like, I would debug this stuff.
I debugged the TCP/IP fallback
algorithm at one point.
And so we got that
working in Windows.
We built the HTML
parsing and rendering
stuff, all that kind of thing.
And NCSA had this tradition
of shipping lots and lots
of beta releases.
Like, basically, build it on
your machine, put up a release.
I think I actually put up
several debug version releases,
because I couldn't find a
bug once that turned out
to be a pointer
initialization, of course.
But we put Windows Mosaic
up on the FTP server
for the first time.
And I remember, we
got super excited,
because a week later, we
were at 1,000 downloads.
Now, I gave this
talk I think in 2011,
and I calculated
like, how long it
took Firefox to get
1,000 downloads,
and it was measured in
fractions of a second.
So a little different scale.
But still, what was
really surprising was,
the game DOOM came
out the same year,
and we still managed to
get work done on Mosaic,
because we were college kids.
I mean, we were students.
NCSA had this great
overall charter of hey,
go enable education
and research.
And we got to explore
a lot of things.
And if we didn't
have that there,
we wouldn't have gotten
to go build a web browser.
It wasn't in our software tool
group's charter at the time.
We were chartered to build image
visualization tools, Telnet,
et cetera.
And this is one of the
things, one of the parallels
that I draw with
Google, because Google
has a lot of that flexibility.
It's one thing that I really
like about working here.
Now, but overall, like, we made
a bunch of foolish mistakes
in Mosaic, because we didn't
really know what we were doing.
We didn't really have
a whole lot of support.
We didn't have a business plan.
I mean, plenty of dotcoms
didn't have business plans too,
but we didn't
really, like, there
was no user experience class
in my computer science degree.
There was no theory of software
testing or anything like that.
And we didn't even have
revision control systems.
Like, there were two of us
working on Windows Mosaic.
We didn't have network drives.
So literally, we would
like, work on the same code,
we'd save it to a zip disk,
walk across the office,
stick it in the other guy's
drive, copy the right files,
hope for the best.
So we did make some
foolish choices.
And one in particular that
I personally own is this.
I'm personally responsible
for overlapping bold
and italic tags working
in the early web.
For some reason, I thought
this would be cool.
The rampant violation
of all common sense
and SGML-structured
document decency.
And by the way, yes, we do
still support this in Chrome
and every other
browser, probably.
We do it in an interesting way
that doesn't violate everything
that's decent.
But in my defense,
such as it is,
I thought it would
be cool at the time.
But the early web, even
the really early web,
because remember, I'm
in like, '93 ish year.
It was really compelling.
And the reason it was compelling
was that you got access
to all this information.
I mean, Google's
mission is organize
the world's information
and make it universally
accessible and useful.
And I was the one chatting
in the back when Parisa
asked this question
earlier, because it's
in my deck a couple times.
And you have to remember,
at this day and age,
the world's information
wasn't on the internet.
The internet was
like, we were off
at the low part of
that ramp, right?
A lot of that information
wasn't even in digital form yet.
Like, you had to go to a
library to get information.
Now, eventually,
of course, like,
anybody who's watched a
bunch of information before
and knows how we tend to
think of the web platform,
you'll recognize part of
this LICE acronym here.
But at this point, it
wasn't indexable, really.
Or it was indexable, but
there were no indices to it.
In fact, I meant to bring
along, on my bookshelf,
I have this book.
Like, a bound paper
book, that is literally
lists of URLs and
descriptions of them.
It was published,
I think, in '93.
'93 or '94, I can't
remember which.
And it's just a solid
book filled with, hey,
this is what you can find on
the Honolulu Community College
Website or the like.
So most critically,
at NCSA we had
this-- we recognized that the
coolest thing about this web
thing was that everyone could
be an author, because most
of the systems out there
weren't really designed
for anybody to put servers
up and share information.
Gopher in particular.
Like, Gopher clients
were easily accessible.
Gopher server software you had
to pay an arm and a leg for.
Like, basically
only universities
ran it or private
enterprises, because it was so
expensive to run the software.
Now, so we actually
implemented a bunch of stuff
at NCSA to try to encourage
this sharing of information.
We actually had, even in
1993, we implemented a group
annotation feature.
Like, you could annotate
web pages, and then anybody
in your group who shared
the same annotation server,
they would see your
annotations when they
went to the same web pages.
We also had this idea that
the web server software should
be free, and everyone should
run a server on their machine.
Now, putting this
in context, this
was several generations of
massive security problems
away from where we are today.
We actually, I ran a web server
on my PC in my office at NCSA.
It was world accessible.
I mean, literally anybody could
just FTP into my personal.
In fact, we wrote a networked
space dogfighting game.
Me and a group of my
friends at the University,
we borrowed the NCSA PC
Telnet code to do this.
And after we'd been playing it,
like, we got it up and running.
It was like, awesome.
Those early LAN parties.
It was great.
After we had it up and
running for a while,
I realized that I never disabled
the FTP server in the PC Telnet
code.
So sure enough, I could like,
FTP into my friends' machine
while he was playing
the game and, you know,
start a big download.
He didn't really like that.
But the cool thing was there
was lots of wacky content.
Like, this was
groundbreaking at the time,
because you didn't have
access to this content.
Like, there was a guy named
Kevin Hughes from the Honolulu
Community College who, they
have a really cool dinosaur
museum at this community
college in Honolulu.
And so he thought,
oh, this is awesome.
I'll take some pictures of
it with my digital camera
and put it online.
And he did.
And there was like,
you would just
get this weird kind of stuff.
And this is, more
than anything, I
think what contributed
to the growth of the web
was this concept
of the long tail.
Who has not heard of
the long tail before?
Just to-- OK, so there's
a few, which is good.
This is where the large
portion of content out there--
the overall population
is in this tail.
And unfortunately, the
colors are messed up.
But like, all of this stuff
out here, measured by interest,
is just as popular as
the most popular things.
So another way to look at this
is, the web is incredible,
because people get super
interested in uncommon topics,
more so, even, sometimes, then
Taylor Swift's latest video.
Which is great, by the way.
This is taken for granted today.
Like, this is one
of those things
where you're nodding your head
and saying, yeah, whatever.
This was new back then,
because you couldn't really
get access to the long
tail, not in the early '90s.
In fact, in the early
'90s, or mid '90s,
actually, in 1996, I
took a class learning
to play the didgeridoo.
Part of the class
was how to build one.
I was like, oh,
this is really cool,
and I put up a web page, how
to build a bamboo didgeridoo.
It's pretty easy, by the way.
You just poke a hole
in it more or less.
But how many of you
remember GeoCities?
Right on.
Nostalgia buffs, I love it.
I put up a GeoCities site
on how to build didgeridoos
from pieces of bamboo,
complete with ASCII art,
because I didn't own
a digital camera yet.
This was seven years before
Canon came out with the Digital
Rebel, just for reference.
So it really wasn't
that popular,
and I put my Microsoft
email address on it.
And yes, that seems like a crazy
thing to do today, but I did.
And this page stayed up until
GeoCities shut down in 2009.
And that entire time, for 13
years, at least once a month,
I would get an email from
somebody saying, hey,
this is great.
I was wondering if you know
where to get raw bamboo here
in Finland.
By the way, this page
is still accessible.
If you really want
to see it, the URL
is in the speaker
notes for this page,
but I'm not going
to go to it now,
because I'm a little ashamed
of the artwork there.
But I tell this
story not because I
think you're all interested in
building bamboo didgeridoos,
although I'm happy
to talk about that.
Even fewer of you are actually
interested in the finer grained
details of where to get raw
bamboo here in California.
I do know, because I did
live here for a little while.
But you probably
have some interests
that are just as uncommon.
In fact, by contrast,
for the last few years,
I started making ukuleles
in my spare time.
And I buy my materials
and my tools online.
I watch videos on
YouTube of how to bend
the sides right or that thing.
I compare notes on forums
about different wood choices,
et cetera, browse through
exotic woods on eBay.
This is a thing.
Like, I would search
ukulele wood on eBay.
And it's not like, five pages.
There's like,
hundreds of results.
And I'm showing my age
because I find this amazing.
Like, this is blowing,
the access to information
that you have.
This is a massively
new natural order.
And this leads me to
something that I've
said for decades
about my career,
is that the web and
the internet just
helps human interactions
happen faster, and fewer
guardrails, fewer
speed bumps in the way.
I used to think,
by the way, this
was an unreservedly good thing.
I don't think that anymore.
So this is kind
of foreshadowing,
be careful about how you
enable human interactions.
But it does definitely
remove geographic barriers
and information barriers.
So anyhow, back in 1994,
the core Mosaic team
all pretty much left NCSA
nearly at the same time.
Mark Andreessen had
left the previous year.
I quit and headed out to
Seattle to take a different job.
And then Mark came
back with Jim Clark,
scooped up the rest of
the engineering team,
before they could leave
and go off to the winds
because they saw that I was
the first one that left,
but I was not going
to be the last.
But I went to this
company called SPRY.
They built a product
called Internet in a Box.
I literally had one of
these on my bookshelf too.
Yes, the entire
internet in a box.
But it was kind of
cool, because this
was the whole package
for what you needed
to connect to the internet.
Which, again, at the
time, was pretty cool.
It had a Usenet browser.
It had an email system.
And had a Gopher client.
It also had a web browser.
And it still wasn't
clear that the web
was the winner, by the way.
It had all these.
Like, when I was building this
talk, and I like, you know,
did the Command tab
on my Mac, and it's
like, literally the
only things running
are two copies of the
browser and the calculator.
And that's just because it was
easier to get to the calculator
by clicking the icon.
Now, I don't want to talk
a whole lot about SPRY
in particular, because they
went away for good reason.
Although it's not
Spyglass, by the way.
Spyglass was a totally
different company.
And in fact, a year
later I left SPRY
and I joined Microsoft and
the Internet Explorer team.
Spyglass was
actually this company
that NCSA licensed
their code to,
because they realized that the
business of software licensing
was not really the business
NCSA wanted to be in.
And then Spyglass resold
it to everyone else,
and Microsoft actually
licensed it from spyglass.
And Spyglass said they rewrote
all the code from the ground
up.
I'm just saying a lot of that
code looked really familiar,
and a lot of it, the
architectural choices--
yeah, it had some of the
same idiosyncrasies as code
that I had written.
Not that I was proud of,
necessarily, but was the same.
But I joined the IE
team right before we
shipped IE 2.0, for context.
And I'm sure a few
of you have probably
heard this quote before.
Mark Andreessen was
quoted as saying,
Netscape will reduce Windows to
a set of poorly debugged device
drivers.
Now, in his defense, by
the way, Mark actually
said that Bob Metcalf said this,
and he was just retweeting it.
Well, quoting it, because
JavaScript wasn't around.
Twitter wasn't around.
This may seem like a cheap
shot against Microsoft.
It actually isn't, because
I didn't believe it then.
I continued to work for
Microsoft for 15 years.
I don't even believe it now,
because those device drivers
are really well
debugged at this point.
But I don't think any of us
expected what this statement
kind of foreshadows,
that the world is just
going to become
the web platform,
and software sitting
on top of it,
not a whole bunch of software
sitting on top of Windows.
And this really did kick
off the browser wars.
And my favorite example of the
hideousness of the browser wars
was the blink tag.
And how many people have
heard the tale of how
the blink tag was invented?
Wow, OK.
So this one was pretty good.
I was not in the
middle of this one.
I was not in the room
where this one happened.
The blink tag was created
because some Netscape engineers
went out drinking one night.
I'm not kidding.
It's on Wikipedia.
Look it up.
And one of them,
or more of them,
were like, oh man, we
should make a tag that
makes everything blink.
And they were out
drinking, so one of them
decides to go back to the
office, and the next morning,
shows their coworkers
the blink tag.
Now, at Microsoft, we
hated the blank tag.
We were like, oh my god,
why would you make the--
why would you do this?
It's like you're going
to, I don't know,
trigger people who are
sensitive to blinking
lights or something.
This is horrible.
In fact, when the
Netscape team demanded
that CSS include text
decoration blink, I said fine.
We'll parse it.
We'll apply it, but
we can't be forced
to make it actually blink.
It was in the CSS1
spec, at least.
You're not actually required to
visually make the thing blink.
Now, we still had to
out blink them though,
and that's what the
marquee tag was about.
In the marquee tag, just
search for marquee tag
in Google search.
It's actually awesome, because
it has now my favorite Easter
egg in Google search,
because it actually
replicates a marquee tag.
Like, the tag results start
scrolling back and forth.
And that's basically
what marquee did.
It scrolled text back and forth.
The joke actually ended up
being on us on the IE team,
because we also made it scroll
vertically and stack text
vertically.
Like a marquee, you
know, when you walk down
Times Square or something
and there's vertical text.
And apparently, this was
really popular in Korea,
because it matched how
their text and fonts worked
at the time, and it was useful
in developing Korean text.
And we literally couldn't
remove it for like, decade,
more than a decade
afterward, because it
was so heavily in
use and we would
have broken a lot of content.
Now, in 1996 is when we
shipped IE 3, so this
is kind of the era we're in.
And around this time, it's
important to understand,
IE, actually, would
dynamically lay out pages.
Like, if you resize the window,
it would just re lay it out.
That's actually how I wrote
the original rendering layout
system in NCSA Mosaic.
This is also, by the
way, the idiosyncrasy
I was talking about earlier, was
I would break up runs of text.
As you narrowed the window,
it would have to break it up
at different places,
and it-- like,
the runs would never recombine.
They would just stack.
So like, if you stretched it--
if you squeezed the
window all the way down,
it would take up
slightly more memory
and have more runs in
the overall system.
They have the same thing.
Now, Netscape Navigator, by the
other way, on the other hand,
when you resize the window, it
would literally reload the page
from the network.
Not even from disk.
Like, disk caching
was only going
to start being a thing
in a year or two.
So they would literally
go reload the page.
And in fact, if you had
form fields on the page,
and maybe you realized that
you couldn't see one of them,
and you'd resize the window,
it would reload the page
and lose everything.
They started caching
things across page loads
for exactly that reason.
But we did this kind of
feature for feature comparison,
but it started being more
clear that they had--
they were going for cheaper
features than we were.
We did do a feature for feature
in JavaScript, on tables,
on font tags.
I am actually the person
who implemented CSS first
in a browser.
This was because my boss
actually came into my office
and said, hey, we're planning
out features for IE 3.
We want you to work
on frames, because we
didn't do frames yet, iframes,
frame sets, et cetera.
And I was like, hey,
that would be cool.
But there's this
thing called CSS.
Netscape's not even
looking at this yet.
It would be super cool.
You can do all this
neat visual stuff.
And he was like, oh,
let me think about it.
Came back in 1/2 hour and
said, yeah, go do that.
And that was how we
got CSS in a browser.
I mentioned earlier about
coding, coding quality,
let's say, software systems.
And at this point, we did at
least have revision control.
Like, we had network drives.
But in the IE 3 days, our
revision control system
didn't work so well if
multiple people tried
to check in at the same
time, because we frequently
were checking in
many different files.
And we had what we referred
to as the check in bear.
This is literally a
physical Teddy bear.
It sat in a hallway
next to a whiteboard.
And if you needed to check in,
and you had to go get the bear,
write your name on the
board, take the bear,
the bear had to sit on your
desk while you were checking in,
and then you went back,
and if someone else
had written their
name below yours,
you went and gave
it to them instead.
It was an interesting
semaphore, I guess.
But after we shipped IE 3, we
started looking ahead to IE 4.
And at Microsoft,
with IE 4, we actually
built an entirely new
engine, the Trident engine,
what became known as
the Trident engine.
And I found out about
this the first time
when we were invited to a talk
by this group called the Forums
Cube Team.
No idea what that came from.
And there were rumors that
they were building something,
and I didn't have
a chance to go.
I was busy doing something.
But the other guy who worked on
the rendering engine, my friend
Jeff, he went.
And he comes back.
He comes into my office and
he's really, really down.
I'm like, how did it go?
And he's like, we're screwed.
They can do everything.
They can edit.
They can change things.
Like, it's a completely
live dynamic environment.
We're out of a job.
And he was half right, because
I had done style sheets.
And I gave a talk
to the Trident team
like, a week later, where I
was showing off all the stuff
I'd done on style sheets.
And I was like, does
this, does this.
I'm hoping to get in these
two features before we ship.
Now literally, someone in the
audience said, could you not,
because anything you ship, we
have to be compatible with.
Now, just for that,
it's three features.
And so they asked me to
move over to the IE 4 team,
work on style sheets.
And when I was asked to
join, that I was told
I would be in the
object model team.
And I'm like, what?
The JavaScript team?
You asked me to do style sheets.
But this was kind of the
key thing about this era,
was everything became
dynamically programmable.
Before that, in IE
3, up through IE 3,
and still in Netscape Navigator,
all you could reprogram
were images.
Not the size, because you
couldn't change the layout,
but you could swap
the visual out,
the links that a particular
hyperlink would point to,
an input fields.
Nothing else.
Nothing that changed the
layout of the document.
And the only way you
could change visuals
was input fields and images.
And suddenly, you
could redo everything.
I mean, you could
change inner HTML
and put a whole new
document in there.
You could change things in
the document object model.
There were a couple things you
couldn't change dynamically.
There's a whole 45 plus minute
talk about hasLayout here
that I'm just going
to skip right past,
other than to say it
really wasn't my fault.
People do say that sometimes.
It wasn't.
And it was super
important to understand
that Netscape Navigator
didn't have a dynamic system.
They couldn't change all
the stuff dynamically,
like, their new system, what
became Mozilla, was delayed.
To combat this, instead
of changing everything
live through the
object model, they
proposed, hey, we should
have a new tag called Layer.
And you can put things
that change inside a layer.
But that whole CSS positioning
thing, let's not do that.
We were like, no, I think
we're going to do that.
There was a lot of
jockeying back and forth.
And I think this all culminated
when we shipped ActiveDesktop
in Windows 98.
And this was because
you can suddenly
drop web content
onto the desktop,
and all of the window
decoration there was actually
done in web content.
This was horrifying
to those of us
who really knew
what was going on,
because it was a very heavy
weight system being dropped in
to do a very low level system.
But this was also when the
dawn of Ajax happened, right?
This was, Alex Hauptmann, a
guy I later worked with in IE,
they needed a data transfer
system for Outlook Web Access.
So they came up with this
control, shipped it in MSXML,
and this shipped in
the IE 5 time frame.
I'm not sure which
of the IE 5 releases,
because literally we had IE
5.0, 5.01, 5.01A, 5.01B, 5.01C,
and 5.01D.
We were trying to shift
together with Office.
It took a few tries.
And after that, we kind
of stumbled at Microsoft.
We were largely just
re-architecting.
Like, IE 5.5 to this
native frames thing.
And IE 6 fixed all the
things we broke in IE 5.5.
And that was about it.
Really.
Like, we didn't really
know what to do.
And a lot of it is
because of this chart.
And this is browser adoption,
during this time period.
And you'll notice there's
a nice peak up there,
and most people don't
do well at peaks.
Particularly Microsoft
doesn't, but most people
don't do well in peaks.
But as we shipped IE 6,
we were right about here.
We had the best
browser on the planet.
I mean, we were much better
than Netscape Navigator in my,
admittedly, somewhat
biased opinion.
Our Mac product
was actually better
than our Windows product.
Or Mac team is
applauding somewhere
and they don't even know why.
But the web didn't
actually have rich layout.
It did great on flow text.
It did great on tables.
But it didn't do stacking
and it didn't do grids
at the time, which
was kind of bad.
Compatibility was becoming
a real problem for us,
particularly because Microsoft
had this really, really
hardcore compatibility
philosophy.
I remember having to ask for
approval to break something
to fix our standard support,
but it would break something
in the Help pages for Microsoft
Cart Precision Racing, a game
that we had shipped like,
three years before that.
And overall, like, the web
didn't lead developers back
to Windows, and Microsoft
started questioning,
why are we doing all
this for something that
doesn't get us more developers.
And we already
have all the users,
so why do we need to do this.
They just wanted to retain
the developer market.
So we created this
Avalon project, which
became dotnet framework 3.0.
And I'm not-- there's at
least another 45 minute talk
in there.
And of course,
this just ended up
in them losing that market
too, and then declining it.
And of course, at the
same time, the world
just kept going, right?
This pattern of mashup apps
became more and more important.
I wrote this white paper
internally about mashups.
And this is basically
multiple components and data
started coming together.
Again, this seems natural today.
But the idea that you
had the same system that
had Chicago crime statistics
and mapping software,
and that you could just get them
to work together dynamically,
that was pretty
awesome at the time.
And, of course, WebKit
started gaining traction.
Firefox was gaining traction.
And the WHATWG was
formed around here too,
because the W3C kind
of lost its way.
There are several hours
worth of talks there.
And in 2004, Microsoft
finally woke up, said,
oh, wait a second.
We need to do something here.
And this was
actually the release
that I was most
proud of personally.
Not because of what
we actually shipped,
but because we had
to build a team
from basically ground zero.
And the unfortunate
part is, you read--
this is out of the
Wikipedia page on IE 7,
and it kind of says,
new features, including,
tab browsing and page zooming,
integrated search box, a feed
reader.
And oh, yeah, web standard
support got a little better,
but it deal doesn't
pass the basic tests.
And that-- we had to get used
to being vilified at this stage.
I did actually have someone in
blog comments, posing as Satan,
offer me a job at that point.
Asked how much I made
and if I wanted a job.
And I was kind of worried,
so I didn't delete the post,
because you never know.
But don't read the
YouTube comments.
Don't pay too much
attention to people.
And I'd point out
that, only now are
we getting into the period
of time where Chrome began.
So I'm not actually going
to cover any of that,
because Peter will do a much
better job than I would.
But I will say, Microsoft
continued to kind of invest
the minimum into the platform.
Not the browser,
but the platform.
And that didn't work
so well for them.
And a lot of this
led me to the lessons
that I learned out
of the IE experience.
Don't become complacent
just because you're
at the top of that heap,
and Chrome can definitely
learn something there.
Don't focus on the competition
was a huge part of it.
That works OK when there's
only two of you, not so well
when it's a lot of different
people and a lot of things.
We're actually pretty good
at not doing quirky stuff.
We try to pay attention.
We try to build
lots of test pages
and make sure that
we're following a spec.
But more than anything,
not all the smart people
work at your company.
And, of course, don't
ignore disruptive factors
like the mobile revolution,
which came along right
about this time too, right?
And this caused us some
challenges on Chrome as well.
But this was a huge deal, right?
Like, I went in 12 years
from having this Motorola
Startac, which I promise you
was super sexy when it came out.
It was the best phone out there.
I loved that phone.
Right up until the
point it dropped it
into Lake Washington,
to having an iPhone.
Right?
And the iPhone, it
had all these sensors,
and the touch screen was super
engaging, and just so much
power in it.
And, by the way, I was over 35
when the iPhone was released.
But I still managed to adapt,
because I remember saying two
years later, yeah, baseline.
My cell phone has to take the
place of my guitar tuner now.
Like, it just has to work.
I'm not carrying a guitar
tuner around anymore.
I had a guitar in my office,
and I'm pitch sensitive enough
that I wanted it to work.
And unfortunately, the web
wasn't just the mobile platform
at that point.
It would have been great,
but frankly, at that stage,
the web was still
designed for 1,024 by 768.
Literally, it was hard
coded in web pages.
When Apple came up with their
somewhat wacky rules about how
to remap onto their device,
they were depending on this.
And they weren't
wrong, really, to make
most pages look correct.
But it wasn't really open
to doing touch input.
Occasionally you
needed a keyboard,
and the network was
still pretty spotty.
Like, people weren't
expecting this.
And it's super important.
This is actually from
around that time period too.
Ben Galbraith, well before
he worked at Google,
he said this at a conference.
And he said, web 2.0 isn't
about a set of technologies.
It's about caring about
your user experience,
and this was the
big evolution then,
was people started really caring
about their experiences offered
in a browser.
And prior to that,
they really weren't.
Post that, we actually
had yet another version
of that when we had to bring
out the Progressive Web App
banner a couple of years
ago, where we really
had to focus on the fact that
bandwidth was still required.
Like, it didn't-- the web didn't
work well if you didn't know
you had a connection.
And I've given many
talks about that.
But at this point, the
things that I want everyone
to focus on is, a
big reason that I'm
convinced the web platform is
still that universal platform,
is that those access to
capabilities is catching up.
We just have to be super careful
about security and privacy
and the user experience.
And, more than anything,
how that platform
works on other devices.
This is also one of the
traps that Microsoft fell in.
Because even when Microsoft had
two browser teams, a Mac team
and a Windows team, the Mac
team was off in a corner
by themselves.
They weren't integrated.
They weren't thinking about it.
And, like I co-chair of the
immersive web working group.
We have to think about
Magic Leap's AR Headset
and how WebXR works on
it, even though Google
is, not currently
to my knowledge,
building an AR headset.
So it's kind of important.
Guidance for that, really,
this is Google 101, right?
Respect the user,
respect the platform,
respect the community.
Don't be the smartest
person in the room.
For any of you working
in standard stuff,
be the best listener.
That's a much better
way to take that on.
As Parisa mentioned
earlier today,
this is our mission
on the Chrome team.
And this, by the
way, overall, this
is what brought me to Google.
Like, this is a strong
part of Google's DNA.
It's a strong part of
the Chrome team's DNA.
This is exactly why
I stay here as well.
And with that, I think I'm
going to close with my final two
Douglas Adams quotes.
Thank you.
[MUSIC PLAYING]
