[MUSIC] 0:00 [SOUND] Okay. 0:05 Is this gonna work? 0:11 Great. 0:15 [SOUND] Hi, so my name is Andrew Betts this 0:16 talk is about the FT's journey to web components. 0:18 It turns that basing your whole architecture on 0:21 components means changing not just a lot of 0:24 your development practice, but also the way that 0:26 we do design and product development as well. 0:29 I realized actually there's a chance that this talk will make me look like the 0:33 kind of guy who kind of hangs out in parks shouting crazily at birds. 0:38 And that always reminds me of this guy. 0:46 so, I'm hoping not to come across like Bill O'Reilly on Fox News. 0:49 But I have to admit I am the guy who made a 0:54 comment to our internal development standards 0:56 that banned our developers from using jQuery. 0:59 [LAUGH] So, I'm gonna look in more 1:01 detail later on about why jQuery and other general purpose toolkits and frameworks. 1:07 Because it's not about jQuery specifically. 1:12 May not make sense necessarily in a component-sized world. 1:15 And I also had a lot of chocolate at lunchtime. 1:20 And I'm feeling really sugar high right now. 1:22 [NOISE] So excuse all the shaking. 1:23 So let's start at the beginning. 1:26 Where do we start today, and why are components the way forward? 1:30 Each web project we do at the FT, is 1:33 becoming more complex, more complicated than the last one. 1:36 Our brand is increasingly digital. 1:39 And people are interacting with us on a 1:42 broader range of devices and browsers than ever before. 1:45 So that means that the cost of achieving a good user experience for 1:50 every user is increasing and the cost of testing is increasing all the time. 1:54 And this is a big problem. 1:58 It's a problem we need to solve because for 124 years we were a 2:01 newspaper, and for the last ten years of that we've had a website as well. 2:06 But for the last two years, we're a website that also prints a newspaper. 2:13 So that really is completely changing the way we look at digital. 2:18 So if you look at what we have today, you could quite easily just say well 2:24 you don't have a responsive site the Guardian 2:27 has a responsive site you should do that. 2:29 And many media companies already have responsive websites the BBC does 2:32 as well the Boston Globe well said on a very good job. 2:35 And the Guardian is a great example of responsive done 2:37 really well, but being responsive is not our biggest challenge. 2:39 There are far more important things to establish 2:45 what we think of a healthy web development ecosystem. 2:48 Something that we can use as the foundation 2:51 to build not just one responsive product, but hundreds. 2:53 So, what we have today is a collection of bits. 2:58 You know, you have some advertising, some 3:03 navigation membership bits, content bits, various sharing tools. 3:07 And all of these things come together on a 3:13 page in a way that is not very well coordinated. 3:15 A lot of them are built by different people, working 3:19 in different teams, that don't really talk to one another. 3:20 They're not really, even very well encapsulated. 3:22 They can be coded very defensively to prevent 3:25 interference from other things that might be on 3:28 the page, even though all those things are also built by people at the same company. 3:30 You get things, the resistance integration, 3:35 and also, too limited in scope. 3:38 So, the range of of stuff that you can do with them, the amount of 3:41 value you can get from all that work you put in is actually fairly limited. 3:44 Now this is exemplified by some of the, the kind of work 3:48 that we've had to do to create the same product more than once. 3:53 so, on the right here, you've 3:57 got marketslifeseat.com, which is a Desktop website 3:58 and on the left you have Markets Data in the FT web app. 4:01 So that seems a bit mad obviously there are companies that build the 4:05 same products in iOS and Android and Blackberry and Windows and on the Web. 4:09 We've built it twice using the same technologies 4:14 in both cases which seems a little strange. 4:17 Bt when you look at the FT web app and the way that was 4:20 built and the way it was designed, 4:22 it's resistant to integrating with other things easily. 4:25 So, 4:29 we see responsive as a feature. 4:32 But anyone can do that. 4:34 It's about how you approach building things 4:35 with Web technologies that we're trying to change. 4:37 There's a senior product executive at the FT who said to 4:40 me recently, you guys have been talking about components for years. 4:42 I remember people talking to me about components in 2005. 4:46 What's so special about components now? 4:48 And I think she's right. 4:51 Components are evolving and have been evolving for quiet sometime. 4:54 We've now reached a point where we can do really powerful things with them. 4:58 If you look back at the history of components, 5:02 you can trace it back to things like identity guidelines. 5:05 Big chunky documents like this one from Apple 5:09 which appears only appropriate for Apple certified individuals. 5:11 Which is a very big, thick flat document that just tells you what things 5:17 should look like, and doesn't give you any indication of how that should happen. 5:21 So, you can evolve from here to something like a living style 5:26 guide, which not just, doesn't just tell you what something should look like. 5:30 It gives you a reference implementation of how to do it. 5:33 So you then have the the origins of a standard component sized UI. 5:36 Because you have a piece of UI and you have lots 5:42 of websites to implement that UI in exactly the same way. 5:44 This actually is a really good living style guide 5:48 for Code for America made by Clearleft in Brighton. 5:50 So, this is a great start but what you don't realize 5:55 you need is a way of putting logic around those components. 5:59 A way of instantiating them, tearing them down, templating them. 6:04 Rendering them into the dorm and all of those things need 6:08 to be done in the same way for all those components. 6:11 And you really want a way of encapsulating those things, so 6:14 they can't interfere with other components that might be on the page. 6:16 So that's where you evolve again, and produce things like component frameworks. 6:19 Facebook produced a component framework very 6:25 popular one at the moment called Reacts. 6:27 We actually made something very similar called Fruit Machine, and our 6:29 Fruit Machine and Facebook's React actually came out roughly the same time. 6:34 And when you take a fairly simple example and you produce it using 6:37 Fruit Machine and using React, it's 6:43 astonishingly similar what you end up with. 6:44 So, that's a really positive indication for us. 6:47 It tells us well, Facebook and the F2 are very different companies. 6:50 But we had a very similar technology problem, 6:53 and we solved it in almost an identical way. 6:56 And that tells me well, we probably have our eyes on the same goal. 6:59 And that is the next step in the evolution 7:02 of components, which is to take it to web clients. 7:05 When we reach the point where we can use Web components. 7:08 We no longer have to opinionated about how we 7:12 wrap those components and put them in the browser. 7:14 So, you no longer have to be running React or running Fruit Machine. 7:17 You'll just make use of the components in the browser. 7:20 And components is something I've become completely 7:23 obsessed about because I think with the 7:26 number of websites that we have, the number of things that we're trying to do. 7:28 You can't always think about the tiny details every time 7:32 and you want to build something really good every time. 7:36 So, to try and build something really good 7:40 really quickly, you need to build with bigger bricks. 7:42 And so the analogy I always make to people internally is well, I want 7:45 to build a house, but I don't want to build a house using bricks. 7:48 I want to build a house using rooms because they I can put 7:50 a house together in a day and that's a really powerful thing to do. 7:53 So our objectives are these sort of things. 7:58 We want components standards more collaboration better 8:01 encapsulation and everything needs to be composable. 8:04 We wanted to go a little bit further than this. 8:08 Because we, we identified things that we 8:10 didn't think other people were doing so well. 8:13 And we wanted to try and come up with a solution that would take us there too. 8:14 So first of all, I asked a 8:18 domain administrator, how many websites do we have? 8:20 I thought, I'll go through them all, I'll 8:23 figure out what the commonalities are between them. 8:25 So it turns out we have 600 domain names. 8:28 And I took one of those ft.com and it turns out we have 800 sub-domains of that. 8:32 So I didn't look at how many sub-domains we have at the other 599 domains. 8:38 I didn't order all those work sites. 8:43 But, a lot of people still use them, you know, 8:46 millions of readers actually find a lot of these websites. 8:49 Very useful and they read them everyday, and we don't want to have to 8:53 rebuild them all, we don't have time, we don't have money to rebuild them all. 8:56 So, when we build components, we really need to 9:01 get value from those components on these existing websites. 9:03 And there are two big problems with this. 9:06 First of all these sites don't have bill, a bill process. 9:09 There's build process that I can insert dependencies 9:12 into, and build them into a front-end build. 9:15 In fact, a lot of these sites were 9:18 built before the idea of a front-end build existed. 9:19 And secondly, there's no foundation. 9:24 There's no common library or framework for running components on 9:25 the page, or if there is one, it's, it's obsolete. 9:30 So we need to be able to work around those 9:33 things without having to make major changes to existing sites. 9:35 Second thing is, I don't like monoliths. 9:39 I don't things that become a dependency of every single other thing that you build. 9:42 Because when you do that, at some point you will hate that thing. 9:47 And, you'll want to get rid of it. 9:50 And it will be a liability. 9:51 But the more things depend on it. 9:52 The more difficult it would to get rid of. 9:54 So the easiest thing to, the easiest way to avoid having to get rid of 9:56 something that's really difficult to remove is 10:01 not to build it in the first place. 10:03 The third thing is, we want to raise the bar. 10:06 This is a beautiful graphic that Google came up with years ago to 10:08 show the progression of web technologies and 10:12 basically it's all happening at this end. 10:14 These browsers on the other hand, continue to exist. 10:17 And I think there's a sort of 10:19 unasked question always, in, in progressive enhancement. 10:22 Which is where are you progressively enhancing from? 10:26 You know, the idea being that you, you serve a good basic experience that 10:29 works everywhere and then you enhance as 10:33 new technologies are detected in the browser. 10:34 But you're bound to have, have set a cutoff like we don't 10:37 care about browsers older than this because, you know, no one's using those. 10:40 And actually there is a native, there is 10:44 native support for doing that in the browser. 10:47 The problem is it was fixed to a 10:49 particular cutoff point which is the existence of JavaScript. 10:51 So the no script tag offered us an ability to 10:56 serve alternative content to browsers that didn't meet a quality threshold. 10:58 The problem is we couldn't move that quality threshold. 11:02 So, and that quality threshold is now in a position that's completely useless to us. 11:05 So I'd really like to have that kind of no script 11:09 capability but to be able to put it wherever I want. 11:12 So that we can decide what browsers meet 11:15 our quality bar and what don't, and which don't. 11:18 And finally, we want to make something that is so easy, that we 11:21 can hand it to an agency to build a website for the FT. 11:25 They've never worked with us before, and then they 11:29 can use it within an hour without talking to us. 11:32 Which is quite an ambitious target for ease of use. 11:36 So we took all these things and we made something that we call Origami. 11:40 So Origami isn't a framework because that would be to create something monolithic. 11:46 So it's a specification. 11:50 It's a document that describes the best practices that we've agreed to to share. 11:52 And, it's a suite of tools, that help us to stick to those best practices. 11:58 And, it's a whole load of components that 12:04 we've built using that, that, those best practice guides. 12:05 So, I'm going to dive into the spec, first of all, and talk 12:09 about a few of the the, the highlights from the decisions that we've taken. 12:12 And then give you a demo of some of the tools that we've built. 12:16 So first of all we have rules to deal with the weight of ease language and syntax. 12:20 So in JavaScript for example, we have 12:27 rules around Not using globals, not modifying the 12:28 DOM on parse and outside of areas that you expect that model to be responsible for. 12:32 So if I use a component that's built by a colleague and I 12:38 haven't spoke to them about, you know, to make sure they did it well. 12:41 I can be confident, that putting that code into my bundle, won't slow down my pace 12:46 load and the it won't interfere with anything on, on the page unexpectedly. 12:51 We also name space for our events so that we can be 12:59 sure that two developers building components 13:03 won't name their events the same thing. 13:05 And of course we have standards for things 13:07 like static code and analysis tools like jsHint. 13:09 CSS is actually a little more interesting. 13:12 Because CSS doesn't really have scope in the same way 13:15 that JavaScript does, we have to do a lot more namespacing. 13:17 So we care about adding namespace prefixes who are like classes. 13:21 And we have rules about not styling out of namespace. 13:25 So, for example, if you have a 13:29 gallery component that requires a basic box component. 13:31 The gallery is not allowed to re-style the box. 13:34 It can take the boxes styles, mix them into its own classes, and re-style those. 13:37 But it is not allowed to, to re-define the definition of box. 13:43 Because the box might be used by another component. 13:48 Specificity is another thing that we need to be very careful about. 13:52 And if you look at some of the legacy products that we have to support you find 13:55 you know the usual problems with specificity wars, where 13:59 things are fixed simply by making them more specific. 14:02 So, in starting this project we try to set up 14:06 rules that will try to ensure that that doesn't happen. 14:10 So using them, lock in a modifier syntax to 14:13 reduce our CSS selectors to one single token where possible. 14:18 And where we're using raw HTML tag selectors, we'll generally use them with 14:23 a descender operator to make sure that we don't target more than we intend to. 14:29 We have a list of states that we we consider when we are designing. 14:35 So this has been really helpful for 14:39 collaboration between the developers and the design team. 14:41 Because we now have agreed exactly what we mean by active, and 14:44 selected and focused and busy and disabled and invalid and so on. 14:47 And these are the interaction states that we care about. 14:53 And when we, when we implement those interaction states, 14:57 we use the correct ARIA roles to describe them. 15:00 And finally another thing I thought I'd 15:04 mention about CSS is how to do responsiveness. 15:06 Because components and component authors can't tell. 15:09 Where that component is gonna be used in the page. 15:13 There's no point in, in putting media queries into a component. 15:15 Because I could have a component that might be 15:19 on the, the, the full width of the page. 15:23 But equally, the developer of the page that's using my component might put 15:25 it in a box that only occupies a small part of the page. 15:28 So the media query if it's inside the component isn't necessarily gonna work. 15:32 So instead, components export mix ins that allow you to restyle the 15:37 component in a number of different visual styles that are generally different sizes. 15:42 And then, the developer of the product that is 15:47 embedding the component can write their own media queries. 15:50 And can select the different visual styles of 15:53 all the components on the page that they want. 15:56 And that's a little bit of work for the product developer, 15:59 but it means they get same breakpoints that exist at consistent 16:01 locations, and that they can control exactly what the behavior of 16:05 the components on the page is when they hit those breakpoints. 16:09 We also have a standard build pattern. 16:13 And this is really important because it means that we can consume, 16:16 large dependency trees of components and build them all in one build step. 16:19 It means that we don't, ever have, repeated 16:24 code within our, our built JavaScript little CSS bundles. 16:27 Everything is, is guaranteed to only be included once. 16:32 And this pattern consists on the JavaScript side 16:34 of using common JS for our module format. 16:38 Browserify to convert those modules for use in the 16:42 browser and Closure Compiler too produce minified concatenated bundles. 16:45 And on the CSS side we use SASS which does all of the above, and we're using Bower to 16:50 require all of those modules into a a flat 16:56 components directory which we can easily deal with to produce those bundles. 17:02 And the final point on the spec that I want 17:09 to talk about is the cut, the cuts the mustard technique. 17:11 This is a term that the BBC responsive news team came up with to describe the 17:14 idea of running a very simple test in 17:19 JavaScript to determine how good the browser is. 17:22 And this is where we bring in this new quality threshold. 17:25 Rather than just does this browser support JavaScript? 17:28 We now care about whether the browser supports enough 17:31 JavaScript to make sense for us to run it. 17:34 So if it doesn't we actually run no JavaScript at all. 17:38 And that leaves us with a website that we describe as core experience. 17:41 Something which works. 17:46 It provides basic you know, pipe link based navigations through everything. 17:48 And its a great fall back for all the browsers, for search engine crawlers 17:53 for users who use JavaScript doesn't work for some reason. 18:01 Maybe they've had a firewall or 18:05 Misbehaving network operator interfere with it. 18:09 So, there's a lot of cases that are covered 18:13 by having a decent core experience that works without JavaScript. 18:15 And then, for those browsers that do pass 18:18 our test, we can progressively enhance within what 18:20 we call the primary experience to provide different 18:23 levels of experience for, for different qualities of browser. 18:26 But fundamentally we acknowledge that we are progressively 18:29 enhancing from a point, and that we can 18:32 move that point as browsers become less popular, 18:34 and we can drop them in to core experience. 18:38 So an example of how cutting the mustard works, 18:41 is oh, okay, this doesn't navigate with onJSDown, sorry. 18:45 [INAUDIBLE] Okay, so an example of how cuts TheMustard works is simp, as simple 18:50 as this, you literally write something incredibly 18:55 simple that will return a true or false. 18:58 And you want it to be incredibly simple because you want it 19:01 to not crash or become a problem in very, very old user agents. 19:04 This is something that you want to work absolutely everywhere. 19:11 So, those are the harlots of the spec. 19:16 There's a ton more content to it, and 19:19 you're very welcome to read the whole thing. 19:21 It's origami.ft.com. 19:23 So I thought I would also show you some of the tools 19:26 that we've made to help us implement components that are spec compliant. 19:28 And this is that these tools are really critical to the whole thing. 19:33 Because if you produce a big document of rules and 19:37 you say, you know, thou shalt stick to these rules. 19:39 That actually is quite difficult to enforce. 19:42 So, the easiest thing to do is to make some tools 19:45 that make it easiest to do that than to do anything else. 19:47 Because if you make it easier for someone to do what you want them to 19:50 do, what you don't want then I like you to do what you want anyway. 19:52 So the first tool is the registry, this is a, 19:57 a website that lists all components that we have it is. 19:59 A self-discovery mechanism so you don't have 20:04 to register your component with the registry. 20:06 It will go and scan all of our GIT 20:08 locations and it will find things that look like components. 20:10 And then when it finds them it will test them, and 20:14 if they are valid components it will list them in the directory. 20:16 Which provides a huge incentive for component developers 20:19 to stick to the letter of the spec. 20:22 Because if they don't there's a good chance the registry 20:24 will kick out your component and say this is not valid. 20:26 The best way actually of showing the registry is just to, to demo it. 20:31 It is a public website so you can look at this as well. 20:35 [BLANK_AUDIO] 20:39 Hopefully the WiFi will work. 20:44 Okay, so this is the Origami registry. 20:47 You can see we've got a fair number of components in here already. 20:49 And I can show you some examples that we've made. 20:53 So let's have a look at gallery for examples. 20:57 okay. 21:01 That didn't work. 21:02 Maybe it hasn't loaded yet. 21:05 [BLANK_AUDIO] 21:06 Should chose a simpler one really. 21:08 These will also expand when they finish loading to exactly 21:11 the right size but, let's load it in a new tab. 21:14 Okay ,so we have a gallery component fairly straight 21:18 forward most media companies will have a gallery component. 21:21 In fact they'll be lucky if they have less then five. 21:23 And we've got a nice time line down here and it's also touch friendly, as well. 21:28 So, this is a great example of where, if you hadn't built as 21:34 a component, and you needed slide show functionality as part of a product. 21:38 You probably wouldn't have bothered to put the touch support in, if tablets and 21:41 phones weren't your, your sort of key 21:46 audience for that, for that particular product. 21:48 So, by using a component where we thought about all of 21:50 these best practices, and encapsulated them all in something that's reusable. 21:53 We can provide a great experience a great gallery experience everywhere. 21:57 This is of course seeing you believe galleries 22:02 are a good idea in the first place. 22:05 So slow [SOUND] let me show you a slightly simpler component. 22:07 [SOUND] Let's have a look at buttons. 22:14 So as well as giving us rich UI components that we would use for very specific 22:19 purposes, but we also have much lower level 22:25 components and even more lower level than this. 22:28 But this is an example of a component 22:32 which gives us our, our standard FT-buttons styles. 22:34 So let's say I wanted to generate the CSS and markup that, that does this right now. 22:38 I would need to go find the buttons component, check it out. 22:46 Well, I'd have, first I have to install NPN 22:52 in Bower, and then I have to Bower install. 22:55 The buttons component, then that would go and 22:57 fetch all the dependencies of the buttons component. 23:01 Then I'd have to run a browser file. 23:03 I'd probably have to set up the Grunts or Gulp 23:06 first to make sure I can do all of those steps. 23:07 And then that would produce me a bundle, which I would then 23:10 have to cash and serve through a web server of some kind. 23:12 And that sounds like a lot of work! 23:15 alternatively, we could use our other tool that we've word got at [INAUDIBLE]. 23:19 So, I'm gonna take this code which is the mark up 23:23 that produces these buttons and pop it into a JS bin. 23:26 If I can make JS bin work. 23:29 Huh, that's interesting, don't know what that's there. 23:36 Probably not the worst things that could have come up in JS bin. 23:39 [LAUGH] 23:41 >> okay, so, by default, this is gonna give me some standard browser buttons. 23:43 So this is not very exciting so far. 23:48 But if I go down a little bit further on this page, the next 23:51 section I see is a quick start section, and it gives me a link tag. 23:55 And let's copy the link tag. 23:58 [BLANK_AUDIO] 24:00 And we get our solid buttons, magic. 24:07 So, what happened there? 24:09 Let's go out to the notation and I'll talk about it. 24:12 [BLANK_AUDIO] 24:14 So, what you just saw was something called the Build Service. 24:18 And it is a node application that will take on 24:21 the query strain, a list of modules that you would like. 24:25 And it will go away and do all of that, all of that process that I just described. 24:29 It will use bower to install the module, 24:34 it will install all the dependencies, it will run 24:35 it through browser fight, it will do all of 24:38 the best practices that we've put into the spec. 24:39 And then it will serve it either on HTTP or ACPS 24:42 as you like and it will push it through a CDN. 24:45 So everything that you could want from something 24:50 that would build your front end dependencies for you. 24:54 And another great thing about this is you can 24:57 specify the version of the module that you want. 24:59 So in this case I'm saying I want version 25:03 one three seven of Header, but I prefixed the version 25:05 version number with a carrot which means that I'm 25:09 prepared to accept any version up to 3.9 including two. 25:11 So you can be very flexible about exactly how risk averse you are. 25:16 If you're building a product that's, let's say a stand alone 25:22 interactive graphic site and you want to freeze it in time. 25:25 And, you want to make sure that it never changes, never breaks. 25:29 You can specify the exact version. 25:32 And, even when later versions of this component are released, the build Service 25:34 will always be able to build 25:38 that particular version or that particular module. 25:39 Alternatively, you can leave the suffix completely blank. 25:42 Like, I've done in our Tweet. 25:47 And that's saying well, I don't care. 25:49 I'll take major version updates, that's fine. 25:51 So that's fairly risky. 25:54 It could be break the API completely but you, 25:55 it might be something you wanna do safe analytics. 25:58 Where you're are intending to interact with the modules API at all. 26:00 You're just gonna let it do it's thing. 26:04 So in that case maybe a major version update is gonna be fine. 26:06 So you can choose and it, it gets 26:09 you started with new projects very, very easily. 26:11 This instantly is also a great way 26:14 to retrofit components to existing websites that don't 26:16 have a build process because you can very quickly just slot in a, a built code. 26:19 I'm gonna use the last section. 26:24 Of my talk to talk about some of 26:29 the tricks we've developed as part of this project. 26:30 So we actually found, we have to resolve some problems that we already thought 26:34 we had solutions for, because in a 26:39 component world those solutions no longer make sense. 26:41 And the first example of this is Polyfills. 26:44 We go. 26:47 Back to full screen cuz I moved [UNKNOWN] okay. 26:48 So components are developed independently. 26:55 We can't make assumptions about what else might be 26:57 on the page that that component will ultimately be on. 26:59 So if the component requires a Polyfill. 27:02 Let's say the J sub t polyfill or the query select polyfill. 27:04 Should it shit with that polyfill? 27:09 Well if it does that than presumably other components might 27:11 also include the same one, and then we've got co duplication. 27:14 Or we could create a module that contains 27:17 that polyfill and express a dependency on it. 27:19 But if we do that, than we won't get the 27:22 co duplication, but we will get the polyfill come or may. 27:25 And actually, we'd really rather only serve 27:28 that polyfill to browsers that need it. 27:30 Don't really want to serve it to browsers that already have that feature. 27:32 So we decided to create a metadata file for each component. 27:35 And one of the things in that mass 27:40 data file is a list of required browser features. 27:41 So, this particular component is saying, I need post message and local storage. 27:44 Otherwise, I won't work. 27:47 I'll just break. 27:49 So it's then up to the website, that 27:51 integrates, that integrates that component to provide those features. 27:53 Either by not running the JavaScript in 27:57 browsers that don't have them, or polyfilling. 27:59 We express those requirements instantly as Modernizr test names so they're 28:03 not just random strings, they actually link to something that mean something. 28:07 And that means also that we can use 28:11 Modernizr when we write our cuts the Mustard test. 28:12 So here's an example of a cuts the Mustard Test that includes polyfill fallback. 28:16 So first when we run our basic cuts the Mustard 28:20 expression and we conclude that this browser, yes, is good enough. 28:23 So then we can test for other things that the browser 28:27 may not have despite having passed the cuts the Mustard Test. 28:30 And if those things fail, we can load some 28:33 polyfills before we then load the main application JavaScript. 28:35 I did say that I, I thought that there might be a few things in here that seemed 28:41 a bit crazy, one of the other ways that 28:45 you can do this is with service-side feature detection. 28:47 That's a very neat, I think a service called polyfill.io. 28:51 Which will, which has a very big index of user 28:55 agent strings, and it will deliver to you exactly the 28:58 polyfills that are required in that browser, which is quite 29:01 neat and it means that your front-end code is very small. 29:05 So, yeah, you could do that. 29:10 So, that's polyfill fallback. 29:15 Like, you know, we, we don't have a feature so 29:18 one of the things we could do is polyfill it. 29:19 Another thing you could do is fallback. 29:22 And that's split into two. 29:25 You could feature gate something so if, if you can't do it 29:27 then just make it appear that that feature doesn't exist at all. 29:30 Or you can do feature alternation i.e. 29:34 you can't do something, so you do something else instead. 29:37 So, the last approach is what you want to use a lot of the time. 29:41 So, for example, if you have an article with comments at the end, it might 29:44 be that we don't want to be able to accept new comments in core experience. 29:49 Because it's a fairly complicated piece of functionality. 29:53 We don't really want to support that for all the browsers. 29:56 So how do we display something else to browsers that don't cut the mustard? 29:59 You can't use NOSCRIPT because it's hard coded to 30:06 a different quality threshold to the one we want. 30:09 So instead we use a div with a class and we will 30:12 add or remove a JS class on our document element the HTML tag. 30:15 To hide or show you that content. 30:19 This actually a pretty reliable method that 30:22 works even in very, very old browsers. 30:25 What am I going to do next? 30:32 Oh, yes, so another thing we see sort of related to this is feature flagging. 30:33 So we want to. 30:38 Be able to turn various on or off depending on conditions in the browser. 30:40 One of those things is hover state. 30:44 Hover state only makes sense if you have a hoverable pointer. 30:47 Actually it was one of Paul Lewis' HTML5 rocks articles that put that sort of, got 30:50 me thinking about this and that was to 30:57 do with disabling hover effects while scrolling for performance. 30:59 But actually we're sort of slightly more interested in using it 31:03 to disable hover effects on devices that don't have a hoverable pointer. 31:07 Because if you don't have a hoverable pointer then you can actually 31:12 activate the hover effects by touch and you generally don't want that. 31:16 So, iOS, for example, has emulated touch. 31:20 Sorry, yeah, emulated hover, sorry. 31:23 Which exists because some websites require you 31:26 to hover in order to use the navigation. 31:29 You can't actually navigate the website unless you can hover over a menu. 31:32 Now we don't have any menus that are like that. 31:35 So, it makes sense that we disable hover on touch screens. 31:37 Or at least we disable hover on touch screens 31:43 that don't have a mouse, and there's massive crossover and 31:45 confusion here because f course there are lots of devices 31:50 that have both mouse and track pad and touch screen. 31:54 Or they don't have a mouse but maybe you 31:58 plug one in while you've got the page open. 31:59 All these kinds of scenarios we need to take count of so that 32:02 we don't just annoy the user by assuming something that's not actually true. 32:04 So, yes this requires detecting touch or, 32:11 more accurately, it requires detecting a mouse. 32:14 But we find that provided that you do that in 32:18 a sensible way, it can actually be a great user experience. 32:20 And finally how do we do asset loading? 32:26 So this is one of those things where is 32:28 just a no brainer if you not using components. 32:30 Let's say you have a share widget and the share widget has a swisser logo on it. 32:33 So where are you going to get that Twitter logo from? 32:38 Well you'll load it from your web server obviously. 32:40 But if that share widget is a component 32:42 and, that Twitter logo exists in the component compository. 32:45 What URL will that image exist at when it comes to be loaded from your website. 32:50 And, that's something that might vary from 32:55 one website to another, that contains this component. 32:58 So, when we write the component, we don't actually 33:00 know where we're going to get that asset from. 33:03 So, we have an assets module that helps us to resolve these URLs. 33:07 First we pass in the the path within the repository. 33:11 And, the name of the repository we'd want to get the file from. 33:15 And, we just assume that there is the the return value from that is a value URL. 33:19 And, you use it like you would any other. 33:23 And then when the component is integrated into a site, we can set 33:26 various configuration that allow us to 33:29 control exactly what happens to those URLs. 33:30 So we can say for example, well I put all my components in 33:33 the results directory, and I put this particular one in the web sub directory. 33:36 And that will then allow the assets module to resolve what the full URL is. 33:40 And that means that as component developers we are not penated 33:45 about how you as a, a product developer craft your URLs. 33:48 You can create whatever URL scheme you 33:54 like, and the components are, are fine with 33:56 that. 34:01 So, in summary, I'm actually ahead of time, which is amazing. 34:02 We have some pretty cool stuff at the FT. 34:07 In fact, the web app won best news app in the Newspaper Awards 34:10 in the paper a few weeks ago, so we were very proud about that. 34:14 Some of it isn't very consistent and isn't very well integrated. 34:17 We see web components as very much the future of the way that we build 34:21 websites, and also part of the solution to the sort of problems that we have. 34:26 So we set out to build a spec and some tools to try and 34:32 fix those problems and to get us ready for web components when they arrive. 34:35 We have lots of interesting challenges, and 34:41 working in public has been really interesting, 34:44 because it's enabled us to get a lot of feedback from developers outside of EFT. 34:46 It's also meant, interestingly, that other media 34:51 companies that also have these same problems are 34:55 very much more willing to talk to us 34:57 and explain how they're solving the same thing. 34:59 So I think ultimately 35:02 that means 35:10 that we will end up with a, a much better product. 35:15 So that is all I have to say. 35:19 Thank you very much. 35:20 [SOUND] 35:21