 All right. So I'm really excited about this. EdgeConf is kind of like the focal point of a discussion around using cutting edge technologies to build amazing user experiences. But I think kind of the elfin in the room is it's great to learn all about all these new technologies. But what about older browsers, browsers that are less capable that cannot take advantage of some of these things? So this session is an opportunity to kind of discuss some of those challenges that we've had for a long time and what we can do about them now. We have a really powerful panel up here. So let me quickly introduce everyone. Over here, to my right, is Shwetong Dixit. He has been on the Opera Develop Relations team and OpenWeb team for a while now, working a lot on compatibility of all sorts of sites, so whether they have willy-nilly regexes that are blocking opera and such. Also a member of the Web Education Community Group and the Mobile Web for Social Development Group at the W3C. To my left, Tamomi Amura. So she has been kind of fighting for the mobile web for a long time, ever since 2005, when she was leading the mobile yahoo.com. m.yahoo.com, yes. Also was using WERFL to great success, trying to wrangle all sorts of kind of tricky little mobile devices coming over there. Worked at WebOS and is now at Nokia. Cool. On her left is Ed Saudin. Ed works for the Government Digital Service. And the GDS finished a just big huge redesign of Gov.uk, a kind of much-lotted progressive enhancement redesign, bringing all of the UK's government online. And they're now continuing to bring more departments online. They've done a really good job presenting the best way to do progressive enhancement and documenting their strategies and methodologies, and also providing a very transparent development process, blogging, documenting guidelines everywhere. Really fantastic job. And our opening speaker, Tom Maslin. Tom is the tech lead for BBC News Visual Journalism and has been leading the client side team for the mobile BBC News team for a while. Has been kind of a sands-based developer, knows browser performance and JavaScript extremely well. And also a while ago worked on the team that built and open sourced the GLODE JavaScript library. So last from the past. All right, cool. So Tom, if you want to take it away, be great. Hi. Hello. And can I have my slides? Hi. Hello. And welcome to the introduction talk, Legacy Clients by me, Tom Maslin. Or as I think this talk should really be called. Yay, I'm so excited. There's going to be five versions of Internet Explorer for me to support next year. I'm 34 years old. Back in my arrogant 20s, I saw myself as a bit of a hand solo, flying around the office, saving princesses' websites, fixing bugs. My job used to be easy. I had four rendering engines to support. And yeah, I also had to worry about accessibility. But right in my code, semantically fixed that. And I also had to concern myself about SEO. But that's essentially accessibility for search engines, right? So my semantic code sorted that too. This was a time when we could all afford to be little hand solos, quickly put insights together. But then in 2007, all that changed when Steve Jobs invented the bloody iPhone. Shit got more complicated. Suddenly, we had mobiles with very slow connection speeds and phones with different size screens, new types of interactions, smart phones started to appear with pathetic little processes, and tiny amounts of RAM that ran my code really slowly. And PPK also pointed out that there was like 100 different versions of Webkits to support. But all of these problems were nothing compared to what was about to wash over us, an avalanche of devices. Being confident little hand solos wasn't good enough anymore. Instead, we've all had to become intelligent, clever spots who can balance all of these issues against getting our job done correctly. As developers, this is the biggest problem that we have today, balancing agility, getting the stuff done quickly, versus robustness, getting the stuff done right. Now, in this paradigm that we find ourselves in, it's very easy to concentrate on this issue so much that we forget about boring old issues like supporting IE7 and IE8. I can test in IE8 and 7, using a virtual machine on my Mac, but it's really hard to do. The experience is slow, and the DevTools are terrible. Trying to get IE7 DevTools to do I1 is like asking a wookie that's wearing boxing gloves to wipe my bottom clean. It's a terrible situation that normally ends up covering you in something. It's some bugs I just give up on because it's not worth spending the time required to fix a problem for such a small audience. It raises questions about whether we should actually support these browsers. I'd argue that sometimes it depends. While the challenges surrounding client support have increased, web development itself has become more popular. It's entered the mainstream. Everyone from school children to contestants on the apprentice are now making web pages. And the act of making a web page is actually pretty easy. Build something, look at it in your browser. There you go. It's done. It's very fast. But as I've just shown you, the practice of web development is the complete opposite. It's actually really hard to do right. Anyone can pick up a book or read an article online that teaches you how to make a web page. How to write HTML5 or CSS or JavaScript. These things are hard to master, but they're easy to start doing. What is hard to learn, though, is how to scale your website up from a single user, i.e. yourself, to a larger audience. These things here, they help you to scale your audience, but learning them is much harder. Because to understand these, you have to change the context of your thinking away from what's in front of you. As a developer, I often find myself having to defend these things, but ultimately, the web isn't about these. They're important, but we don't do accessibility for the sake of accessibility, and we don't make sites fast or SEO friendly or work without JavaScript because it's nice. What we're trying to achieve, our actual end goal, is ubiquity. We want as many people as possible to see our site. The web should be inclusive, not exclusive. I mean, nobody would build a shop that only the dwarf from Game of Thrones could get into, right? Shops have doors that are wide and as tall as possible. Websites should be the same. An easier way to think of ubiquity is to call it browser support. When people talk about web browser support, they think, well, how far back should we go? IE6, IE7. In the website versus native apps debate, the reason why website wins is because apps are binary. They either work or they don't. An iOS app works on an iPhone, but it doesn't work on an Android. However, your site will work on both. And even better, if you build it properly, it will work to a certain degree on pretty much anything. It's the ubiquity of the web that wins. So to go back to the original problem I defined, this job is also harder because the problem is continuing to increase in complexity. And we have to balance that against getting stuff done fast and robustly. What we shouldn't do is fight that complexity with ever more complex solutions. People who build responsive websites that are really just a collection of smaller websites within it are creating more problems for themselves. When a problem grows to a certain size, the problem changes into something else. And to survive, you have to change how you think as well. We did that at BBC News. We turned the problem of browser support upside down. Instead of thinking about how far back we should go, we decided to support everything. We call this technique cut in the mustard. The responsive site has a very basic core experience that has a simple layout, is very fast, and is delivered to all browsers. The core experience is good enough to allow everyone to consume the news. On top of this, we built an enhanced experience using JavaScript and modern CSS. It has a complex layout and is very functional. This is only delivered to modern browsers. It's conditionally loaded by checking for the existence of specific features. All the browsers that cut the mustard have great JavaScript and CSS support. They have fast rendering engines and a less buggy. This technique is robust because it supports a massive amount of browsers. It's also agile as you're building the enhanced experience using modern coding practices. But IE7 and IE8 only get the core experience. Now, this might be good enough for you if these browsers don't bring a significant amount of traffic. Or you might decide that these browsers need more than just the core experience. How do you do that? Well, with two ways. We can edit the cuts of the mustard test to load an alternative JavaScript app that is specifically just for IE7 and IE8. We can then cherry pick what features of the enhanced experience we give them, like a two-column layout or video support. We also need to give these browsers better CSS. With mobile-first CSS, IE7 and IE8 only render the smallest view because they don't understand media queries. But with a CSS pre-processor, you can output a version of a site style at any defined width, specifically for these browsers. The panelist, Ed Salden, has already implemented this for the UK government website. And here's one example of how you can do it. Instead of writing media queries directly into your CSS, use this mixing instead. Then make a new SAS file that sets a variable with the width value that you want IE7 and IE8 to render the desktop view to. Import the main SAS file into this, and it will render out an alternative desktop-only version of your CSS into a new file. You should add the legacy IE style sheet into the page using a conditional comment. Now, however, you have to be careful now, as IE7 and IE8 will be exposed to your modern CSS, and there's lots of selectors and properties that you need to watch out for. If you're unlucky, you may find IE7 and IE8 will be rendering your modern CSS onto the page in a way that reminds you of how Donald Trump's hair renders itself onto his head. So to summarize, how do you support legacy clients? I'd say don't think about stretching your code across an ever-increasing browser support list. The problem is only ever going to get more complex, and you can't keep up by making an ever-more complex solution. If you keep thinking like a hand solo, eventually, this problem will get on top of you. Instead, I think the best way to solve this is with teamwork. Use a solid base of progressive enhancement as a springboard for your JavaScript, and treat each feature on your website like an away mission, deciding when to send these agent browsers to the fore. So that's enough for me. Let's chat about it. Very nice. I'm sorry, yeah. Gee, thanks. Thank you very much, Thanos. Great. So we'll go to our first question. Our first question, delivered by Hakim. Anonymous question, why should there be a stigma attached to not supporting older clients? If a developer knows their audience, and they all have the latest clients, what's the problem? I think that should be, why is there a stigma attached to not what, why should there be? So I'll rephrase that. So Shrutan, do you want to take this? Why should there be, why is there a stigma attached to not supporting older browsers? There is, but there shouldn't be. Mainly because when it comes to older browsers, there's a lot of reason to actually support older browsers, because there's a lot of times in which the user cannot update their browser, whether it's because the system administrator doesn't allow it, or because many times the user doesn't know what a browser is. So if you say update your browser, it's like, how could I update my browser? I don't know what it is. So that's one thing. Second things are that sometimes people know what a browser is, they're fully aware of how to update it, but they don't want to. Maybe sometimes it's because they're using a phone and they have a very crappy network, and they might use a proxy browser instead of something which is like a full-fledged browser. And proxy browsers are tricky, as we'll see later on. Sometimes people have very limited data plans. I know people in Europe who have 30 MB data plans for a month, and if you exceed that, then you'll get charged very, very highly. So there's multiple reasons why, and genuine reasons why, you should support older or proxy browsers. And there shouldn't be any stigma attached as such. I mean, we all like to play with the greatest and the most cutting-edge stuff. But the realities of the world is we need to deal with everyone. And sometimes there's also what you call regulation or some laws regarding accessibility, and stuff like that as well, which need to be considered as well. So the second part is if we do know what your clients are. If you're looking at analytics and numbers, and they're indicating that you're OK on dropping support for IE 6, and 7, and potentially 8, is that fine? I think it depends on the context of the content. I think if you're making a government website, then there definitely is a stigma, because these services, like mandatory, they have to be viewable by anyone. But if you're making an application like Gmail, then probably not, because somebody with IE 7 won't give you that much benefit. Is there legal legislation that requires the accessibility to old browsers? So the only legal legislation or legal things that exist for older browsers are accessibility. You can be sued for not having an accessible website. But that's up for the user to determine what accessible is. The stigma that we have, this industry seems to have this horrible stigma where you can't drop support for old browsers. You've got to go back to the question, what is supporting an old browser? Supporting an old browser for most of us means that we're going to test in it. So that's not support at all. That means you're testing in these browsers. Supporting is actually if anyone has a problem, you're going to fix it for them. That's support. So if someone has a problem using your website, yeah, you want to help that person out. But there shouldn't be any stigma attached with helping someone. But if you want to spend time making sure ahead of time that those people won't have problems, then that's how you spend your time. That's it. But the one problem I've seen is that, OK, let's say maybe by the statistics, each company services a stat and maybe they just decide to drop the IE support. And sometimes they're doing it in the wrong way. I mean, they try to sniff in the user agent or something and try to eliminate all the IE, which seem to be old, but many times they're doing it in the wrong way. So let's say I work for Nokia and I use your Lumia phone regularly. And my browser choice, well, it's not my choice, actually. It comes with an operating system. And it's IE10. And oftentimes I see the site like, oops, sorry. You have to update your browser. It's like, really? It's IE10. It's pretty decent. And I believe that service or sites should work. But I think they just try to sniff it out mistakenly and try to suggest me to upgrade the browser or just download some other browsers. But the thing is, like you were saying, we don't always have a choice. Users don't always have a choice. So that's something I have to just remind. People have to remind. So I guess on the topic of support, support is kind of a difficult, it is the verb that we always use in this discussion. And it implies that it is a binary decision. You're the supporter, you don't. And I think for many of our development cycles, our development approach support is kind of this sliding scale. And so Tom, with cutting the mustard, when a browser falls into unsupported, they get a core experience. So there is no unsupported. The idea is that everybody is supplied a core experience. Everybody gets the content. But the way it's displayed is very simple. So if there's additional content on the home page of the BBC News site, for example, like analysis and features, that's available. But you have to click it to go to it. So the experience is very basic. But you still get all the content. But then with the premium version, we'll just go and fetch all of that content and put it straight into the page for you. And is the difference, in your case, the amount of testing between core and the premium experience? I imagine you are not as actively testing the core experience. The core experience is so simple. It's a single column. We don't add any functionality into the page. So that's going to pretty much render on anything. I think Andy Clark, a well-known developer in the UK, a while ago released a Universal IE6 style sheet. The idea here was basically a style sheet that had very good-looking typography, but destroyed all the layout, killed all your floats, just kept it all in a single column. And the idea was give that to IE, give them nothing else. The content is there, and it's accessible, but you can forget about the visualness of the rest of the site. And I think that's a nice way for something to go unsupported is basically to fall into a pit of accessible content. So having an IE6 style sheet, which has virtually nothing, is kind of the approach we took for one of the large sections of GovUK. Because we used the approach that Tom was mentioning during the intro with using mobile first and then sending specific style sheets for IE6, 7, and 8. But IE6, they don't get any layout, because layout's added on desktop. So IE6 just gets a mobile view. So it has no, it's a single column. It's basically got typography, because that's all that it gets. I think it's a benefit as well, because people with IE6 or IE7 probably don't have a good computer. And so the fact that it's so simple means it will render like five or six times faster than other experiences. Right, it's so readable. And as long as users can get what they want. Experience is not killed. I think that's a good strategy, because there's so many sites which either support it or just send an error message saying that, OK, this site is not supported, and that's it. The user cannot do anything about that. So I think that's a very important thing, that you don't block anyone. You at least serve them the core experience. The first part of that question was if you know your audience. And it's really difficult to know your audience in a very, very accurate way. Even if you know using your statistics and your analysis, what are the browsers which are coming through? There are times in which you get a mention on the front page of Reddit, or you get slashed on it. Or an influential news website mentions you. And then you'll get this whole stream of traffic which is completely unpredictable. So even that premise of that question that you know your audience is flawed. So I think it's a good time to move on to the next question. This one to be asked by John Fellows. So this is an anonymous question. What's the best way to make legacy clients a visible part of the development process? So I think this is both visibility on the developer side to understand what is necessary to give them what you plan to give them. And also potentially on the executive side to better understand what, from a development cost perspective, is included here. At the BBC News, we made the responsive site, but it was a small team that did it. And then eventually we found it out to the rest of the department. And so we've had to go through a training process with everyone as they become engaged with the product. So we've got the designers thinking about the core experience as well. And they're thinking about progressive enhancement. So they start off with the core experience. And then they progressively enhance it and make the better version. The problem that we find is that many people just associate the core basic experience with a very thin layout. What they find harder to do is to probably try and understand that the core experience could be any width. And the premium experience could be any width as well. I also wonder, is there included on this, I think, there is a visibility of the perceived experience between legacy clients and modern clients? And one of these parts is performance, certainly. So just rendering a page or any sort of interactivity, the more modern browser, it's going to be quite a bit more responsive. Is there a good way to demonstrate the difference between the user experience of someone on an older client versus a newer client? And is that something that the executive team wants to see and understand? Maybe I would say, let's say some UI, or I would say UX, using some Ajax-y type of interaction. And that works probably wonderfully on the latest graced browsers. Chrome desktop works nicely. But yeah, they show the same UI. And let's say all the mobile browsers or it could be Android, all the Android and stuff, it's probably going to look really janky, or maybe even unveil, you know. A lot of us manage the expectation, though. People on the old browser, people on IE6, who are stuck on IE6 in their corporate environments, they'll be used to an internet which is not quite like the internet the rest of us use. So while, for me or for you, browsing a website in IE6 will feel painfully janky and painfully horrible, they're kind of almost expecting that. And people aren't left on these browsers because they want to be there. They're there because those are the browsers they have because corporate IT have said that's what they've got. So it's all a case of managing expectation for those guys. Those people, if they know they're getting a janky experience, they come into that knowing. And my colleagues, I have colleagues who have IE6 as their browser on their machines and they know it's gonna look crap. And they joke with me like, is this supposed to look that bad? And it was like, I think the developer picked that color for you. It's like, no. They know the internet's horrible. Yeah, I mean, the thing is just to add or maybe even remove from my point, they might be used to it when they're working but for sure they're using the internet at their home or on their mobile and transit or something. So they know what the real internet is like and it'll be even more frustrating for them to see the internet as it is in the wild on IE6 all the time at work. Go and sit next to them at work. They're like sort of paying at work anyway. They know. Calvin's feeling something there? Yeah, actually I was gonna ask you what you just said but I wanted to ask specifically, is there a way to, if people have these different experiences at work and at home, they know your site's different when they're actually at work and something might be missing functionarily that they're used to at home. Is there some strategy we can take to make them not frustrated at us seemingly like they're suddenly hitting a broken version of the site that they were used to? I think this comes back to the approach with cutting the mustard. You make sure they can get the content they need to get still. While it'll look different, it'll feel a bit different as long as they can achieve the goals that they need to achieve. It's the best you can do for them. True, I guess. I think what I'm hearing from both of you is that there is kind of, both strategies include a degraded experience for older browsers in some way and that seems to scale pretty well but that does mean that we do have at least two experiences. And so if we are in a situation where you have someone that has seen both of those experiences, is that going to be a problem? I think that's fine because we can't, like I said in the talk, we can't make a premium experience that works across the whole spectrum of browsers because polyfilling and mobile internet connections are so hard to marry up together. So it's gonna, it has to be good enough because there's no other way. No. Yeah, it's better than just showing them that oh, your browser is not supported by. You know, it's at least better than that. I guess, sorry, the one caveat to what I just said is that if you do server side detection and sniff the old browsers, which is probably something, because normally people, when they talk about UA sniffing, you think about, oh, is this a mobile device or is this a desktop device? Whereas I think now we should probably be thinking about is this an old browser or a new browser? I think that'd be an interesting. In your case, would it be, is this a, does this browser cut the mustard? Yeah, you could do that on the server, if you wanted to. Right, like, you know, the old browser, that doesn't support JavaScript. It doesn't understand, you know, JavaScript feature detection, then you have to rely on the server side. All right, I'd like to move on to the next question. This one comes from Dustin Caston. Dustin's up here in the purple. Hey, so what as a community can we do to help the holdouts of legacy clients such as the government and IT departments too? Nothing. That was my answer as well, I was gonna say nothing. So I did a little bit of research on kind of around this point before I came. The same pool said to me earlier, I've built a thing, so which takes your Google Analytics and splits out browsers with graphs. You can see browser usage over time. So it's called browser matrix, takes in your Google Analytics account and then just charts the trend lines for browser. Paul said it'd be really cool if it could show future trend lines. So I went and had a look because I'm a nerd. IE6 is in seven's trend lines on GovUK. They're going down. IE6 lost half a percent in the last six months. What percent was it? It's gone from just over one to around half. Is that any particular time of the week? So it can also show you stats on a day-by-day, seven-day rolling basis. And during the week, six is above that. And at weekends, it's not really there. But I guess the question is like, but in the case like IE8 would be a better case. So like those guys, they're going down, they're gonna get there. And from the government perspective, like working in government, everyone is painfully aware in government that we're tied into these horrible contracts that require us to have IE6 and everyone's working to try and get out of them. Like no one is trying to stay in that world. There's not much a development community can do to help that. And on GovUK, we have a browser bar that pops up if you want an old browser that says try and upgrade, which hilariously, we won a design award earlier this year and a whole collection of screenshots that in news articles, you could see that browser bar. So, made us smile that these people writing reports for fairly large magazines online still use old browsers as well. But in terms of government and massive corporates, very aware we're trying to get rid of it internally. A question from the audience, Daniel. So, we always want to allow our users to be happy and I looked at some numbers and we have IE, all of IE is like 8% of our traffic, maybe 4% of our traffic. But is it worth spending the effort versus things like developer happiness and redemption? Sounds like it's not worth the effort for you. Sounds like you're doing well. I'd say it depends. I mean, those old devices might bring a lot of traffic to your site, but do they bring a lot of revenue? And... Right, I think that's something that it's, I don't know that we've seen a lot in the way of business metrics that are segregated by browser or by connectivity or by the performance, the load time of the site. But I think it's worth looking into kind of how those technical metrics of the site and of those users translate into their success on the site. I guess to get back to Dustin's question, we're talking about what our community can do to help legacy clients. So Google Apps dropped support for IE8 last November. And Google Analytics dashboard has dropped its support for IE8 in a few months. Google has a policy of only supporting the most recent and the last version. And so Google's being kind of aggressive in this and saying you just have to upgrade in order to use it. You can't use Google Docs on IE8. But is there anyone else that is in a position where they can help move this forward, or were you just in a case where we are just waiting for those trend lines to naturally go down over the course of years as we did with IE6? Internally in UK government, I'd love to say more, but there is work going on to fix it there. But yeah, it's still, there are people trying. One more thing that I wanted to add was a lot of these things are decided at the contract level. Sometimes what happens is, I can at least talk about the Indian government, sometimes what happens is they don't make the government websites. They sometimes send it out to a contractor who makes it for them. And usually things are decided at, when the contract is signed. And if there's a clause saying that, okay, IE6 will be supported, it has to be supported. So one of the things is to, as a web developer, if you're wanting for that contract to argue at that level before signing, that yes, I will not be supporting these things. I might be supporting the newer versions. And the second thing I wanted to mention was this problem is exacerbated by the fact that many people who were in government weren't really tech savvy that much for a while. They didn't really know about browsers and stuff like that. But with newer devices coming in, people are having iPhones and iPads and stuff like that, they still might not know what a browser is or not care. But they know that, okay, whatever this website that I'm sending the contract for, it has to work on my iPad, for example. So they're more focused on those things, on devices rather than the older browsers. So that mind shift is happening a little bit. But once again, as web developers, before signing the contract, you have to see it and be very careful about that. Talking about contracts, all contracts that the UK government signs now cannot have anything which even hints at vendor lock-in or device or browser lock-in. Anything that hints at a specific version has to be removed before contracts can go out to pretend there's nothing that's allowed anymore. A comment from the audience, Mary from O'Reilly. Hey, so just going back to, we were talking earlier about how frustrating it is for your co-workers if they have one browser version at home and one browser version at work and those types of scenarios. I think we might be referring to a very specific portion of the world in that those are the people who are very tech savvy who have the latest and greatest things who, yeah, you know, bigger and newer is better. But what about the rest of the world that, you know, updating your browser is scary because it means all of a sudden you don't know how to use it anymore. So there's people who consciously make the choice to not update because of that. So, I'm sorry? Your mom's. Well, okay, so yeah, that's an example. My mom does that. But I mean, it's a legit scenario. And by eliminating the ability for them to view your website, you're basically telling them they don't matter. Yes, I think change a version is real for everyone in a lot of cases, browsers and website features as well. I mean, my take here is that a lot of it is up to browser makers themselves to make transitions as smooth as possible. We're good now because the problem was always IE, right? Or more like corporate IE. So people would build corporate intranets and they would rely on ActFX. And that's why we're in a situation where there's so many corporate desktops that can't upgrade. I was going to mention that too. Many times you can't just download, install any browsers and any computers. You have to ask IT guys to do that, you know? So obviously, you know, probably that's where legacy IE is coming from. So, you know, if you're, you know, working for the web services for, like, enterprise and such, this is something like a really huge issue. And you have to really watch out at your browser stats and what you're, you know, the people using. So I want to move on to the next question, but before I do, I want to get Jeffrey Bertoff from Microsoft, since we are talking about IE a lot. It'd be nice to get his comment here. Yeah, thank you. So, first to defend Microsoft here, one thing I want to make sure, and I do that proudly, because one of the things I want to make sure that we understand is that Windows XP that runs IE8 was a great product, and that's why people still use it. So anytime we build great products, we're going to have to deal with legacy browsers, because they're going to stick around. So if you look at a parallel to iOS, so we just stopped, or Apple just stopped supporting, was it 3GS? With updates, which means that iOS 6 is the last version they'll ever see. But those phones are going to continue to be around, and they will become a legacy platform that we have to support. So when we have good products that are going to stick around, it's something that we need to plan for. So these type of discussions will always be relevant. Well, I think in this, in this case, we're in our situations that Windows XP is a great product, but the problem there is that users of IE on Windows XP don't have an ability to upgrade their browser to the next version of IE. Yeah, so that's, you know, that's something that's clear. If you are on that platform, there's two different things that are going to cause you to stay on older versions of IE. One is it's your environment, you don't want to upgrade or you can't upgrade. Or the fact that with IE, you can't upgrade past IE 8 if you're on Windows XP. So our, our, at Microsoft we use JavaScript, we use our JavaScript engine, HTML5 and a lot of our products. And so whether it's writing apps for Office or in embedded or in Xbox or in Windows 8 apps, all of that can be done with the JavaScript engine. There's definitely a coupling there that makes us have to draw some lines in the sands as to where we can, can update and where we can't. So it's not that it's, there's reasons behind it, I guess is what it would say. Sure, and I guess we can close this discussion for now with the end of support date for Windows XP is April 2014. Right. So that trend line that we're watching for IE 8 will may potentially drop down more substantially at that point. So there's like, there's a whole other like dark world which no one talks about. Talking about like old IEs and the fact there are other things which we have to support which no one talks about. And they're old screen readers. Actually, screen reading technology. Before we move on to screen readers, I want to get Alex Russell's comments here. Hi, thanks. Alex Russell, one of my first projects at Google and I'm going to talk a little bit about this frame which was necessitated because you didn't do what you just said. Microsoft didn't take care of the legacy. Right. It was Microsoft's responsibility to do that and instead Microsoft chose not to invest in making sure that users of Windows XP could continue to use modern technology. So having done the cleanup work for you, I just need to make the point that you didn't. This is going to get exciting. For the moment, we're going to move on to the next question. This one, Matias Kuzman, Kautzman. Hi. My question is, for how long is it worth polyfilling features for legacy browsers and taking the hit in performance or dev productivity? What factors should influence the ultimate choice to see support for a legacy client? So in a lot of cases, our method of dealing with older clients that don't support a certain capability is polyfilling them. We started out with the JSON2.js, JSON polyfill, and we've managed to polyfill many, many things. These polyfills do have performance costs, not only in the bytes that we have to send on the wire in CSS and JavaScript, but also in runtime performance. So performance of polyfills is a concern. And what are the other aspects that could help influence the choice to see support might not be the right words, but change the support level? So maybe a good example is with animations. So a couple of years ago, people would do JavaScript animations, and now we try to see all animations with CSS, and we just say, well, if you don't have that CSS feature, you just get a janky animation. I'd say that's fine. I don't have a problem with people in IE getting janky transitions. Especially with jankiness. If you want to have some animation, but it doesn't work in some browsers, I think you have to just kill the animation. I think not moving at all, it's far better than janky animation. So I want to say janky, I'll actually mean binary. It's closed, then it's open. But then with a more modern browser, you can slide it in and go. Although I guess an issue with that is not so much with Polyfill. Something I've seen recently where I made a panel appear, and I gave it a nice animation grow. It worked lovely in iOS, but when I checked it on an Amazon Kindle Fire, it had a great browser, it supported the feature, but it was really janky. Because the hardware just couldn't keep up. Right. And not just the hardware, actually the Amazon Kindle, the silk browser is a proxy browser. Or maybe a marketing term is like cloud-accelerated browser, or whatever that is. So that has to keep in mind. It's not like all JavaScript is forced to work in some WebKit, it works in as way you want an proxy. But I think, I guess, when we talk about legacy clients, there's a few reasons why, like we use the term legacy, and that does happen to usually refer to them being old. But I think the reason that we don't embrace them and love them is because they may have bugs, they're probably slower than what we're used to, and they lack features that we want to use, that we're interested in using. So it's not necessarily that they're old, but they aren't good as what we want. And I mean, is it worth forming a policy around how to change your support level for browsers? What's your take on this? I think, ultimately, there's going to be so many variations that you should stop with the mindset of supporting or not supporting those kind of browsers or not. You should just go with the thing of progressive enhancement and feature detection. And because what will happen is you say that, okay, I'm going to support this old browser, but ultimately, what will happen is you'll get more and more devices. Nowadays, we get devices which are running a very good version of Android, but are less than $100. So even though they're running like a very, very nice version of WebKit, for example, the performance is such that it really makes them almost like a legacy browser in many cases. So how do you define a legacy browser is going to become more and more muddled because a browser with a very, very nice phone can behave like a legacy browser if the network connection sucks. And there's a lot of smartphones coming up with good versions of WebKit, but very underpowered. Yeah, so it's a strange time. So you've got like a Nokia C5 that's an entry-level phone. It's got a really bad process and RAM, but it will have a really good version of WebKit on it, so it will render the page really well. And then you can compare that to an iPhone 5 that has Opera Mini in it, so the capabilities would be less or you would at least get a static version of the site. It's a very bizarre issue to try and solve. I don't think there is a magic bullet. Actually, in the modernizer web page and the documentation say, it's because you can use Polyfill doesn't mean you should. I think I said that in the site. It's true. Yeah, so it's really... So that's really, developers have to decide what you want to really support. You know, many times like a fancy UI would be really nice, but do you really care? And some browsers have been like round corners, really. You don't always need this. You don't always drop certain, especially if it's just UI print as you can drop that. But I guess the other part of this is that there are some features. There's a set of features that you cannot let degrade gracefully. WebGL, GetUserMedia, Web Audio API, these many can't be polyfilled. And so what is the responsible way in defining a browser support policy when you're dealing with features of this sort, where you're providing an experience that competes with something on a native platform and it's not content-based? So you mentioned WebGL. I can give you an example there. On the BBC News, we started doing WebGL content now. We've got the Mars, we have the Mars lander 3D object. So if you had WebGL supported, you could spin it around and zoom in and stuff like that. And it was really nice. But then there's no polyfill in that. So what other browsers would get is an image gallery of the 3D model. So we wouldn't try to polyfill the content. We'd offer an alternative content. Okay. I'd like to move on to the next question. John Rezeg, if you could, would love. Thank you. So I took this question because I didn't like it, so I didn't want it to be asked. The question was roughly that they felt that you could get away with supporting browsers that did not have JavaScript. And I feel that that is not the case, that for most content websites, you need to support clients that do not have JavaScript. But to spin it into a more legitimate question, what about web applications, where you're not dealing with strictly content-based? I feel like most of you are dealing with content, where it's like, here's a news article, here's some information you want to read. Obviously, in that case, there shouldn't be a barrier in between you and reading that. But what about a whole application that is built in very JavaScript-centric? Should you be making a fallback for that? I know if you want to use Gmail and there's no JavaScript, you fall back to this form-based thing. And I have no idea how well that's maintained, but that's got to be someone's sad job. But I mean, I assume not everyone wants to be doing old HTML tables and doing the forms. So is that legitimate thing? Should people be worrying about that for their applications? Tom? I'd say it's always best to create an experience that doesn't just immediately fail when something goes wrong with the JavaScript. So I think Gmail is a great example that you point out. So it's something that is a service. It is purely functionality. But then I think we should just make the experience. There's a great... In fact, I'll let you say this. So I read on the GDS website about why you should make progressive enhancement with JavaScript. Do you get what I'm talking about? No? Okay, so Ed said that instead of build your applications like an escalator instead of a lift, do you get me now? Was that you that said that? I don't think I wrote that. Was it Jake? I remember me. I read it on the GDS site. So somebody said, if an escalator breaks, the worst thing that's going to happen is it's going to turn into some stairs so you can keep walking up. So you can keep walking up it. But then if you're in a lift and it breaks, then you're stuck in the fucking lift, you know? There's nothing you can do. And it's the same with JavaScript applications. Well, I guess there's plenty of JavaScript applications. Diagramming tool and IAM client, like many of these rely on real-time data, cannot be done with page refreshes. And so some of these do require JavaScript for their interactions. Jake wrote a really good blog post on this recently. Yeah. Jake, would you like to comment on how... For those who couldn't see, Jake was waving quite madly. I'm kind of perching on the stairs because I was actually on the way to the bathroom, so he caught me just at the right point. Any website that has a loading bar is a missed opportunity. It's a missed opportunity to serve the content directly without JavaScript and then get JavaScript in there to do it. And Gmail is an example of that. I mean, Gmail should have URLs. I should be able to bookmark a page to a particular email. And when I hit that, I should get that content on the page and then JavaScript can come in and add the rest. I mean, it is just a series of tabs and forms. It doesn't need to depend on JavaScript at first render. But the Gmail web app also has URLs that are permalinkable for all messages as well. One thing I wanted to mention just to repeat, which matches this use case is you have JavaScript applications heavily reliant on JavaScript, but you also have these phones which are coming up which will have browsers which support JavaScript, but these are underpowered phones in which it will be actually better for them to get a version without JavaScript than to get a version with JavaScript which runs really, really slowly. So in those cases, it might be better for them to get a lighter version of the page. And the other thing is search engines. Once again, if you have single-page applications, you can run Node and Phantom.js and use a solution with that. But I still think that it would be better to just have something which can be run without JavaScript. I suppose in that search engine optimization, it's a balance of what's easy for you, and if it's important for you to have that content available to search, you need to find a way to do that either through progressive enhancement or through a complex server-side rendering farm. The alternative, the other side of the argument is that making an application that's purely reliant on JavaScript is probably a lot faster. So I would say you mean if times... If you're trying to get something up and running fast, if you're prototyping, if you've got deadline issues, then that is an option. You can do that. However, I would always try to make something a progressive enhancement. So in the slide where I spoke about the things that were nice, so accessibility, SEO, working without JavaScript, usability, all of those things are idealisms. But on their own, they're probably not great arguments that you can go to your manager and say, hey, this doesn't work with screen readers, because your boss will probably turn around and say, I don't care about screen readers. But when you add them all together, they create something bigger, and that's the whole point of the web. And all of those things, if you develop with all of those things in mind, then you're kind of developing and in the current of the web, you're swimming with the web as opposed to swimming against it, which is what I think is applications that are purely JavaScripts are swimming against a little bit. So you can make things that are purely JavaScript, but I think it's better and you get added benefits by building things in a progressive enhancement. Matt and May, I see you have a comment. We're going to have to make this very quick, but I want to get your voice here. Sorry, somebody says accessibility and I go crazy. I just wanted to add on to this, and I think BBC is a great example of this, that the users of assistive technology are not legacy or down-level users either. If you have something like data visualization or chat or anything interactive, those are still things that you need to make accessible, whether or not you're going to serve them to legacy clients. Everybody is expecting that. They have the latest assistive technologies, like everybody else, and it's important to decouple them from, well, we'll just serve them the text-only site because that's the same thin grill they've had since the 90s. Yeah, 98.4% of screen reader users have JavaScript enabled from the recent WebAIM survey. But guys, I think we're out of time. Thank you very much to our panelists for joining us up here, and thank you, guys.