 I'm Rachel Andrew, as introduced, and I'm going to talk for a little while about the business side of front-end development. And I'm going to be touching on a bunch of things, and I've got a whole set of links and things in my slides, and I'll give you a link at the end that includes all of those, so you don't need to worry about copying things down. So firstly, why am I here to talk about this subject? So I've been working on the web since around 1996 as a web developer of various types. I started my own company in 2001, and that was really a sort of consultancy. We were doing web development for clients, and we mainly work in PHP. And so I've been doing client-based work since that time. And then about six and a half years ago, we launched a product, and that product is Perch. It's a PHP CMS. So now I spend a lot of my time actually working with web designers who are using our software and seeing the things that they struggle with. My background in front-end is that I was part of the web standards project at one point, so I've always been very, very keen on open web standards and pushing that sort of thing forward. But I think as someone who's very keen on standards and keen on good ways of doing things, you can get a little bit detached from what regular folk on the web are doing, and that's the thing I've learned through supporting my customers is actually what regular people are doing. People who don't read specifications and who don't kind of make a hobby of playing with CSS. You know, what are they worrying about and how are they running their businesses and how are they using, you know, front-end development actually in their day-to-day work. And the thing that's really come for me from working with the web standards project and sort of through my history is the fact that I believe that the web is, you know, incredibly accessible. It was accessible to me when I first got into web development. It's not my background. I'm an ex-dancer. I kind of, you know, grew up with the web essentially when I sort of moved over and started working and doing web design. And so that accessibility of the web, the fact that if you put, you know, an HTML document together, that's an accessible document. And so anything that we do as developers takes away from that accessibility. So we get to choose. We get to choose whether we want to protect it or whether we want to break it. But I'm also a businesswoman. As I mentioned, I've got a product and I live in the real world. And so I run a company and I'm just one half of that company. There's two of us. And so I wear an awful lot of hats. And any one day I might be doing, you know, the bookkeeping. I might be writing some docs. I'll be doing some support. I might be developing PHP. I might be doing front-end development for our site or for our product. I might be writing a puppet manifest. I do all of our operations. So I have tons and tons of hats. I can't just spend all day, you know, agonising over which HTML element to use. I'd love everything to be perfect. But often I have to just have things that are just good enough because I've got to ship. I've got to get stuff out of the door. And I have to be doing that, you know, several times a day. So today I'm going to talk about, you know, where we've come from as web developers, our history, and where we're going to. And I'm going to think about some of the things that I've seen over that time and some of the things I see people struggling with. So to find out how I'm actually the oldest person in the room, put your hands up if you developed a site that had to work in Netscape 4. I'm almost the oldest person in the room. Keep your hands up if you worked with Netscape 3. Yes, you are my people. So I started building websites when browsers didn't support CSS. And I can remember arguments in things like Dreamweaver news groups, news groups on newsnet, where people were saying, you know, should we use CSS at all? What is this funny-looking thing? Font tags are much easier. So the argument for CSS styling at all was really one, on the fact that you could style things in one document and didn't have to search through your document using whatever terrible text editor you had to replace your font tags. That's why we use CSS. It's great. And I started using CSS for layout really early on. This is a superb piece of code. This is the Netscape resize fix. What this did was Netscape 4 had an excellent bug. Basically, CSS was based on its own JavaScript style sheets implementation. So CSS didn't work unless you had JavaScript turned on. And also all kinds of funny things used to happen. If you resized the browser window of a page that was using CSS for layout, any absolute positioning, basically, all the positioned elements would stack up in the corner. So we had to get around this to reload the page. And so this bit of code was included in Dreamweaver. It was a Netscape resize fix. The thing was we'd find this line around years later, long time after anyone had used Netscape 4, because I mean like who doesn't want to fix Netscape. So our kind of job back then was we were browser bugs experts. That's what we did. We had these dreadful browser bugs. We had limited CSS support. And that was really what we were doing. We were working out how to do modern things, modern at the time, while dealing with these browsers that had very limited implementations of CSS and the implementations they had had absolutely bizarre bugs. As I mentioned, I was part of the web standards project. I was actually brought into the web standards project along with my husband Drew McClellan and we headed up the Dreamweaver task force. We spent quite a bit of time working with Macromedia, who had Dreamweaver back then, and trying to get Dreamweaver to essentially output standard code by default. You know, we wanted it to out of the box develop decent enough code. And that's the archived Wasp site where you can sort of read the original mission. And Wasp eventually closed down because that original mission had kind of been met. The standard things these days are pretty much being implemented in a standard way, which is what we asked for. You know, we wanted browser vendors to look at the spec and implement in the same way as every other browser vendor so that you could build in one browser and it would work in another. I mean, obviously browsers don't always immediately support every new CSS spec that comes out because that's not realistic. And different browsers have got different priorities. When something is a standard, it's being implemented in a standard way. And we're seeing innovation through the standards process. Last week I was at the CSS Working Group meeting in Paris and I was sat there in a room full of browser vendors all deciding how things should work and also bringing their own ideas to the table and the things that are important in their browser. You know, we saw a specification which is CSS rounds display specification which is for CSS on round watches and things. Fantastic early stage specs and this innovation is happening through the CSS Working Group and through the standards process rather than browser saying, we've got this new thing and we're not telling you about it because it's our competitive advantage. So kind of what do we do now? Is developing for the web getting easier? Is our job just easy now because browsers work well? Because we're not browser bug wranglers anymore. And there's certainly a lot of people now piecing together bootstrap templates. They would call themselves a front-end developer maybe but they're really just piecing together other bits of code. So will professional front-end developers find ourselves without a job because anyone can download bootstrap, anyone can just put something together. And I kind of think that this, the growth in the number of tools and processes that we're seeing is somehow a bit of a reaction to that because we want front-end development to be taken seriously. You know, I don't want someone to think, oh well if you're just a front-end developer, you're not really a developer, you're not really a programmer, you're not really an engineer. So we want what we do to be taken seriously. It's still development, we're using OO principles, we're creating frameworks, we're creating tooling. And we're creating an awful lot of complexity along with that. And I think we're in some way taking a bit of a step back from the real languages of the web which are relatively simple. So we're not writing CSS, we're writing SAS because it's cool, it's got variables, it lets us do some cool stuff but maybe we're not looking at the output that it creates and maybe we're not looking at that with a critical eye that we would have done a few years ago. We're using frameworks that sometimes just dictate the markup that we have to use. Whereas a few years ago we might have cared a bit more about that markup. And we're using JavaScript libraries that include vast amounts of code and we just want to do some trivial thing that we could have just written in JavaScript. We're kind of abstracting everything, we're creating abstractions, abstractions on abstractions and we're making things very, very complex a lot of the time. And interestingly, while we're creating abstractions and avoiding working directly with our core languages, those languages are actually getting more useful and more elegant under the hood. I mean HTML5 now lets us move away from wrapping everything in a div element and instead we can mark things up semantically and we don't need plugins for audio and video. You know, HTML5 video is fantastic and it even includes things like closed captioning. You know, we can add timed subtitle tracks using Web VTT to our videos. We've got forms that validate our data with the HTML5 form spec and we can make use of operating system and browser features. You know, use type equals color in a form and with a supporting browser you get a color picker. That's pretty cool. And if we look at CSS, you know, we've got selectors that can accurately target bits of the DOM. And the level 3 selectors spec is pretty much supported in modern browsers. You can use this stuff. And the level 4 spec, which is still in development and things change all the time, I was listening into discussions last week about it. But we've got things like, you know, time dimensional pseudo classes which unfortunately don't involve any time travel. But those Web VTT caption tracks you could style those based on timing so you could fade a caption in and out, for example. Or highlight the line that's been read in a document to the user. There's loads of really cool stuff that you can do there. I've been doing quite a bit of talking recently about layout for the web and I mentioned right at the top of this talk about how layout was really difficult way back when. And layout actually for the web kind of stopped for a long time. We've been doing stuff with floats and things. And recently, of course, we've had some new stuff come into the spec and start to come into browsers. And obviously this is Flexbox, the flexible box layout module, which moves us away from a reliance on source order. Which is something we've always asked for, this being able to separate content from presentation. And I've been doing a lot of work about the upcoming CSS grid layout module. Which is a really exciting module because it gives us a native grid system in CSS for the web. This talk isn't about grid, but I think it highlights an interesting point. So if I've got some markup like this, I can set each element up as a grid area and just give it a name. I then declare a grid on the wrapper element, define the grid of columns and rows, and then place my areas with grid template areas. It's sometimes referred to this Asciart syntax of layout. You're describing your layout actually as the value of that property. So there's no floats, there's no positioning. Because the layout's all in CSS, the grid can be redefined within media queries and where the items sit on the grid. They can also be redefined. So you can move things around depending on the size of the screen. I've got a whole bunch of examples of this. The site's actually on GitHub so you can play with it. Grid layout actually only works in... It's behind a flag at the moment in Chrome. There's an early implementation in IE 10 and 11 which surprises people. Grid actually came from the Microsoft team. Some of the ideas that are in it have been around for a while, the template areas syntax. But grid was really pushed forward initially by Microsoft implementing it in IE 10. And it's now behind a flag in Chrome so you can actually play around with it. And the spec's hopefully going to be finished this year. So we'll be starting to see grid in browsers fairly soon once it gets out in Chrome. It's also been implemented in WebKit. So grid's something that actually is coming very soon. But the point is I've been putting these examples on because the CSS Working Group want feedback on grid. They want feedback on how we might use it. They want feedback on naming. You know, as simple as does this make sense to developers if we call this property this thing, they're asking for feedback and no one is giving feedback. So I put together those examples really to try and prompt feedback for grid because I think it's important that people talk about this stuff early. And I get emails all the time oh well I'll take a look once there's a sas mix in. I'm like why do you need a sas mix in to play with an experimental spec and what point is that? But people have only learned sas. They've not learned CSS and so they actually don't know how to look at grid because they don't understand where that's come from and that to me is quite frightening. Especially because grid removes a lot of the requirement for preprocessing. We're using preprocessing for layout a lot of the time to remove the complexity of figuring out how to do floats and figuring out how to do calculations. And once grid's live I'm sure there are things that preprocessors can do to make our lives easier when we work with it but there's certainly not a requirement to understand it. So at the moment I think using a preprocessor is probably the best way to deal with layout on the web and this is the Susie grid. So this does all the calculations for you to do grid based layouts without needing to add a bunch of classes to your markup. Do you know when you use bootstrap grid or whatever quite a lot of the popular grid systems you have to add these sort of low classes to your markup. Which is one way of doing things. The problem is if you want to have lots and lots and lots of breakpoints how many classes do you have to add to your markup to kind of represent all of those. So Susie let's get away from this, it's pretty cool. And there's a great tutorial here which walks you through creating this very complex grid which is pretty impressive that you can do using current CSS methods and it shows you how to do that with Susie. And you could obviously write the CSS yourself and calculate it at all but that would be hard and time consuming. So you know, great, this is a good use for a pre-processor. So you lay the blocks out using SAS and then when you compile you get your CSS with your flexible widths all calculated. Very very good. But I replicated this using CSS grid layout. And I did that without needing any pre-processor without any really complex calculations. And that's an example of the code but the full code for that is is on mygridbyexample.com website. It's actually very very easy with grid to do these complex grid layouts. And you know, this is the future of what we're doing in CSS for layout. And I think you know designers and developers should be all overspecs like grid. It's in development, it's in browsers you can play with it. All you've got to do is switch a flag in your browser and have a fiddle with some examples. And yet people aren't all over it and people aren't looking at it and then what will happen because I've seen it happen time and time again is it will get into browsers, we'll be able to use it and then people say this syntax sucks. And the CSS working group will say why didn't you say anything? Because people aren't looking at this stuff at the point at which you can get involved and it is easy to get involved. They're interested, they're interested in our involvement these days. So perhaps we're leaning on frameworks to mask the issues that we've got with CSS so we kind of forget that there are issues with CSS. Because if you use a framework, if something sorts out all of the difficulties of using floats then you don't think hang on, why are we doing layout in this terrible way? We're not something better. And so you don't get frustrated enough to try and make things different. It's only by working with the specifications by getting down to the metal of this stuff that we can start to improve them. You have to understand to be able to push the web forward. The web standards movement was totally driven by frustration. We were so fed up of building two websites, one for Netscape one for Internet Explorer. We were so fed up that we were nothing to become experts in browser bugs. Rather than be able to be creative and do interesting things we were spending our days just working out why Netscape was doing this. Working out why Internet Explorer was making half of our content disappear. That frustration led us to petition browser vendors. It led us to produce things like the browser upgrade campaign which kind of was probably a strange choice but at the time we were asking people to basically block the content from people who are using Netscape 4 to try and push people to upgrade their browsers because it really was holding back the web. And there was mass adoption of that by web developers. So we were kind of fed up and we used our skills to push things forward and I think we're in a lot better place for it. There were plenty of things wrong with the web today but we're not having to build two websites. We shouldn't have to be building two websites like that. So my concern with all of these abstractions and frameworks isn't that they can be used to build terrible websites because you can build a terrible website with vanilla HTML and CSS. You can make a terrible mess with JavaScript and sometimes libraries and frameworks prevent people from doing terrible things because they'll deal with security issues and so on. But my biggest fear is that we're not pushing for better solutions because we've got these frameworks and someone from the CSS Working Group said to me a lot of the push for layout hasn't come from web developers. The push for layout has been coming from ebook publishers because ebooks are a lot of them now, developed using HTML and CSS and there are specifications for the CSS for doing print and PDFs and they're pushing for better layout tools because they want to be able to do magazine like layouts and things using CSS and it's not possible. So it's interesting that as a community the working group aren't thinking oh you know web developers are asking for this and if you start to look at the discussions that the working groups have they talk about are there signals from the community? Are the community asking for stuff? If the community aren't asking for it then maybe no one needs it and so we don't get a better web. So my second concern is that by taking a step back from our core languages we're kind of passing the book where certain elements of our work is concerned so that might be in terms of creativity you know we're not solving problems we're just tweaking bootstrap and it might be in terms of technical decisions we might be saying well I'm using this framework and it means I have to do this it means I have to put this stuff in my markup it means I have to structure my markup a certain way so we're making these technical decisions not based on what the core languages can do not based on what our browsers can do and those things are getting better all the time but based on what potentially an arbitrary choice of framework can do and I'm not saying that compromise is wrong there's always compromises to make to say we don't live in a perfect world we all have to ship stuff we often have to do things under all kinds of constraints but I don't think the compromises should be the same for every single project and they will become the same for every project if you use the same framework for every project and there's a lot of sense in standardising on certain tools that's good business sense learning something and using it well and build up good knowledge in your agency or whatever how to use it that's cool but I think you need to always take that check and say am I just using this because we always use it or is it really the best tool for the job and using these things should not be at the expense of learning the core tools of the web it shouldn't be at the expense of knowing HTML well of knowing CSS well of knowing javascript you know you should be able to sit down with a tech senator like we did in the old days and build a simple site and I know that people can't I know that people who are professional front end developers and they would not be able to sit down and build a simple site and that is really worrying because if they can't do that they can't understand what these frameworks are doing and it's the same as people learning jQuery instead of using javascript you're learning SAS instead of CSS learning Bootstrap's grid system instead of the fundamentals of layout there's a huge difference between the person who knows HTML, CSS and javascript well and then pick a tool because it saves them time or whatever else or it makes a certain project easier and the person who uses the tool because they couldn't build it themselves there is a huge difference in those two people these single tool experts get really angry on Twitter when someone says oh I don't think that tool is doing that in a really good way and they have to defend it because essentially their job is tied up in using that tool and it's the same with programming languages I was a pearl developer and I've worked in classic ASP I now write PHP and people like to have a go up PHP I go up PHP's terrible language and I'm like it works for what we're doing it's not supposed to CMS it's written in PHP because that's what's on the hosting but if PHP were to disappear tomorrow I'd just learn something else because I know how to write code I understand the fundamentals and understanding the fundamentals of what you do is hugely empowering it makes people worry that there's this pace of change there's a new thing that appears every day a new framework and how are we going to learn all this stuff and in the rest of this conference you're going to hear probably new things things you haven't seen, should I be learning this should I be learning grunt or gulp or what should I learn next if you know your core tools if you know HMA, you know CSS you know JavaScript it all looks far less scary because if a tool comes along you can assess it against that knowledge will this help my workflow I'll give it a go maybe not at the moment I didn't learn SAS for ages because I didn't actually need it and then a project came along I was working with some other people and I thought this could be quite useful to help us structure our workflow and so then I learned it you don't need to learn every new thing if you've got the core knowledge downright because you can always build a website at the end of the day these things are creating HTML, CSS and JavaScript and that's all you need to know when you develop for the web the rest of it is just workflow and it's just whether that works well for you and your team these fundamental languages are timeless it's not so different what I'm doing now to what I was doing back when we first started learning CSS when we first started using CSS it's not worlds apart we've got a whole lot more stuff we can do some really cool stuff but I'm still building websites so know those core skills well pick them up and put them down as you need to and you'll not find yourself scrambling to relearn your entire skills and your entire stack just because some tool falls out of favour I've got one bit of advice for newer and younger developers today it don't become an expert in one tool to the exclusion of everything else learn those timeless skills and then choose which bits you want to specialise in it's a good understanding of these core languages is that the heart of us has been able to make sensible decisions about what to use for our projects and what else do we need to consider as well as the tool that we like to use and the processes we want to work with and part of this problem are people becoming very evangelical about the tools they use because they're very wedded to them means there's an awful lot of noise isn't there if you ask you know which is the best framework to use which is the best CMS which is the best pre-processor you're going to get a bunch of stuff you're going to get a lot of noise you're going to get a lot of people saying well this is the best and this is the best and having an argument with each other and it's really hard to ascertain what should I be using and whichever you pick someone is going to tell you you are wrong and you should have used this other thing so having those core skills lets you just make better judgement it lets you step back and say well if I was going to build this totally by hand this is what I'd want to end up with you know which of the tools gets me to that point and with these decisions I think something that isn't often talked about is the differences in terms of how projects are developed and maintained so everyone's talking about a certain tool they're talking about a certain library or a framework but you don't know if those noisy people are developing projects that are like yours you know are they working in a great big team are they just a solo developer it's very difficult to know and I think that's not talked about enough because the things that work well if you are a team of 50 people working on a big product those are very different things to if you are just one or two people perhaps you know working on a project where only you ever touch the CSS or perhaps you're working on a project where you need to hand that over to a company perhaps you're working on a project where you need to hand that over to a client and they're going to have to maintain it that's very different from building something in-house so this is a poll from Chris Coyer's CSS tricks site I'm just asking you know how many people touch the CSS in your current main project there's quite a spread there of different ways that people are working so a freelance web designer might design and create a site completely on her own and then she might maintain it but she might not I mean we used to build an awful lot of stuff where we would build it and we would just hand it over to an internal team and they'd be looking after it so how responsible is it to use the latest trendy framework or the latest preprocessor or whatever on something which you're going to hand over you should certainly at least be having that discussion with whoever you're handing it to and making sure they're going to be able to cope with it it's a lot of the reason why we stayed with PHP when we were doing client work is that we found that that was the easiest thing to hand over because the client could find themselves an inexpensive PHP developer whereas if they had to find a Ruby developer they were typically and certainly at the time were a lot more expensive and harder to find so it's that responsibility that you have as a developer if you're handing something over and you use something which is brand new will it even be maintained in a year's time will the client be able to find a developer who can take the work on and sites developed by huge teams they've got completely different issues you need process if you've got 20 people touching the CSS you need process because CSS is not great when multiple people work on it it's not really been designed for that so you need at least some process and things like few processes and so on really really handy because you can concatenate together everything later people can have separate things to work on there's a lot of stuff you can do and decisions can be made differently in big teams especially if you're keeping the thing in house you're going to be working on it you can make decisions that just suit that project because you don't need to worry about handing it over to another team you're going to be working on it so you might want to use something that's really cutting edge because it really works for that project and that's fine you could potentially maybe fork that open source project and develop your own fork of it if you needed to because it's just yours you're building if it's an internal audience you're building a dashboard you're building an intranet type of thing you can often make very different decisions there than if it's going out onto the web it might be that you know that everyone using the application that you're building is going to be doing that on a tablet out in the field they're going to be using an iPad you can make very different decisions there than you would for something that's just going out onto the web it's really important to keep an eye on this the web and what we can do is changing so quickly flexbox for example you can pretty much use as long as you don't have really old browsers coming to your site modern browsers have got great support for flexbox and it solves an awful lot of tricky problems if you know that your site is visited by really pretty much modern browsers you can use it the site for my product is visited by web designers they all have modern browsers I think we've got 97% of visitors or a browser which is capable of using modern flexbox it's not the case for the actual product itself because the product admin is used by end clients editing their websites and so some of them might have internet explorer 8 so we can't use it there really important to look at what has come into the site so you can choose the technology well but also what time have we got available can we carefully handcraft something you know does that matter or you know do we have to work out how we can really you know use tools to give us a bit more time but when it comes to time who's time are we actually saving I think we're very very keen as developers to optimise our time to make things quick to code to you know sort of optimise our experience as the person developing the site and sometimes that's at the expense of users because we're the wrong thing to optimise if you've got a choice because we write code once and then it's run thousands and thousands and thousands of times in the browsers of our users so if that optimisation that saves you a bit of time causes the site to crawl causes everyone to have a terrible experience causes people on mobile not to be able to download it that's not a good optimisation and so that we need very careful about looking at these tools and saying okay this saves me masses of time, that's great but are we optimising in the right place by using them old standards nerds have good thoughts on this this is Aaron Gustafson he's another web standards veteran and he's as worried as I am about this trend to make developers lives easier rather than those of our users and this increasingly matters with so many people now accessing the web on mobile around the world there's a real business case to be made for making your site very accessible on limited devices and unlimited bandwidth so this is a slide from we are socials compendium of global digital statistics and it's really worth taking a look at if you need to convince anyone in your company why this stuff matters so there are parts of the world where the reality of web use is mobile and when we're talking mobile we're not talking about like our use of mobile which might be the latest iPhone on fast connection we're talking about feature phones on slow connections and very limited data and that's the only way a lot of people are actually accessing the web so this is what it comes down to you know if using that shortcut using the plugin or the framework or application if it's not going to cause huge accessibility problems if it's not going to cause huge downloads on mobile then for me go for your life because it's not causing anyone a problem but if it will if the only way to get the all singing all dancing application that you've sort of got in your head is to make these huge compromises then maybe you need to look at another way of getting to the end result and often try and kind of justify our shortcuts by saying oh this is only temporary you know this site will be replaced you know and I don't know but I did a lot of client work and I built lots of things that I was promised were going to be temporary and you look back five years later and there it is usually still the same content as well but things aren't as temporary as sometimes we think they'll be on the web you know and also sometimes you end up maintaining that temporary thing forever because once it's up there they're like well it's all right it works you know we don't need to update that and so you end up maintaining this dreadful, crufty thing on an out of date framework on an out of date library forever because there's no money to fix it and you know this stuff matters to me I've always chosen to protect the inherently inaccessible nature of the web because I believe the web is for everyone and that's for the person in the country where they're using a feature phone and they've got very very limited internet connectivity and they're using the web to learn and to expand their horizons and to build their business you know from that phone I think that's really really important it's important that we all get to use the web and all of us worldwide I think it's hugely empowering it's been incredibly empowering in my life you know I got into the web when I was next down so I didn't have any other skills and I started teaching myself web development and it's been huge in my life my ability to make a living and I think it can be for so many other people so the best way I know to protect the web is still this term progressive enhancement that's at the heart of these choices it's at the heart of the choices that I make this quote is from the BBC Future Media Standards and Guidelines these state that the core experience of every document should not require javascript or even CSS to function and that's where we start with progressive enhancement we start with structured HTML and I travel quite a lot and I'm always on like terrible hotel wifi and it's when you're on terrible hotel wifi that you realise how terrible the web is and like you load these pages and nothing loads you know I was trying to find the details of the restaurant last night and all I could get was a black web page because it was all images and fonts and none of it loaded whereas if you start with very basic HTML and you make sure that doesn't happen at least I could have got the markup I would have got something I could have found where it was just from reading the plain HTML so we start with well-structured HTML and then we layer on the experience for those users and user agents that can support it I think we think of progressive enhancement as being this thing that happens in the browser we've built a progressively enhanced site and therefore we start with the HTML and we add on all the other bits but I think it's deeper than that it's at the heart of our processes it happens right through the stack and when we're talking about the business of what we do what's the core experience what's the core experience that your site or your app needs to provide there's rarely a business case for kind of bling and for showing off I was talking earlier this week at a business conference the things that build businesses are not flashy websites not at all so that kind of matters less than you think so what is the core experience that you need to deliver through your app on your website instead of looking for a magic tool that gives you an all-seeing or dancing UI but only with one day work we can develop a basic but usable thing first and ship it and then add to it it might not have every possible feature at the start but it works and it's accessible so we ship things and then we iterate and we're iterating on a solid base we're not throwing up something that looks amazing and promises a lot but then just doesn't work and then we're kind of having to fix all the bugs in that because it works poorly on mobile or it looks out-users of assistive technology and then we're kind of backtracking and saying oh yes accessibility is coming accessibility should never be coming that should start that should be at the core and that's kind of how we approach the purchase interface now purchase is downloadable it's like WordPress you download it so actually getting people to upgrade is kind of hard because they've then got it and you have to kind of encourage them to upgrade but we focus a lot of effort on the admin experience because I think that content editors a lot of the time are kind of the forgotten users of websites we worry about the the web pages on the front end and we worry about us as developers and the people editing the content are kind of like yeah we've got this awful CMS to use so we try and get away from that so obviously we care a lot about admin UI so it was very tempting for us to want to create a really snazzy JavaScript UI and do also to clever tricks and we launched purchase six years ago and we've continued to iterate and we do use JavaScript in our UI because some things are enhanced by it like assets management and so on yet the whole experience works without JavaScript because that's what we started with we started with this very plain user interface that just worked it all works without JavaScript and one of the things we love is every now and again we'll have someone drop us a line and they'll say oh you know I delivered this site with Perch to an organization and then they told me they've got a user who needs to use the CMS who uses a screen reader and I was really worried because these things don't normally work with screen readers but they're telling me how great it is now to me that is a win if someone with a screen reader can use our stuff without us we've never tested it with a screen reader I'd love to do full scale accessibility testing on it but we haven't as yet but because we've built it in a progressively enhanced way someone with a screen reader can use our software and we kind of got that for free essentially just by doing things the right way and I love the fact that despite the fact that there's two of us and we're trying to do a million things by working in a good way and I think that's really cool but what about all those third party plugins frameworks and so on so how do they fit in they're not all bad how do we sensibly combine them with our work now I imagine that most people here understand this idea of not invented here syndrome this is the idea that programmers will reject any solution that isn't developed in-house and you get this leveled at you if you build something that's different to what is already out there that there's another way of solving that problem people will say you're reinventing the wheel why are you doing that and sometimes that's true in fact there's a strange thing that goes on whereas the less I know about the subject the more I am likely to write my own terrible code to solve the problem it's like you know we all do it, we all try and reinvent the wheel but I think there's a flip side we can end up so reliant on third party solutions that we stop innovating we stop thinking creatively around our problems we just reach for the nearest plugin we search for something that does more or less what we need and to be honest to me the best thing about this job is the creativity is the creating cool stuff not just you know cobbling together stuff that other people have written so if you find some framework or plugin and it kind of fits the bill and you're really busy and you need to get something shipped you think well we'll use this now and replace it later and that's actually a decent way to work isn't it you can say well let's use this and we know we want to do something better but we can use this for now so what you want to do then is to avoid that plugin becoming a dependency in your project avoid basing great chunks of your workflow on a third party tool because that might change it might change in a way that's not useful for you or you might discover that it has some major problem on mobile or accessibility or whatever so don't base great chunks of your app on some third party tool the dependency inversion principle works really well here the first of these two principles is most relevant to those who are on the front end high level modules should not depend on low level modules both should depend on abstractions and if we go back to the early example of the Susie grid that's a reasonable example of a front end shortcut that doesn't create a dependency because we don't need to add anything to our markup or content if we use Susie we end up with CSS when we use Susie so we could remove the Susie grid or we could remove the SAS part of the tool chain completely and we'd still end up with semantic HTML and CSS so that seems like a really good way to use a tool it's there we've used it it's short cut the difficulty of creating layout on the web but we can pull it out of the workflow and our site still runs it's absolutely fine and I think a progressively enhanced approach is a good example of this dependency inversion in as much as it applies to front end development you might have a javascript implementation that hijacks regular HTML5 video and add some stuff a static map is hijacked by a draggable and zoomable map a form interface that allows you to save and add another and you're using using javascript to really just post to the browser but you could just have you know people would post that would still work without the javascript we can do this stuff we can work in a progressively enhanced way and then if for some reason the javascript doesn't load and ultimately you know everyone is a user without javascript until the javascript's loaded and it might not load it all still works and I know when you're pushed for time it is very very tempting just to get things together the quickest way you know how and you sort of think well if I can't do everything if I can't make this perfect why am I bothering doing anything at all but I think any steps you take towards progressive enhancement are going to be beneficial to someone so do the things that you can do with the time that you've got this is a great post Jason Garber he wrote some really excellent and sensible posts about the practical application of progressive enhancement with this understanding that what we do is on a continuum it's not terrible and perfect it's kind of like you know we're all on different levels of that and the sites that I build are all on different levels of that so to recap learn and importantly teach other people these core skills HTML, CSS and javascript please maintain interest in emerging specifications and make sure you don't end up clinging to outdated abstractions because you've become so reliant upon them there's absolutely a place for the expert front end developer instead of learning how to cope with browser bugs though you know become an expert on performance as web usage goes more and more mobile that's going to become more and more important becoming an expert in making well performing applications is going to be incredibly important in the future when making decisions about these frameworks, plugins and systems ask yourself is the output as good as if you'd written it by hand or how close can you get to that is this tool just speeding things up and if it is, you know what are the compromises and other compromises you're happy to make while there's a ton of great code to draw on out there and I'm sure a lot of you are writing that code and making it public try and avoid sort of inventing the wheel and make sure that doesn't prevent you from creating your own new things the role of this expert front end developer hasn't gone away and I think it's so much more than it was ten years ago we're incredibly fortunate and we have the ability to really change the way people use digital products to how they interact with things and how they interact with each other online and there's so much that we can do and make and there's so much more around the corner so don't stop playing and don't stop experimenting and pushing things forward because we've come so far in the last few years I might be you know I've been doing this since the year dot but I am still really really enthusiastic and interested in front end development as kind of a craft and what we can do I'm excited about the next ten years I'm excited about where we'll go with this but thank you so much for listening I really hope you enjoy the next couple of days there's some great stuff coming up my slides and a load of links are available at that URL and I'm hanging around so I'll be very happy to have a chat with anyone if you'd like to. Thank you