Developing for the Unknown

Ashley Nolan
Senior UI Engineer at :
@AshNolan_
Developing for
the Unknown
So hi everyone, I’m Ashley Nolan, and I’m a Senior UI Engineer at JUST EAT, based over in Bristol.
And today I’m going to be talking about the problems all developers face when developing with the future in mind and sharing some of my experiences on projects that I’ve been working on over the last few years that can help
with these issues.

@AshNolan_ :
Legacy
Now in order to talk about developing for the future, I think it’s really important that we look back at the past and in particular to consider what this word means.
In the web development industry, legacy tends to have really negative connotations. Picking up a legacy project is something that developers dread because we associate 'legacy' with outdated practices, dated architecture, and
so having to update a legacy project can be really hard work.
However, on a much wider scale within society, the term legacy can be both positive and negative; we often refer to people or companies who have left a very positive legacy on industries, our ways of thinking or on a much
wider role within society.

@AshNolan_ :
People like Nelson Mandela and – this man here – Winston Churchill who both have left enormously positive legacies behind them.
In other industries such as music you can point to people like Elvis, The Beatles, or David Bowie as all having left a great legacy behind to the bands and performers who came after them.

@AshNolan_ :
Who can tell me who this man is?
Exactly, so this is Tim Berners-Lee, the inventor of the world wide web, without whom none of us would be sitting here today. So we have people like Tim Berners-Lee, Alan Turing, Steve Jobs, to name but a few, who have left
an overwhelmingly positive legacy to us within the computing industry.

@AshNolan_ :
Legacy
So if legacy can have evoke such positive emotions and memories, why do we still use it primarily as this dirty word to describe a trait that we want to avoid on the projects that we work on.
Why can’t we create a project that leaves behind a positive legacy? Is this even possible with the ever changing nature of the web?

@AshNolan_ :
Of course it is.
So I’m not talking about necessarily having to create a legacy on the level of people like Tim Berners-Lee, but I think it’s important for all of us to think about the legacy that we leave behind on the projects that we work on.

@AshNolan_ :
Legacy is something that
we are creating
Legacy is something that we create as developers and product owners and that we can help to control.
We create it with our decisions on what what technologies we choose to use, we create it by the decisions we make when writing the actual code, and we create it by how much or how little we decide to document the decisions
that we make.
And the decisions that you make will directly affect other people too. It’ll affect the developers somewhere down the line who may need to update the project that you worked on. It’ll affect the people who paid you or your
company to build the website, and the return on investment that they receive from the website that you build them. But most importantly, the decisions that you make will affect the users of that website, and the experience that
they have when they use it, and that is ultimately what decides whether that project is a success or a failure.
it’s good to remember that these things aren’t mutually exlclusive either. By making your site easier to develop for, you can spend more time on things that can actually help your users like the UX or performance of your site as
well.

@AshNolan_ :
Now my experience over the last few years has been working on quite large scale web builds. Before JUST EAT, a few years ago, I was the lead front-end developer on the BBC Good Food redesign and I’m now doing the same at
JUST EAT, heading up the front-end redevelopment of our International platform.
But to put this into context, with how this is associated to legacy – I’m not trying to be too self righteous here obviously. Ultimately, both of these websites are enabling people to cook or order food – no-one is going to die if
the decisions that I have made previously or in the future are wrong or if I decide to choose one JavaScript framework over another – although people may go hungry. But the legacy that I’m trying to create is simple; I want the
front-end of my projects to be easy to use for our users and our customers, and easy to develop on and update as a platform for developers in the future.
I think that as a developer if you can achieve those two things, not only will the business as a whole beneﬁt, but you’ll be passing on a really solid legacy for whatever project you’re working on.

@AshNolan_ :
4:00 – Now the problem with trying to create this solid legacy, is we don’t know what will happen in the future. If you go back a few years for example, no-one had heard of responsive design and media queries, and further
back than that developers were still using tables for layout rather than CSS . So there’s absolutely no way that we can protect our projects from being outdated in some respect by developments in our industry.

@AshNolan_ :
No matter what, I think we’re always going to feel a lot like this kid playing basketball – we’re always going to feel like we’re chasing the changes in front-end development. The future is always going to be ahead of us though
and things in front-end development are always going to be moving forward.
But developing for the future isn’t about predicting and trying to protect yourself from technology changing. For me, developing for the future is about making sensible reasoned choices, and most importantly to make sure that
updating those choices later won’t be a complete pain in the ass, whether that’s for you or for someone else down the line. Being able to react and adapt to change, without rewriting you whole codebase, is hugely important as
technical advances move forward so often in our industry.
So ultimately, that’s what my talk today is really about – how to make good decisions over the direction of your front-end projects so that they become easier to maintain and update over time, and to embed good practices into
your development workﬂow.

@AshNolan_ :
6:00 – So in terms of trying to highlight the best ways to go about this, I’m going to be talking about the work that I’ve been a part of while at JUST EAT – and about some of the painful experiences that I’ve had while working
with our legacy codebase and how we’re trying to make sure that those experiences don’t get repeated in the future.
Now I joined JUST EAT back in May last year (2016), and I didn’t know all that much about the company when I joined them and I certainly didn’t know anything about the International Platform, which is what I ended up working
on and the project I’ll be taking examples from today.
Now I’m guessing like I was back then, you probably don’t know much about JUST EAT’s International platforms either, so I’m going to give a very very brief overview of the project that I’m working on currently just to give you a
tiny bit of background.
So for those that don’t know, JUST EAT is an online food ordering system, which aggregates local takeaways and restaurants so that you can pick a restaurant and order some food without having to ring them up directly.

@AshNolan_ :Map vector courtesy of Freepix
So in terms of the International Platform that I work on, the countries that we look after are:
Spain, Italy, Denmark, Ireland, Netherlands, Belgium, Norway and Canada.
Outside of what the International Platform team looks after, JUST EAT also has websites that serve the UK, France, Switzerland, Brazil, Mexico and Australia, some of them like the UK are under the JUST EAT brand and others such
as Australia are called completely different things. So in Australia, the company is called Menu Log for example.
So the International Platform team that I am a part of serves all of those ﬂags in red, so that’s 8 countries, all with different languages, some of which have different languages within the same country such as Canada and
Belgium

@AshNolan_ :
Now when I joined the company, it was when the JUST EAT International team had started on the redevelopment of the website – so we had an old codebase that we needed to evaluate and see how much we could take onto the
new platform that we were now developing.
So this is quite a common scenario in web development, where you want to do a redesign but you may not want to just put your entire previous codebase straight in the bin, because that’s pretty wasteful. So as part of this, my
ﬁrst job with the company was to review the state of the front-end code that made up our old site and the things we’d started to put in place on the new website as well.
Now within a week or two of me joining the team, there were a couple of really clear issues, which I think are fundamental to any project, but one that stood out in particular immediately.

@AshNolan_ :
So the biggest issue was that just trying to ﬁnd out what was even going on with the front-end code was stupidly hard.
So for such a large-scale build, it was almost impossible to work out what decisions had been made about the direction of the front-end aspects of the site. So there was no documentation, no code commenting, no information
to help me work out why things had been done or where things even were.

@AshNolan_ :
So to give one simple example of this, this is a screenshot of the main site directory on Github when I joined. And this was actually from our 'new' codebase rather than the old one.
Now if anyone had to guess where front-end assets lived, such as the CSS, JavaScript and fonts, you may logically think that they would be in the /Assets folder. However, that would be far too easy – especially considering that
I’m using this as an example of what not to do. Because In fact they are in the Assets folder, but as well as having CSS, JavaScript and fonts in the Assets folder, we could also ﬁnd more CSS and fonts in the Content folder and
more JavaScript in the Scripts folder. Because, why not?
After digging through the CSS a bit more, the styles in the Content folder were generated using LESS and the styles in the Assets folder was just straight up CSS.

@AshNolan_ :
Our 'new' website was in danger of
becoming legacy from the offset
Now the biggest problem with all of this was that our brand new website was in danger of becoming legacy before we’d even really got started.
These were really fundamental issues – and this is something that I’ve found does tend to happen over time as a codebase evolves. In our case, this had happened because we hadn’t planned the transition well enough between
our old front-end code, to how we now wanted to do things, and effectively because of this had ended up with the old structure and the new structure in our new codebase.
Ultimately we hadn’t put the right things in place from the start. And by this I mean simple things like specifying our project structure and deﬁning a clear workﬂow of how our front-end code was going to be developed and
built.

@AshNolan_ :
Plan and Define your workflow
and put time into tooling
10:00: So the first, and probably most fundamental point I want to make before going into any specifics of coding or front-end best practices is the importance of making sure you don’t cut corners when planning and defining
your project workflow. Or if you already have a structure, but it’s terrible, spend the time to fix it, because it will save you massive headaches further down the line.
One part of this that can really help you out is putting the time into learning workflow tools, such as Grunt or Gulp, which can really help you structure your project through the tasks that you create and use.
We’re really lucky now as developers to have tools that can define how specific front-end tasks are to be carried out. If you go back just 5 years, unless you wrote documentation on how you intended your site’s CSS or JavaScript
to be built and minified, it wasn’t always clear to someone new to the project. Now with workflow tools, you can set up a bunch of tasks so that every developer compiles their Sass or minifies their JavaScript in exactly the same
way. Within a project team, developers can also help to evolve and improve these tasks so everyone can benefit from them.

@AshNolan_ :
So the tool we now use at JUST EAT to define our front-end workflow is Gulp.
Now I’m not going to get into whether you should use Gulp over Grunt or any other workflow tool that’s out there, because the main thing for me is not to get too hung up on the workflow tool that you choose to use. If I was
working on a project that heavily relied on Grunt already, I wouldn’t worry too much about updating it to Gulp unless you really want to for some reason or another – there isn’t really that much difference and both have great
communities around them.
The main thing is that you are using something to help you structure your workflow and make it consistent across your team, whether that’s Grunt, Gulp, Brocolli, or NPM scripts – whatever works best for you.

@AshNolan_ :
Workflow tools speed up your project
setup and provide consistency across
teams and future projects
The other big benefit to using any workflow tool is that they’re useful irrespective of the scale of the project you’re working on.
If you find yourself working on lots of small scale projects, then putting together a set of gulp tasks - such as Sass compilation, adding browser prefixes to your CSS, or bundling your JavaScript using browserify – things that you
know you’ll be using across every project – is a massive timesaver.
On the other side of things, on a large team of devs working on a large scale codebase, being able to define your front-end tasks consistently across the team is extremely valuable. So we use Gulp to run a whole bunch of tasks
in development, as well as having a set of production Gulp tasks that run on teamcity when our site gets deployed (which you can also run locally to test the production workflow).

@AshNolan_ :
Documentation
What is it good for?
13:00 – Now the other thing that I mentioned that was missing when I ﬁrst started looking over our codebase at JUST EAT was any sort of documentation.
So what do I mean by documentation? Well documentation could be as simple as good code commenting, or as detailed as creating a styleguide that’s built to run alongside your project – it completely depends on your project
scale and your own good judgement.
So we’re all professionals – we should all know the value of good documentation, especially now that we all make use of great open source scripts and plugins. But the worst mistake you can make is to undervalue documentation
on your own projects – because when it’s there, it’s incredibly useful.

@AshNolan_ :
To take an example, jQuery probably wouldn’t be as popular as it is today without it’s incredible documentation site – I remember reading a quote from John Resig, the creator of jQuery in which he said something along the
lines of 'how surprised he is that developers don’t put more effort into writing documentation considering the time they spend creating their scripts, because without that, the things they create are only truly useful to
themselves'.
Now this is especially true for a library like jQuery – and I’m not going to say that everyone should be making time to write documentation as detailed as that – but it’s equally relevant when it comes to the projects or websites
that we work on. By not writing any documentation for a project, you make things harder for anyone that tries to update your code in the future – including yourself – but worse, you’re likely to reduce the lifespan of the code or
the project that you’ve worked on.
How many times have you looked at some code that you’ve inherited with no comments or documentation and decided it would just be easier to rewrite it than to try and work out what’s going on? That’s what will happen to
your code if you don’t document it in some way.

@AshNolan_ :
Now I know that every developer in this room has probably been given this advice a million times before, and it doesn’t help that writing documentation is without doubt the worst part of our jobs. Every time I force myself to
write documentation, I feel like my inner self is this cat being dragged along the ﬂoor not wanting to do it.
I also understand that when time on a project is tight, documentation isn’t going to be the top priority.
But if you can at the very least get into the habit of writing better comments in your code, then the developer who updates the code after you, or maybe even your future self when you come to update that piece of code a few
months down the line, will deﬁnitely thank you for it.

@AshNolan_ :
Programs should be
written for people to read,
and incidentally for machines to
understand
Abelson & Sussman
Try and remember this quote by Abelson & Sussman…
I’ve heard many developers in the past say that great code documents itself, but I honestly think that’s just a poor excuse for not commenting code properly.

@AshNolan_ :
Code Commenting
CSS
.infoBar {
…
}

@AshNolan_ :
Code Commenting
CSS
/**
* infoBar Component
* ===================================
* A full page bar that can contain information relevant to the page
*
* Examples of it’s use include the Cookie Banner and the Langauge Switcher Banner
*/
.infoBar {
…
}
At JUST EAT, I now don’t merge pull requests on our CSS components that don’t at least have a brief explanation such as this at the top of the component ﬁle saying what it does and example usage.
And there’s no excuse for not doing this – it takes 2 minutes and it helps to give so much more insight at a glance into the CSS styling and components that you are writing.

@AshNolan_ :
Changing our habits
16:00 – So at JUST EAT, one of the other main shifts that we’ve had to make is more of a cultural one.
So historically on the JUST EAT International team, there wasn’t anyone owning the front-end side of the platform. We have a large team of engineers working on the codebase, but these devs are mostly either .NET engineers or
full stack developers. So back in May last year I was one of 3 front-end focussed engineers working on the platform, with 1 of those only having joined the same day that I did.
Because there was no clear direction before this, developers across our teams were creating styles for our site in silos. So the other big challenge when joining the company was to educate and change our front-end habits
throughout the team and to make sure that we could communicate how we wanted to do things effectively.

@AshNolan_ :
Styleguides &
Component Libraries
http://styleguides.io/
So one of the ﬁrst things I decided to set up was a site style guide and component library.
Now I’ll come onto what those looked like a bit later, but what was the reason that I chose to do this over prioritising other things?

@AshNolan_ :
Components
So that developers can evolve modules over time
So the main thing that I wanted to encourage at JUST EAT and I’d advise any front-end developer to do, is to think about splitting up the mockups you receive from designers into components, so that they can evolve over time.
By creating a component library, it was to make developers think about creating their code in isolation, outside of the page, so that it could work anywhere we needed it to.
This also means that in the future when we need to change things for whatever reason, rebuilding a component is a lot simpler than rebuilding an entire page. A consistent issue that I’ve seen working with both CSS and
JavaScript across lots of different projects is that developers tend to tie their code to the context they’re developing in much too tightly, so that in the future a simple change becomes much more complex than it needs to be as
you unravel a lot of features.
We should always be trying to separate our concerns, as it makes our code much more maintainable.

@AshNolan_ :
Component driven development
Why bother?
- Reuse patterns across our website
- It’s easier to find specific functionality – and redundancy
– in a codebase
- It encourages the extension of styles and avoiding
undoing/overwriting styling
- Components are not tightly coupled to a page context,
so can be used anywhere – including other projects
So a couple of other reasons that it’s a good idea to build front-end code in terms of components:
– So the majority of websites have patterns that repeat across pages, and building in components means that we can reuse those styles and scripts across all of our application.
– By organising your CSS or JavaScript in terms of components, it’s much easier to find specific functionality and update just that functionality knowing that you won’t accidentally break something else. As a result of this
organisation, it’s easy to handle redundancy, as when a component is no longer used, you can just delete the files relating to that component.
– When building in components it encourages you to avoid undoing styling & encourages extension of styles instead. So starting with a small component and extending this base functionality so it is more flexible.
– And importantly, a component only worries about itself, so it’s not tightly coupled to a page context. This means they can be used anywhere, even potentially on other projects.

@AshNolan_ :
So moving to a real example, this is the current JUST EAT search results page.
Now rather than trying to style up the entire page so it’s speciﬁcally a search results page, we can break this down into much simpler components, putting them together to form this page.
So here we can have components for a media element, which would just handle the styling of an image sitting side by side to some text. We can also have a component for our results listing, because this is a style that is
actually used in multiple places on our site. And similarly you break apart this entire page into smaller components – the page navigation, breadcrumb, we have a rating component for the stars in our listing that are used across
our site. And we might have a grid layout component to handle how the overall page layout can be speciﬁed.
So by combining all of these components, we build up our search results page, but there’s nothing on this page that couldn’t potentially be used in another part of our site.

@AshNolan_ :https://smacss.com/ & http://atomicdesign.bradfrost.com/
There’s a couple of really great resources on this that I’d recommend to anyone interested in learning more, and these are SMACSS by Jonathan Snook and Atomic Design by Brad Frost.
So both of these books explain in more detail how to go about making your CSS more modular, so it’s easily reusable, and go into a lot more detail about components and common issues people face on projects. In the case of
SMACSS Jonathan Snook applies this to the work that he did while he worked at Yahoo, and Atomic design goes into the detail of how this approach can be combined with tools like styleguides and the workﬂows you can use.
So I’d recommend checking these out if you haven’t already.

@AshNolan_ :
Naming Schemes
i.e. BEM or SUIT
21:00 – So I just wanted to cover one thing that I think really complements component driven development in CSS and that’s CSS naming schemes.
So these are something that I strongly recommend to help developers write better CSS and something that we now use at JUST EAT.
So the idea of having a naming scheme is so that everyones CSS has a consistent feel to it, and when you’re writing CSS in a more modular way a naming scheme helps to describe the relationship between the classes in your
CSS.

@AshNolan_ :
Naming Schemes
Key Aspects of a naming scheme
1. Consistency between classnames
2. Show the relationship between classes
3. Easy to spot modified components and extensions
4. Provides consistent state/utility classes
So there are several key aspects to using a naming scheme.
1. To keep consistency between classnames – so that they look similar throughout the project
2. Show the relationship between classes so that it’s clear from looking at a class which component it is a part of
3. They help to show when someone has extended a class and modiﬁed it, reusing the existing styles
4. And they help people write consistent state and utility classnames (such as active or open on a component)

@AshNolan_ :
Blocks
i.e. -> .nav
Naming Schemes
Key Aspects of a naming scheme (BEM)
So to give an example, one such naming scheme is called BEM, and BEM is about splitting up our components into clearly deﬁned chunks. Those chunks are:
Blocks. So a block would be the base of our component…

@AshNolan_ :
Blocks
i.e. -> .nav
Elements
i.e. -> .nav-item
Naming Schemes
Then we have elements, which are the pieces that make up our blocks. So elements should only make sense within the context of the block that they belong to. If this isn’t true, then the element should probably be a
component in it’s own right.

@AshNolan_ :
Blocks
i.e. -> .nav
Elements
i.e. -> .nav-item
Modiﬁers
i.e. -> .nav--inline
Naming Schemes
Finally we have Modiﬁers, which are used when we need to create a block that is very similar to an existing one, but with a slightly different appearance or behaviour.

@AshNolan_ :
Naming Schemes
Kickoff CSS Naming Scheme
/* Descriptors use camelCase if more than one word: e.g. twoWords */
.iconList { ... }
/* Child elements use single hyphens: - */
.iconList-item { ... }
/* Modifier element use a double hyphen: -- */
.iconList--inline { ... }
.iconList--large { ... }
/* Element state: .is- or .has- */
.is-active { ... }
http://ashn.uk/ko-naming
Now, looking at how this can be applied, this is an example of the naming scheme that we use at JUST EAT.
This is called the Kickoff CSS naming scheme – but it is actually similar to one used in a methodology called SUIT – we’ve simply adapted it slightly to ﬁt with how our team want to work in terms of the syntax.
So for example…
Explain.

@AshNolan_ :
Naming Schemes
Before naming schemes…
/* No link between classnames in a component */
.searchResults .restaurants { ... }
.searchResults .restaurants .first { ... }
.searchResults .restaurants img { ... }
.searchResults .restaurants .rating { ... }
/* States are not clear */
.active { ... }
.valid { ... }
So by way of an example, this is what some CSS might typically look like when you aren’t using a naming scheme of any kind…and this is taken from our old search results styling.
So everything is very tightly coupled. You can’t reuse classes such as rating, as they’re speciﬁed quite deep and are speciﬁc to the searchResults container. Also if you just looked at the HTML, you wouldn’t be able to link which
classes were related to one another, and where one component ends and another begins.
So what happens if we use a naming scheme instead?

@AshNolan_ :
Naming Schemes
After applying a naming scheme
/* Clearly linked classes */
.listing { ... }
.listing-item { ... }
.listing-item--first { ... }
.listing-item-img { ... }
.rating { ... }
/* States are clear */
.is-active { ... }
.is-valid { ... }
Here you can clearly see relationships between classes within a component. So you have classes that define a listing component, and a rating component that can now be used anywhere in your site.
States are always defined with the same .is- or .has- prefixes, so they are easier to spot in your CSS and HTML as being a state.

@AshNolan_ :
Naming schemes positively re-enforce
modular and component driven CSS
So hopefully you can start to see how using a naming scheme can help to re-enforce writing component driven CSS, and some of the beneﬁts they can provide when trying to write more maintainable CSS.

@AshNolan_ :
Styleguides &
Component Libraries
26:00 – Now I mentioned earlier on that I wanted to create a styleguide and component library to help developers understand the beneﬁts of writing their CSS in components, so I wanted to quickly show you where we’ve ended
up on that front.
–– SHOW LIVE COMPONENT LIBRARY ––

@AshNolan_ :http://ashn.uk/statix & styleguides.io
Static Site Generators
Styleguides
If anyone is interested in the tool we use for this it’s a project that I’ve open sourced called Statix, which uses a static site generator called Assemble to make writing styleguides and component libraries very simple.
Don’t worry about copying down the link as it’ll be in the slides that I’ll share at the end.

@AshNolan_ :
Decoupling
Separate your concerns
29:00 – So going back to coding issues, one of the other big lessons that I’ve learned working on larger projects with bigger teams is just how valuable decoupling technologies can be.
So what do I mean by this?

@AshNolan_ :
Decoupling
A simplified example
// CSS
.myComponent {
…
}
// JS
$('.myComponent').on(…);

<section class="myComponent">
So taking this really simpliﬁed example – here you can see that we’ve got some markup – a section tag with a classname of myComponent – some CSS referencing that classname, and some JavaScript also referencing that same
classname.
Now the problem with this is that I believe that refactoring your CSS should be as easy as possible. Components by their nature change over time and so it’s important to encourage people to change the structure and name of
components when they need to.
The obvious issue with this is that if our JavaScript is also hooking into the same classname, changing it will obviously break that JavaScript functionality.
So what can we do to ﬁx this?

@AshNolan_ :
Decoupling
A simplified solution
// JS
$('[data-myComponent]').on(…);
OR
$('#myComponent').on(…);

<section class="myComponent"
data-myComponent>
OR
<section class="myComponent"
id="myComponent">
// CSS
.myComponent {
…
}
So you’ve a couple of options, which are essentially the same approach but use different points to hook onto the element.
So at JUST EAT, we use data attributes to get around this issue. We write our JavaScript in modules and so here the base of our module would be deﬁned with a data-myComponent attribute which our script can then hook onto
to do whatever it needs to do.
You can alternatively use ID’s for this, because hopefully you won’t be using ID’s in your CSS because of the speciﬁcity problems they can lead to. If this is the case, ID’s would be another property that you could use for your
JavaScript hooks, but I personally prefer using data-attributes as they feel a little bit more suited for that purpose.

@AshNolan_ :
Decoupling
A simplified solution

<button class="myButton" data-test="addBtn">Add</button>
Also, we run feature tests such as selenium at JUST EAT – previously they also referenced classnames in the same way as this, which meant that when classnames changed that were referenced in the tests, these tests would
break even though the underlying functionality of the code hadn’t changed.
For our selenium tests, we actually use a separate data attribute of data-test, like in this example, so that in the markup if we see this attribute, we know that changing or removing the element will break our feature tests.
So this really helps us, as previously we’d ﬁnd that people would be updating components and giving our testers lots of extra work just ﬁxing the old tests that they had broken, which wasted a lot of time.

@AshNolan_ :
Separate your concerns
Changing a classname shouldn’t break scripts and tests.
Make your code more resilient to change.
So the main point with this is to separate out your concerns.
This applies when separating out front-end tech from each other, but also between front and backend code.

@AshNolan_ :
Project Dependencies
Choose them wisely
33:00 – The ﬁnal point I want to cover today, is around project dependencies.
And what I mean by project dependencies is making sure that you give enough consideration to the tools that you use on your projects, and the reasons why you’ve chosen to use them or just as equally why you’re not using
them.

@AshNolan_ :
So one example where we had to think about this was when I ﬁrst came onto the project last year and it was to do with the use of CSS preprocessors. So when I joined the company, the team wasn’t utilising any preprocessors,
and the reason for this was because the front-end lead who came before me wanted to make sure that the site used as few dependencies as possible.
Now this is a really admirable attitude to have in a lot of ways – it’s good to carefully think about the dependencies that we add to our projects – but I do think this is an example of someone taking it too far.
So hopefully everyone here realises the importance that CSS preprocessors can play when writing maintainable CSS. If not I’d just like to show you one piece of CSS that sums up why they’re incredibly useful as a site starts to
scale.

@AshNolan_ :
/*************************************************************
* Red foreground colour
*************************************************************/
.materialCard h1,
.restaurantReviews .moreRatings p a,
.restaurantReviews .moreRatings p a:hover,
.restaurantReviews .moreRatings p a:focus,
.restaurantReviews .moreRatings p a:active,
#searchResultsHeader h1,
#searchResults .restaurant .openingTime,
#searchResults .restaurant .offline,
#searchResults .restaurant .collectionOnly,
.restaurantOverview .collectionOnly,
.restaurantOverview .closed,
#login h1,
#login h2,
form .errorMessage,
.errorSummary ul li a,
.errorSummary p,
.errorSummary ul,
.orderConfirmation h1,
.appUpsell h2,
#helpContent h2,
#takeawayAreasHeader .changeCuisine a,
#menu .category .categoryName,
.allergyInformationLink,
So this is an example piece of CSS from a ﬁle called 'colour-palette' which I actually came across in our new codebase, and this piece of CSS was designed to make it easier to change the colour of text across a bunch of elements
on the JUST EAT website.
So if I move this on, you can see that this is a pretty hefty set of selectors, and at the end of it, we have just one colour declaration. So true to design, it is easy to change the colour of every piece of text that is currently coloured
red on the website.
The issue here though should be pretty obvious. It’s completely unmaintainable. No-one can possibly tell which selectors are still in use, ﬁnding a selector in this list is horrendous because there are just so many of them – this
approach doesn’t scale. The bigger your site gets, the longer this list gets and the more horrible this piece of CSS becomes.

@AshNolan_ :
Current statistics for usage of
CSS Preprocessors
 
Based on a survey of 2028 devs
– September 2015
http://ashn.uk/survey-res
So anyone who’s familiar with CSS preprocessing knows that this is an easy problem to solve when you’re using a tool like Sass or Less, and to me, there’s no real reason not to be using a preprocessor these days.
I actually ran a survey towards the end of last year on Front-End tooling, which had over 2 thousand respondents, and one of the questions was about preprocessor usage. And as you can see from this chart, 85% of people
replied that they now used a preprocessor in their workﬂow – which just goes to show how important a tool they have become to developers.

@AshNolan_ :
Don’t shun a tool because
it’s an extra dependency.
Weigh up it’s potential value against the added
complexity in your workflow.
So using a preprocessor is kind of a no-brainer in my opinion, but what I’m getting at is not to shun a tool simply because it’s an extra dependency for you project.
When you look at new tools or frameworks, you should be weighing up it’s potential value to you and your team and comparing this to the added complexity it might bring to your workﬂow

@AshNolan_ :
Code with the future in mind
- Use transpilers to let you write your JavaScript with
future standards in mind while keeping compatibility
for older browsers.
- Choose dependencies with one eye on the future.
It’s also really important to code with one eye on the future.
A great example is using a transpiler when writing your JavaScript, which is something we now do at JUST EAT using Babel. We decided to go down this route because we want our codebase to evolve over a number of years, and
so being able to leverage ES6 and the latest native JavaScript functionality while having a transpiler to give us backwards compatible code for older browsers.
We know that because we’re coding with respect to standards, it’s inherently future-proof.

@AshNolan_ :
Beware Hype!
Just because something has lots of hype, doesn’t
necessarily mean it’ll stand the test of time.
So I think this is especially relevant in terms of front-end development, but if you want to build something for the future, it’s best not to jump aboard the hype train.
I’ve been involved in way too many situations over the years where yesterdays amazing new shiny thing, is the biggest piece of legacy in a project.
Embrace the new and shiny by all means, but test out the tool, get other peoples opinions on it and think about it’s impact on the future of your project. This is especially true of JS frameworks if you go down that route – it
makes much more sense to choose a framework that has a proven track record, compared to choosing the latest being hyped on HackerNews.

@AshNolan_ :http://ashn.uk/sass-postcss
One recent example of cutting through the hype and evaluating a tool on its merits is PostCSS – which is a CSS processing tool which has had lots of hype around it over the last year. We use this in our workﬂow alongside Sass
because it’s footprint on our project is quite small, and it gives us some incredibly powerful tools when writing our CSS, such as automatically inlining images, adding preﬁxes to our compiled CSS, great CSS linting and a bunch
of other useful things that we wouldn’t be able to do without it.
With PostCSS, we started small and have tested it out and added tasks as we needed them. It also doesn’t change the way anyone in our team writes CSS, instead working alongside the way that we already write our styles.

@AshNolan_ :
Summing up
So, I’ve tried to cover the main things that I’ve learned over the last few years that I would personally now apply to any project that I work on.
There’s obviously a tonne of extra things that I haven’t had time to go into as I’ve been focussing more on the development issues we’ve come across – so there’s lots more UX focussed problems that we’ve faced that I could
probably do a whole separate talk about.

@AshNolan_ :
Whatever we create should be
built to last
But the main message that I wanted to get across today is that we should be acting responsibly as developers and building things that can potentially last a lot longer before they’re classed as legacy in terms of how they’ve been
developed.
I think we’re in a place now with the tools that we have available to us, where we can genuinely build something with the ability to evolve over time.
We often think that starting again is much easier than having to make an existing project better. But I’d argue that if that’s the case now, it’s actually of our own doing. If starting completely over again is easier than simply
evolving your development workﬂows, then it’s a sure sign that a lot of the things that I’ve talked about today have simply been ignored.

@AshNolan_ :
Build a great legacy
So on your next project, try to build a great legacy, instead of a leaving a legacy behind that someone else wishes had never been created at all.

Ashley Nolan
Senior UI Engineer at :
@AshNolan_
Thanks
http://ashn.uk/devunknown

Developing for the Unknown

Recommended

Recommended

More Related Content

Similar to Developing for the Unknown

Similar to Developing for the Unknown (20)

Recently uploaded

Recently uploaded (20)

Developing for the Unknown