The Web Platform and The Process of Progress by Alex Russell
Thanks, Christian. By the way, I know we're at the end of two very stimulating days, but Christian has done a fantastic job. Does everyone agree, yes? All right. [applause]
As Christian alluded, I was asked to speak, and I was as shocked as anyone when they said, "You're going to be the last slot." Who was here last year? All right, so you kind of know what I do, and generally, it's not positive. It's not inspirational. I tell you why things are broken, and oh my goodness, [indecipherable 00:48] , and actually, that's what I'm going to do today. I'm here to depress you just a little bit.
But it's all planned. I decided to do this intentionally. I'll lift you back out of the pit of despair, hopefully, but you need to come with me into understanding why it is things aren't as good as they should be. There are two parts to this. One of them is, they're not as good as they should be. The world could be better. The other part of it is, how do we make it better?
We can think about making progress in a platform as a path, and it could be a random walk. It could just be things happening, and you're sort of subject to them, or it could be directed walk. There might be a destination.The question, I think, that's in front of us now is, "What ability do we have as web developers?" As people who are engaged, maybe, on an occasional basis, you talk to Anne van Kesteren
in a bar, or you talk to me someplace, and you're like, "How can we make this better?" Because some things are still definitely painful.
I spend a lot of time thinking and writing about the process of making it better. What is it that you can do that is most effective at every point to make something better? The first thing to recognize is that progress, which is what we want, is a man-made process. There is no event in human history which has yielded a better state for the people you love and care about, yourself, the people around you, your family, that has probably been only a natural event.
"Yes, the ice age ended." Well, that happens on a time scale you don't care about. "The crops were good this year." Well, you planted the crops in the first place. There's something about this which is always relative to a human viewpoint. It's always about, "Is it good for a human?" and it's always about something that we do for, with, and to each other.
Progress. The set of things that are better are better in relationship to us, and the way we make them better is something that we do. It's not something that happens to us. There are environmental factors, but collectively, we make what we make, and it can be better.
But the fundamental predicate, the thing that must come before you have any progress, before you can make anything better, is that you must make something different. If you would like something to be better by a large amount, it must be different by at least that much.
There's probably going to be something that's also worse. Change isn't always good. I like to say that change is a vector; It has both magnitude and direction. When people talk about change as though it is a good thing, I get a little bit skittish. I don't really necessarily agree. I think change can often be a bad thing, but it's only when things are changing that things have the potential at all to ever get better.
We need to wrap our mind around the idea that progress is man-made so we, us, we make progress, or we don't, and it's relative to what we want. Progress is not a value-free system. It must require that we think that something is better or worse for us. It requires our value system be applied to a set of events. So our values matter, it's about something we do, and it can be good or bad.
We can change things for the better, or we can change things for the worse, so we have a responsibility, then, to think about how much change can we make. How much change are we allowed to make? What changes should we make? Who are they going to be bettering? Who are they worse for? There's almost a moral aspect of this, but I won't get too far into it.
This is Thomas Kuhn, a philosopher of science who wrote a book called "The Structure of Scientific Revolutions" in 1962. This is the book for which you can curse/thank for the phrase "paradigm shift." It wasn't his fault. It's not his fault that he had a good idea, but he has a divergent theory of progress, specifically in science, which up until then had been viewed as a linear set of things getting better, things just get better.
But there's also some tension in that. You also recognize that things don't get better just little bit by little bit. Sometimes they make big changes, they jump a lot. So he spent a lot of time thinking about, writing about, the set of times when you don't move a little bit, you move a lot of the time. It's a big discontinuity. You make a large jump all at once.
In reality, that's not actually what happens, and he talks a lot about how in order to make a very large change, and a very large apparent change, there has to be this buildup of evidence that the current world isn't working. It's not right. Something about the way we understand or explain things isn't as solid as we once thought it was, and that's the landscape on which you can make a revolutionary change.
But there are times in the world where there's normal progress and there's revolutionary progression. It's worth thinking about the times in our past, in the browser world, when we've had normal progression versus revolutionary progression.
So I always go back to the late '90s. The late '90s were absolutely revolutionary for us. Obviously, it gave many of us jobs, for one. That was good, I think. I don't know if you're here at gunpoint, but if you're not, the late '90s were probably a big part of that, because we had multiple competitors trying to build a platform together and in opposition, all at once.
And they were delivering new features every year-every six months, every year. New things were getting out there. And not only were they getting out into the world, they were getting out into users' machines in a way that you could start to count on. And of course we had all sorts of predictable problems that came along with that. With great change comes a lot of uncertainty.
"Oh, I just upgraded for IE4. What am I going to do when the 5.0 browsers come out?" "Oh, the 5.0 browsers are here. What about the 6.0 browsers? Everything's going to break. It's terrible. Slow everything down." This was what we all were saying. There was a lot of, "Uh, this is terrible. There's too much change. It's too future-y." And so we settled into a normalcy, specifically when IE6 won.
But we've sort of come to expect that there's going to be this slow progression from now on. And I think that's not necessarily how we should think about the world potentially improving. I think our world has mounting evidence that the way we're approaching the task of web development is based on a whole series of flawed assumptions about the world around us, and it's about time for us, collectively, to break out of them. So I want to run you through a couple of thought experiments.
Progress is man-made. What are the dials of change? Where are the places that we can slow things up? Speed things up, slow them down. (Slow things up, yes. Let's not do that.) So let's walk through these things one at a time. What if there was only one browser? Just clear stop. Just whatever you're thinking right now, stop. What if there was only one browser? Brand X makes the browser. It could be Microsoft, it could be Apple, who cares? There is one browser in the world.
What happens now? Right now, is that good? On your next project, is that a good thing? Do you feel uncomfortable about that idea? Does it make you go, "Yes, it might be really good. I don't have to worry about any of this compatibility stuff. But is it going to get better?" You might have that tinge in the back of your head. You might be saying to yourself, "Well, if there's only one browser, then how do we get our issues or needs solved?"
What if the company that makes it or the organization that makes it doesn't share my goals? How do we ensure that there's a new version of that browser? That's interesting. And what if browsers still cost money? This is an interesting friction point. So if we look back at the course of web browser evolution, there was a time, I don't know if you remember it, but web browsers cost money.
In the United States, there was a company, still is, called Best Buy, big box electronics retailer. And you could go into Best Buy and get a shrink-wrapped disk or CD with Netscape on it. And you could pay them money, and maybe you would buy Internet service, a dial-up Internet service, and you would get the CD for free, so you would get Netscape Navigator 3.2 Gold as part of your service. You might remember this if you're as old as I am.
So what if browsers still cost money? What if Microsoft hadn't walked into this and said, "Oh my goodness, someone's building a platform around us. We will no longer be the ones to build a platform. We should set the price of the browser to zero. It should become a feature of Windows." That's what happened. What if that hadn't happened? What if there's an alternate future when people are still paying for browsers? Would they be better? Would they be worse? Would that be better or worse for us as developers?
OK. What if everyone had the latest version of the best browsers immediately-right now, right this instant? You wake up tomorrow morning, and all of the legacy browsers in the world are gone. Is that good? OK. Why is that good? Why is that good? Is it good for users? Probably. But it's good for you, specifically, right? There's a little bit of separation anxiety in this thought experiment, right? If you've spent as many years as I have thinking and knowing about parts of IE that no one should ever have to care about, or Netscape four back in the day. If you've been cobbling together these little bits of hack to go build a coherent platform out of it, you might feel as though someone's on your turf.
But if everyone had the latest version of the best browser right now, would that be better or worse for us collectively, and what would it change about the way you approach your next project?
Last thought experiment. What if everyone had that happen to them, you wake up tomorrow, everyone's got the best version of the best browser, or the latest version of whatever browser they've got, but there's no auto update, ever?
Every time we release a browser, we go around and maybe we prompt users to upgrade, or we do it in an advertising campaign, or whatever it is. We come up with some way to get the word out, and users can go and download the next version of the browser. Is that better or worse than where we are today?
Now, we're starting to see the axis, the set of levers that we've got, or that have been turned for us, in many cases, by different people over time, that have accelerated and decelerated the process of progress. Progress is man-made, and it's a process whose velocity we can change. It's something that we can have something to say about.
This rang true for me earlier this year at Front-Trends, where Rachel Andrew was giving a talk about the craft, effectively, of putting together websites, modern websites, modern UI. The thesis of her talk, and I hope not to misrepresent it, but basically what she was saying, if I can paraphrase, was that you should only lean on tools, or techniques, or polyfills, those sorts of things, once you know what they're doing. You should learn your craft, and then you should be able to automate.
The question isn't, "Is the plan going to be the thing that you use?" It's, "Did you learn to plan in the first place? Did you make a plan?" Learning to understand what's happening down there in the browser, in your site, getting familiar with the guts of it, is an important thing to do. But this was a talk that was juxtaposed, it was put right next to several talks about polyfills, and how they were amazing, and how you can just include these scripts, and they make these problems go away.
The cognitive dissonance, the difference between these two positions, could not have been clearer. One of them said, "Look, this is good. This is great. You get everything here for, effectively, free," and the other one said, "No, no, no. It's terrible. You should go and learn what's in there, understand it", and both of those things ring true, don't they?
One of them is a key enabler to making your life better, and should you have to know everything about everything? Who does? The other one says, "Well, you should know a lot about things, especially if you're going to make progress, because it's good for you, and it's maybe good for people around you."
I, as someone who works on a browser, was sitting here listening to these two talks next to each other, and the only thing I could think was, "We're doing it all wrong", because this is not a debate that web developers should be having between themselves necessarily.
Yes, this is a debate that will always happen at the margins, but the question of, "What is it that you're doing to take care of some marginal percent of the user base, over and above how you were going to construct your designed experience in the first place?" is really what it gets to. "How much effort, how much cost, how much expense am I going to put into architecting my system, so that I get this top-level experience for everyone?"
It's worth acknowledging that polyfills are attacks. They're a form of money taking out of your pocket, be that in terms of complexity, if you're a site, latency, in terms of just the sheer amount of learning you have to do in order to understand what they're doing, and how they work for you or with you, and, as Peter Paul pointed out yesterday, they're increasingly attacks at run time, and that's money that's coming out of, in many cases, literally, your pocket.
But those requests all represent value that's being added to that page, and a lot of that value is there to accommodate legacy browsers, people who are, in one way or another, either left behind or about to be left behind, and it's a reach out to those users, by those websites, to say, "No, no, no. We can still give you everything. We can give you the whole experience", but you're taxing everybody else here, too.
If you look at the sizes of jQuery 2.0, which is the new version that's going to drop support for old versions of IE, versus modern jQuery at the top of trunk-1.8, you get a relatively huge reduction. I've done experiments once upon a time in Dojo, to say, "What if we only supported a modern WebKit browser?" Well, you get something like 30 percent off of the top, and that's without re-architecting anything.
There's a lot of this cost, which is just there to capture or bring people along with you, as you move into the future. This is a maladaptive trait. Eventually, the set of the things that were you good for you, you evolve to a place where the set of things that were helping you out might be hurting you, and at some point, they hurt you more than they help.
Purebred dogs are a great example of evolution gone a little bit awry. They can barely breathe, subject to all sorts of cancers early on. It's a tough spot to be in when you've done good, and done better, and now you realize that the things that have helped you do better are helping you do worse.
Steve Yegge, in one of his rants, which, this one was leaked. It was meant to be an internal post for Googlers, but was eventually allowed to stay public. I recommend you go read it. It's all about internal platform stuff at Google, but he included in this, he said, "It's called accessibility, and it's the most important thing in the computing world, the most important thing", and he's right. This is part of a longer discussion about, you never build one product.
If you think that you're going to hit everyone with a single product as a service provider, you're probably wrong. So what are we doing when we build websites or web pages? We're building multiple products. We're always building multiple products. If you think you're building one product, you're wrong and I dislike your work.
That's not a controversial statement, because if you think that you're building one experience, and there's no fallback, if you're building without a fallback, and you're helping to create a world where only sighted people, or young people, can use the web's content, you're doing a dick-ish thing. It's not good.
Accessibility matters, but accessibility isn't in an expensive sense matters. Let's say that in an ideal world, we're building two experiences. It's probably many, many, many different experiences. Mobile, we talk about mobile as though it's a thing now, but it's just one other aspect of the experience that we're trying to build, you design these experiences intentionally.
You design a fallback experience, you design an A-level experience and then you maybe spend marginal time the middle trying to design things one way or the other somewhere to capture users you might've lost. Let's assume that we build into two buckets; your A-level experience and your fallback. You have a fallback, you have a fallback, you must have a fallback. We would like to capture the most users in the world and get them onto that A-level experience and not the fallback. That's good. That's reducing our costs. We heard this yesterday. Alex Graul was saying...he was showing some beautiful stuff at the Guardian, just incredibly gorgeous visualizations and he was saying, "But we need all of this to work in IE7 and IE8" and I just...I hear that and I cry. What he's saying is that no matter what we do, there are two ways to create a better experience; one of them is to...well to create a broader experience. One of them is to bring people along, is to bring people into the new world, is to give them new browsers, whatever and the other way is to set your sites lower. What he's saying is we need to set our sites lower in terms of delivering an experience in order to do it on these browsers. Polyfills are one way we do that.
All the responsive design stuff is effectively sort of in this vane it's not quite as bad but we pay a heavy, heavy tax for it. I think of this in terms of pollution. You're looking at this factory and you're thinking I wish they could get a scrubber on that.
If you look at the factory itself, what is this factory doing? It's not polluting, that's not what it's doing. Polluting is a side effect of creating an incredibly valuable thing. This is a factory that's probably lifting people out of poverty, helping to create a local community that people can live in and maybe it makes some the air dirty but it's creating products at a much lower price than if people had to do it without mechanization.
It hurts our perception of the platform, this isn't great. In fact, it's really bad. It's very, very, very bad. This is very bad. I don't know how to express this more succinctly. This sucks.
This is the world that we live in. My argument here is that there's a 90 percent threshold. It's about the line at which if you look over the historical trend of the YUI A-grade libraries over time, they said basically if you wanted to be A-grade, the A-grade list included 90 percent of the web's users at every point in time. That list changes, of course, but it always included about 90 percent.
It's worth noting that when we don't get new stuff quickly it hurts. It hurts all of us. It hurts our profession, it hurts our sites, it hurts our clients, it hurts our users and I think we need to own up to the fact that we haven't been doing very well.
I'm sorry. This is the part where I say, mmm. I'll get to the good bit. I don't know really does anyone really recognize it was almost a decade ago that Canvas was released? Almost a decade. I wanted to be doing something else by now. We're only at 82 percent penetration. Browsers that have Canvas as seen by Stat Counter are only about 82 percent. We're not even 90 percent eight years later. Eight years later. OK.
Rounded corners anyone? About the same time Firefox 2004, putting in Safari in 2007, same rate, same rate of decline. We're still waiting on IE8, basically. If IE8 goes away all this stuff so turns into free money. We could start using it everywhere. We don't have to...our fallback experience our bucket for fallback is an experience that we've expressly designed. Our bucket for A-grade is a new experience that we've expressly designed. We can stop kidding ourselves that there's something in the middle here. We can say, the 90 percent I can capture in my A-grade and my fallback is that rest.
Let's look at something a little bit newer. This is video, right? Introduced by Opera in 2007, we're at 82 percent but even newer than that are 3D CSS transforms. We had our talk about that today. Right now, we're at 64 percent over three years. If we look at that and we go what does it take to get to 90 percent? What does it take to get to actually available? It's not good. The optimistic, the early adopters among us can start to target new stuff that we launch in a browser today in 2016. Does that strike you as a good deal?
you can't use Canvas or SVG without polyfills, which are expensive because those SVG and Canvas things are probably going to end you up...those polyfills will end you up with VML, which is slow and broken in IE8. CSS selectors, Media
At some point, you start to feel a little bit of sympathy for the hostage taker. You're, like, "Oh, he's in a tough spot financially. It's terrible for him and his family. He needs to make money somehow". You're still a hostage. You're probably still going to die.
The end of this scenario isn't good, it's terrible. We need to have a little bit less sympathy not for our users but for the hostage takers. If you think about the world of browsers today the way the world, the way I like to think of it is that there is a pack of new browsers that are released relatively frequently; call it once a year, once every year and a half, worst case scenario.
All users who auto update to those browsers get the benefits of whatever competition has happened in the cycle just before that. In the previous turn...in the previous iteration everyone said, "We need this feature". And then they said, "No, no, no. We did this slightly wrong let's go to the standards and do it and come back". All right.
Now, we've got the standard version. That happens in the next version. The next version of every browser is the one that we can count on to be helping us out. The last version of every browser is a liability. It's always a liability. The population today is very bimodal.
You have auto update, that's been taken on board by every browser vendor and the users who have the auto updating systems enabled and hopefully as friction free are way out in front. They don't need anybody's help to get the new stuff. But you view this entire world as your customer base. You think of them all as just variations on each other. You need to accommodate this whole world, but you don't.
This is the good part. This is the thing where I think...does anyone use IE7 day-to-day? IE6? My IE6 homies, anyone? No? OK. All right. I didn't think so. I want to show you some new stuff. Stuff you might not have seen. This is YouTube in IE7. I know. It's a little in your face, isn't it? This is actually better than it was. For the longest time there was a bar across the top the entire layout was broken and it said here are our browsers, install one of these. This is YouTube, this is the world's most valuable home page, it is in your face. It says, please, please get a new browser.
This is Gmail in IE7. This is not IE6 by the way, mind you this is not IE6. This is what Gmail is going to look like for IE8 as soon as IE10 is released. [applause]
This is Yahoo now. It's not just us. This is Google Docs and this is trying to edit a document in Google Docs. This is Google Plus; seriously, this is Google Plus, honestly. This is Facebook although I will note for the record that I think that those links that are up there are even broken right now. They'll fix it I'm sure. This is Hyves, this is amazing. This is Google Art Project. These are big, big, big, big sites. If your boss says, "No, we can't afford to turn off support for IE7 or IE8, seriously, go get yourself a copy of IE7 and IE8 and then go browse the web. Seriously, this is [indecipherable 30:
34] in the future already being here.
I just think we haven't collectively accepted that this period of evidence that keeps accumulating about how we're not necessarily doing well for ourselves keeps piling up and we may be missing it. I'm just going to leave you with this, which is, that we can do this. We have seen revolutions in the web before and they're enabled by users getting new browsers. Not new browsers once but new browsers continuously. That change, that churn, that's what causes users to have a better world and gives us access to the benefits of competition.
We don't get anything as long as we have to pay attention to the last version of some browser. We want to be developing against the current version and the next version because as long as there is anyone who is one browser or version back, they might as well be cast in stone. They're end versions back they just don't know it yet. They might as well be lost to all-time. I'm going to leave you with this; only we can do this. It's up to us as web developers to put these prompts in place, to get in users faces and say, "Listen, you're polluting. I realize that you're doing well by your organization by not replacing stuff"
Maybe it's expensive to replace. Maybe it's expensive to put that muffler on top of that smoke stack, but it's up to us to say, "You, as a user, are hurting us. You're hurting the environment. You know that thing where the web is slow and you hate it? You should be doing something about it, dear user". Maybe you don't have to be as up in someone's face as Hyves or Plus are, but YouTube, think about YouTube. Think about the Google home page.
These are lessons in what we can do together to help change minds, and if there's anything that we've learned in the Chrome experience of the last couple of years, it's that users do what they're asked to do. If you get in their faces, and you say, "Hey, I need you to take a moment of your day", or just serve them the fallback experience. Stop treating users on old browsers as though they are part of that leading pack. That's my plea to you.
I guarantee you that if you do, we can change this. We can end our legacy nightmare, because the auto updating world is the world we all want to be in, and as you saw, it's already better than anything that we've got right now. It's going to be amazing, and I think we can do this together. Thanks for attention, and... [applause]
Hey. Call to action in the end. Good call. I like the idea that Facebook asks you to download Internet Explorer because Internet Explorer's old. That was a nice screenshot. It's really hard to point to people to upgrade it, because it's like...
Oh, I think Facebook, they actually have a list... They changed their prompt recently, but it was asking you to install the latest versions of IE, and Firefox, and Chrome Frame and Chrome. I think they're doing the right thing.
I very much agree with you. I'm just so tired that people keep building things for Internet Explorer 6, as if it's a browser that should be supported in the interface. People are not used to good experiences there. We should not spend our time to shoehorn that in there.
Well, my view is a little bit more aggressive than that. It's that you shouldn't be spending any time on IE8. IE8 should be your fallback experience. You should be developing your sites with IE8 in mind as the fallback experience, because if you're targeting your top-level experience at any version behind the latest version, you're actually taking money off the table.
That's what you're doing, and I think that that's a place that, collectively, we need to get beyond. We need to understand that this is actually a form of pollution. It's users and organizations that have chosen not to participate in good social behavior, effectively, punishing us all by polluting in the environment.
I think it's also very important to think about this in a global context, because the argument I always hear, and we had lots and lots of meetings in that in Mozilla, is that, for example, in Korea, until a year ago, we almost had every banking locked into Internet Explorer 6, because the security, which is the most ironic thing, was done with ActiveX. By law, the banking sites had to use ActiveX, and no other browser would be allowed but that argument does not count to me in our world. That shouldn't affect our work, to say, "Oh, we have to do that, because some banking site in Asia has to do it as well."
That is partly their problem if we want to go after the same market, which is not very likely, because we don't get their clients with our websites. I always love when people talk about browser support, that they go for these edge cases in both sides.
Well, I think it's a reasonable thing to do, but my argument here isn't that you shouldn't be trying to help those users out. It's that you need to do something different to help them out. You need to put them not into the group that you're doing the most care and feeding of. It's that you need to put them into the short bus. You need to treat them as though they're using browsers that deserve the fallback experience, and test your fallbacks.
I think testing your fallbacks is really what I'm saying. Test your fallbacks, and aggressively put people in that group, because that's accessibility. That's designing the second experience, and if you're paying as much attention to that second experience as, I think, we all agree that you should be, then you're going to do well by them, too.
A lot of the arguments I hear in web design is, "Yeah, everybody has the newest WebKit, and the coolest, newest browsers, and we don't need any fallback that is server-side rendered anymore at all", so how do these work together? How is the fallback solution there?
There is a lot of tension, obviously. I think the big change we're seeing now is client-side data models starting to become prevalent. People are starting to finally start doing client-side MVC, and data binding, and live updates, and you wind up with a crisis, effectively, about, "OK, where does this view state logic live? Where's my view model? Does it live on the server? Does it on a client? If I migrate it to the client, how do I make that work for all of my users?" I think just fundamentally, if we accept that... There are going to be some people who can definitely write users off. They're lucky. It's Mr. Doob, right?
Who cares if your OpenGL experiment doesn't work on an old browser? It's an experiment. But if you're shipping stuff to a broad constituency, then you have to have something on a server that's always going to help serve the basic content.
Again, I think this argument bottoms out into very... I don't know how to put this. It's not well-thought through. Because the idea that you're going to have an HTML parser that works against most HTML in the first place, which is your fallback experience. What you're saying, "Oh, well, it has to work on these browsers", well, those are browsers. You're not saying, "It has to be readable in a text editor". You're not saying that to users. That's not what you're saying.
There's some assumption of a level of software, some amount of CPU that you assume, some amount of network bandwidth that you can count on. And so we have to understand that these are always marginal arguments. They're not absolutes. And so it's worth saying, at some point, you need to pay attention to what the experience for your users is, but talking about browsers specifically may not be the right frame to get to the accessibility that you want.
I like the hostage situation, because I found there is almost a Stockholm syndrome of interfaces in people. We had these terrible experiences for years and years in enterprise-level software that worked across all the browsers in a very bad way, with five steps for one drag-and-drop could do. And people are just defending those and saying, "This is what software should be like, otherwise it's not professional."
And I think Google Docs and the Google Apps suite are actually fighting all these old ideas. Do you think there's a way to work around that? Because I would love to see a Chromebox replace every single Windows machine in an enterprise environment out there, but it's not happening at the moment.
Well, in terms of Chromeboxes, I think once enterprises come to understand the mind shift that has happened amongst vulnerability researchers and malware authors right now, I think a lot of those things start to sell themselves. Because they way people write exploits now is just fundamentally different to the way they were engineered a couple years ago. Zero day is zero day. You're probably owned if you're behind at all.
And so the structural solution is to have software that's continuously updating, and has structural security built in. And Microsoft has got the message. But if you've got organizations that are tied into this idea, they're going to have to make a big shift anyway. But I think it's our job as web developers to treat the users of those organizations with respect, but not to pay them for hurting us. It's not impolite to point out that they've kept most of the users in the world from having a better experience.
Because that's what's happening when you put in these polyfills and you do all this work to go do the care and feeding of old browsers. You're hurting your mainline users in most cases. You might say, "Oh, it's just a little bit of script here and there." That's network latency, that's battery. It hurts. It hurts.
Go load a blank web page. Just do it. Load a blank web page. How much should it cost? It's f-ing instant. Right? But we don't assume that that's what Utilitarian is right now. We assume that it includes a copy of jQuery and some reset CSS and all this junk. And how much of that do you need in the modern world? If you did the thought experiment and said, "OK, everyone's got the latest version of the most modern browsers, how much of that baggage do you actually need?"
That's the sort of revolution that I think we're on the cusp of, and we just need to do a little bit to push that IE8 and soon IE9 percentage out. Android 2.2...whatever that is, we need to get in user spaces and give them the options that they've got.
At worst, we don't update these polyfills. We don't use polyfills as polyfills. We just keep them there indefinitely rather than seeing them as a stopgap solution until we can do better.
I think that's how all software is built, though. I think the idea of software maintenance is mostly a fictional theory. There are some pieces of software that see enough investment that they're going to continue to have new versions, but that's not maintenance. There's some software that can't die, so it's going to be put on life support. And there's some software that's going to never be touched again. And those I think are the three camps. I don't know that the idea of software maintenance exists.
Good point with Android. I think the largest problem we have with Internet Explorer not being updated is because it was highly tied with the operating system, and if the operating system doesn't get updated, then it actually doesn't get improved. And we now have the same problem with the Android Stock browser. Chrome on Android is there, but it's still an opt-in, even for Jelly Bean, for a lot of providers. So that's the next round of that, isn't it?
I think we're in a slightly better position. Yes. That's the position we're in. And this is where I think that we should be doing collective advocacy to those users and say, "Hey, Firefox for Mobile exists. Chrome for Android is great. Please get a modern browser". It's not often users' faults that they're on bad browsers. But it's also not necessarily fair for us to assume that they've made an explicit choice.
We have to provide them with the set of options that they've got, and to the extent that there are good options available, I think it's our collective responsibility to start presenting users with the options that they've got, because it's good for them, too, in most cases.
My biggest issue is, as well, when you want to go to the bleeding edge, and you want to say, "I want to use all the cool new stuff that you listed", we're blocked by hardware. That's why we do Firefox OS. That's why Chrome is out now and iOS as well. It's just unfair that browsers cannot access the hardware that it runs on nowadays.
I have a hard time taking a side here, because if you look at it from the perspective of an end user, if you assume that there's competition, and competition makes products better, that's generally, I think, a reasonable way to think about the world, it's evolution in another name, then what you need to enable that is real competition. Real competition is, I think, desirable, as long as there's real competition, and everyone gets the benefits of the latest version.
This is the key thing. If everyone is auto updating, and there's real competition at some level, then everyone's going to get a better experience. You can see failures where not everyone gets auto updates. We've seen that failure real large. We've seen places where there haven't been competition. Without real competition, you don't get the progress that might have otherwise been made.
I don't know of another way to inspire people to do a thing than to say, "Someone else did it better", and that's true for me. To get me to do a good job, you should say, "Someone else did a better job than you did". That's probably how you're going to make me get out of bed in the morning.
It works. It absolutely works, and it's the best thing we know to make large scale progress. You need real competitions, and maybe that's at the device level, right as devices become disposable. I don't know. I honestly don't know, and I can't speculate, but I think it's too early to tell what the end game there is.
Interesting question here: "Isn't auto updating also attacks? Browsers have bugs. New browsers bring new bugs."
Sure, but let's talk about the risk window. I used to be a security engineer once upon a time, and the way to think about risk is not as a bad thing could happen. You live in the real world. Bad things happen every day, you're just comfortable with some of them. You've learned to understand the potential magnitude and the potential frequency of certain things that could go wrong.
New things happening is scary because you don't know how bad they could be, and you don't know how long they'll be there, and if you look at the history of the web world, you feel like you might be left at the alter at any time. "Oh, Microsoft might stop developing a browser. Now everyone's hosed," or, "Google might drop Chrome."
Anything could in theory happen, and it could be existentially bad, but focusing on that without saying, "All right. Let's say there's a bug, and it's a common bug, and it hurts live websites. What is a browser vendor incented to do? What are they likely going to respond with?" If the answer is, "There's a popular bug in their bug tracker, and they can roll out a fix in less than a week..." We've done that, by the way.
There have been cases in Chrome where we have rolled out fixed for websites. Where they had compatibility issues with us, we changed Chrome and were able to get it out to users faster than they were able to fix their website and we rolled it back, because we're able to distribute software that fast.
If there's a bug, what's the window of vulnerability, effectively? What's the window of risk? If it's a rolling software world, then that risk goes away, because we can fix it as fast as we break it. I'm not saying that we want to break things, and if you ever go download a browser from a source repository, Firefox, Chrome, whatever, what you'll realize is that most of that many gigabyte download is tests, and those are tests that are born from hard experience.They're not just theoretically like, "Oh, your grammar is correct", or, "Oh yes, you parsed this thing". It's like these [indecipherable 46:
53] real world things combined to blow up a scenario. We want to make sure that never happens again. It's mostly regression tests, end-to-end regression tests.
That's how we build browsers, and you should expect us to continue to do that, so I think the premise of the question is what I would have experienced, and what I might have assumed might go wrong, before we had auto updates, which make progress go faster, and before I understood how browsers are developed, which is that it's mostly tests.
It's being scared of the new thing, and being scared to try to shoehorn it into practices that review software every year, or every three months. That is really problematic, but at the same time, when you see how security and attacks changes, it has to change. It really has.
I think the thing that really kills it for me is that if you look back on our recent history, our last decade, we've rolled out new stuff, and we haven't gotten those gains. We can't use most of that stuff. The only stuff that we can use are in certain scenarios, where it's backwards compatible, and you don't break the experience if you're in the fallback.
New CSS features can only be used in certain ways. Adding new core semantics to the platform that don't have a fallback, that don't have some sort of a Polyfill, wow, that sounds like scary talk, but it doesn't necessarily have to be that way. We can't even take advantage of the stuff that we know we've got, let alone the new stuff.
I think the value proposition is better than it appears to be. There's a lot of new stuff just sitting there, waiting for us to take advantage of it at broad scale, and the risks are much lower than they appear to be. Some very large percentage of the world, probably more than 50 percent of the world's web users, are on Firefox or Chrome, or Opera, and they're getting auto updates without being asked, and the world still goes on.
The sun still rises. Software still sucks. Life is life. We haven't broken the world. We're there. We can do this.
With that, thank you very much. [applause]