Reworking our-workflows

Ashley Nolan
Senior UI Engineer at :
@AshNolan_
Reworking our
Workﬂows
Hi, I’m Ashley Nolan. I’m a Senior UI Engineer working at JUST EAT in Bristol.
I’m going to be talking about something that I’m really passionate about at the moment, and that’s front-end development workﬂows.

@AshNolan_ :
Bit about me
First – a little bit about me.
I’ve been working with the web for around 9 years professionally and have worked with clients such as the BBC, Unilever, Activision among other companies.

@AshNolan_ :
In the last couple of years especially, I’ve helped lead the front-end development on some really large scale platforms such as the redesign of BBC Good Food and have recently joined JUST EAT, and I’m currently
helping to rebuild the front-end of their International Platforms, which includes restructuring JUST EAT’s front-end workﬂow.
I’ll go into some of that throughout my talk but any questions…

@AshNolan_ :
Now I want to take you back – way back to 2004. So that’s 11 years ago, and for anyone wondering, I was 20 in 2004, and although I was fully trained in using Microsoft Frontpage back then, that was when I was
ﬁrst starting out building professional websites for people other than myself.
So 2004 was the year Facebook was founded, IE6 held the biggest market share of any browser on the web, and the BBC Sport Website looked like this…

@AshNolan_ :http://ashn.uk/bbc2004
So it was a long time ago.
Now my workﬂow back then was also quite different to what it is today, and it consisted of the following:

@AshNolan_ :
1.Write some HTML and CSS
2.(Maybe) write some JavaScript
1.Write some HTML and CSS1.Write some HTML and CSS
2.(Maybe) write some JavaScript
3.Use FTP to upload files to a server

@AshNolan_ :
…and that was job done really.
And this was great – everything was really simple. Except it really wasn’t.

@AshNolan_ :
Like this invention by these two clever chaps, it was pretty ﬂawed.
So for example, companies I worked for back then didn’t use version control. SVN had only been invented in the year 2000 and Git was absolutely nowhere to be seen, so our version control was having 2 copies,
one locally and one on the server.
Now looking back, this was pretty dumb, but as companies like Github have made version control a lot more accessible to developers no matter how they work, it’s now considered the norm to use version control
and for very good reason.

Cohesive Workflow
Now version control isn’t the only thing that’s progressed in web development since 2004, and front-end development in particular has moved at an insane pace in this time.
Our workflow now involves all manner of choices – and much like the cogs in a watch, they all need to fit together to form a cohesive process for your team, no matter how big or small that may be.
For me personally, problems with process get accentuated the larger the scale of the project, especially on projects with longer shelf-lives – so ones that are built to last for years rather than weeks, because then
you really see how the choices you make have an impact over time.
But this doesn’t mean smaller projects can’t benefit from good process. It’s about weighing up the choices that will be most beneficial and making sure you don’t put things in place that’ll hinder you further down
the line.

@AshNolan_ :
CSS
Task Runners
CSSCSS
Task Runners
(plus a tiny bit on static site generators)
Now I’m going to talk about some of the front-end tools and methodologies that I think offer the most value to teams today and that I’ve found to have the biggest impact in terms of helping the structure and
maintenance of the projects that I’ve worked on.
So I’m going to focus on a few areas:
- I’m going to talk about CSS, and some of the things I’ve noticed that have helped me when authoring CSS or the mistakes I’ve come across
- Task Runners such as Grunt and Gulp
- plus a tiny bit on static site generators

@AshNolan_ :
(6:00) So, I wanted to start by going through some of the changes that I’ve seen in a language which I’ve always worked with.
For me, no matter how much stick it can get as a language sometimes, CSS is one of my personal favourites. Although this is apparently what the logo for CSS looked like originally – and it’s got virtually no style,
which I think is quite ironic…
CSS is really expressive, at it’s core it’s deceptively simple, but the more experience you gain using it, the more intricacies you ﬁnd.

@AshNolan_ :
Now unfortunately, when starting out with CSS, it can feel a little bit like this.
To be honest, no matter how long you work with CSS, you’ll inevitably get this feeling every now and again. I’ll usually get it when debugging code in older Android browsers, but this is how I used to feel writing
CSS that worked with IE6 as well.
Now if like me you’ve been developing websites for some time, you’ll know just how far CSS has come in a relatively short space of time with the introduction of CSS3…

@AshNolan_ :
I’m going to sound a bit old, but before CSS3 came along, times were tough in the trenches of front-end development. We were being forced to make rounded corners out of images and fonts with things like SIFR
or Cufon – these were terrible terrible times. I still have the scars and therapy bills to prove it.
We’re ﬁnally now getting to a place with developments like Flexbox and Webfonts where we can almost do everything we want to in CSS.
But the problem is we’re still not there yet – we’re still waiting for new specs to be ﬂeshed out and the browsers to implement all of the features that could help us.
So how to we mitigate for this in the meantime?

@AshNolan_ :
The obvious answer is to use Preprocessors!
So out of interest, how many developers here use preprocessors in their workflow? Sass? Less? PostCSS?
So Preprocessors now are pretty mature – lots of developers are using them, which is great because they are extremely useful – they are one part of my workflow that I would genuinely find it hard to develop
without.

@AshNolan_ :
Why?
But why use preprocessors?
So forget nesting and mixins, which are really handy when structuring your CSS, there are 3 main reasons to use a preprocessor in my opinion above all else.

@AshNolan_ :
Why use Preprocessors?
I. File Organisation
@imports 'reset'; // reset stylesheet
@imports 'grid'; // grid styles
@imports 'typography';
@imports 'components/navigation';
File organisation
So being able to break up your CSS into manageable chunks and then concatenate them down into one CSS file when compiled.
So here, you see we have our reset, grid and typography specific CSS and then we can start styling our components, such as our navigation, in different files as well.

@AshNolan_ :
II. Variables
$bp-narrow: 320;
$bp-mid: 640;
$bp-wide: 960;
$img-path: '/assets/img';
// colours
$color-primary: #333;
$color-links: #0000FF; //blue
Variables
Variables are really handy especially for ﬁle paths, when using images for example, specifying your major breakpoints when using media queries, and for deﬁning a clear colour–palette.
Doing this also makes it easier to have a living styleguide based on your CSS, as you can use these base variables to show the main colours and font-sizes when stored in this way.

@AshNolan_ :
III. Browser Prefixes (using autoprefixer)
-webkit-transition: 250ms ease-out;
-moz-transition: 250ms ease-out;
-o-transition: 250ms ease-out;
transition: 250ms ease-out;
transition: 250ms ease-out;
Browser Prefixes
The other reason is the ease in which they can help keep your CSS more maintainable.
In vanilla CSS, you need to specify and maintain the fallbacks for browser prefixes manually. This is ok, but it’s hard to manage over time and can lead to redundant code.
With preprocessors you can tackle this in two ways – either using mixins (ok solution) or by using a plugin called AutoPrefixer (best solution).
Using Autoprefixer, you can simply write the CSS properties as you would normally, specify the browsers that you would like to support, and the relevant prefixes get generated when your code is compiled.

@AshNolan_ :
PostCSS
Post-processor?
https://github.com/postcss
(11:00) Now Autopreﬁxer is actually a plugin for a different kind of processor – a tool called PostCSS.
PostCSS is actually a pretty new tool which has started to gain some attention because of the success of AutoPreﬁxer – has anyone here used PostCSS yet?
So PostCSS is being labelled as different to preprocessors like Sass and LESS, but if you’ve never heard of it before, what’s the difference between a preprocessor and a PostCSS?

@AshNolan_ :
PostCSS
- Lots of features, all rolled
into one tool
- Can’t extend if you need
added functionality
- Add features by adding
plugins
- Can write your own plugins 
if needed
Preprocessors
Preprocessors have lots of features, all rolled into one tool. But you’re stuck with those features unless you want to contribute to the tool itself, and even then it might not get accepted if you do that by whoever
owns that project.
PostCSS features are instead added by adding plugins. So imagine you start with a blank slate – you can then add just the functionality you require. So if you only want to be able to use variables, you can add a
plugin that will do just that. The same goes for Nesting and browser preﬁxes (using autopreﬁxer), you simply add the relevant plugin and it’ll transform your code in the desired way
This is great because perhaps like our team at JUST EAT, potentially anyone can edit the projects CSS and add to it. Now if you use a preprocessor like Sass, you have to make sure that people are using all of its
features sensibly, such as nesting and extends, and sometimes these can cause problems, as I’ll talk about in just a minute. With PostCSS, if you want to you can simply not include that functionality.

@AshNolan_ :
Essentially, you can create your own unique
preprocessor out of PostCSS plugins
Essentially, you can create your own unique preprocessor out of PostCSS plugins with as much or as little functionality as you require.
Now if this all sounds too good to be true, at the present time it is a tiny bit.
We actually looked into using PostCSS as a replacement for Sass in our workflow at JUST EAT, but currently it doesn’t quite have all of the features that we would want to be able to make the switch. But that doesn’t
mean it might not fit well for your project.
If you’re looking for a lightweight alternative to a preprocessor, PostCSS is definitely one to have a look at.

@AshNolan_ :
- It’s a pretty new tool, which means there
are a limited number of plugins (atm)
+ It’s got incredible potential
PostCSS
In Brief
http://ashn.uk/postcss-intro
So in summary…
- It’s a pretty new tool, which means there are still only a limited number of plugins available. You can write your own, but you’ll only want to do that if you have the time.
+ It’s got a lot of potential. Mark Otto, the Creator of Bootstrap, has said that BootStrap 5 may well be written in PostCSS, so it’s attracting plenty of attention

@AshNolan_ :
- Structure
- Maintainability
- Flexiblility
(15:00) So, taking a step back, we’re always looking to achieve these 3 things when we write our CSS.
Structure, Maintainability, Flexibility.
Using a preprocessor helps us to reach these goals when used responsibly.

@AshNolan_ :
but…
but…and there’s always a but…it’s that word 'responsibly' that is the most key in my last sentence…

@AshNolan_ :
When we use tools like preprocessors we’ve got to make sure we don’t become like this dog.
For me, preprocessors are brilliant things, but they can also be quite dangerous in the wrong hands.

@AshNolan_ :
Irresponsible Preprocessing
Nesting
.availableTimesContainer { …
.tablularDiv { …
.dayOfTheWeekContainer { …
.dayOfTheWeek { …
.cell { …
&.cell:hover, &.selected { …
.modal { …
&.modal.top { …
.arrowUp { …
}
}
}
}
For example, this was a legitimate piece of code I came across when I inherited a project from a freelancer at my previous company.
Now my initial reaction when I see this type of code is something like…

@AshNolan_ :
.availableTimesContainer .tablularDiv .dayOfTheWeekContainer .dayOfTheWeek
.cell.cell:hover .modal.modal.top .arrowUp,
.availableTimesContainer .tablularDiv .dayOfTheWeekContainer .dayOfTheWeek
.cell.selected .modal.modal.top .arrowUp {
…
}
.availableTimesContainer { …
.tablularDiv { …
.dayOfTheWeekContainer { …
.dayOfTheWeek { …
.cell { …
&.cell:hover, &.selected { …
.modal { …
&.modal.top { …
.arrowUp { …
}
}
}
}
Irresponsible Preprocessing
Nesting
Now this kind of thing makes me almost as sad as when I was having to use stuff like SIFR, but the difference is that this is completely self inﬂicted.
This actually compiles out to this (click) which is something we should never write in CSS.
As developers, we have to be more responsible than this, but although this is an extreme example accentuated when using preprocessors, if I see deep nesting of any sort it’s a clear sign to me that someone
doesn’t understand how to write modular CSS, with or without preprocessors.

@AshNolan_ :
- Structure
- Maintainability
- Flexiblility
(16:00) So coming back to the three points that I just mentioned, these should also be our goal when writing CSS of any kind even if we aren’t using preprocessors.
Now this is one area in which our thinking has changed quite a bit as the web has grown over time.

@AshNolan_ :
CSS Methodologies
CSS Methodologies and naming schemes in particular are becoming more and more popular currently and are quite frequently talked about – but essentially they all share very common ground.

@AshNolan_ :https://smacss.com/
As far as I’m concerned, if I could advise anyone writing CSS to go and read one book on methodologies, it would still be this one: SMACCS by Jonathan Snook.
I actually read this about halfway through working on the BBC Good Food Redesign a few years ago, and it pretty much described and addressed the majority of the issues I came across while writing the CSS on that
project.

@AshNolan_ :
- SMACSS
- OOCSS
- Atomic Design
- BEM
- ITCSS
- SUIT
CSS Methodologies
Loving the Acronyms
Now the important thing to consider when thinking about CSS methodologies is to understand that they don’t all have to work in isolation. In fact, their true power comes from combining them for your own needs.
For example, I tend to use parts of all of these on my projects, because that’s what ﬁts my needs.
To take this even further, it can be a good idea to build up your own base projects.

@AshNolan_ :http://ashn.uk/ko-intro
Now by this, I don’t mean rewrite bootstrap for yourself, but ensuring that your team uses the same conventions across projects is really useful.
So for example, at my last company, we did a lot of smaller projects, and there was a team of about 6 front end developers working across these projects.
To keep consistency, we built our our base framework, called Kickoff. The only aim for Kickoff was to provide a similar folder and ﬁle structure when building sites, and to deﬁne consistent naming conventions.

@AshNolan_ :
Naming Schemes
Kickoff CSS Naming Scheme
/* Descriptors use camelCase if more than one word: e.g. twoWords */
.skipToContent { ... }
/* Child elements use single hyphens: - */
.form-controlGroup { ... }
/* Modifier element use a double hyphen: -- */
.btn.btn--primary { ... }
/* Element state: .is- or .has- */
.is-active { ... }
http://ashn.uk/ko-naming
So for example, Kickoff’s naming scheme looked like this.
Explain.

@AshNolan_ :
It’s best to understand and adapt CSS
methodologies and naming schemes, as
that’s where their true power lies.
In summary, it’s best to understand and adapt CSS methodologies and naming schemes, as that’s where their true power lies.

@AshNolan_ :
Atomic OOBEMITSCSS
http://ashn.uk/css-meths
Sitepoint actually published a really good article on this very subject last week – so if you’re interested in this kind of thing, I’d highly recommend checking it out.

@AshNolan_ :
- Use Preprocessors (responsibly)
- Draw from methodologies to help structure
- Define your own conventions
CSS Workﬂow
A Summary

@AshNolan_ :
Task Runners
(22:00) Now the other biggest workﬂow change since I started out in front-end development came with the introduction of Task Runners, such as Grunt and Gulp.

@AshNolan_ :
So Grunt and Gulp are both Task Runners that are built in JavaScript, that can automatically carry out some very useful development tasks for you.
So things like minification, concatenation of files, Linting of your CSS or JavaScript files, even creating local servers for you to develop on.

@AshNolan_ :
Gulp
- Been around slightly longer
- Slightly more packages
- Config based
- Tasks run in sequence
- Newer and Insanely Fast
- Slightly fewer packages
- Similar to writing JavaScript
- Tasks run in parallel
Grunt
Now there’s not a huge deal of difference between the two, but the main differences are that:
– Grunt has slightly more packages than Gulp (although it’s catching up)
– Gulp is much faster when it comes to running your tasks
– Gulp is slightly more intuitive to some developers, as it’s more like writing code than Grunt
– In Gulp it’s easier to do multiple tasks on one set of ﬁles than Grunt (uses streams)

@AshNolan_ :
NPM
The main thing you need to know about Grunt and Gulp is that they both run using Node and make use of a package manager called NPM, which stands for Node Package Manager. NPM comes bundled with Node
when you install it.
As of when I wrote these slides, there were 165,274 packages on NPM – so it’s very widely used.

@AshNolan_ :
Reasons…?
There are tonnes of reasons why I think that task runners are useful. Being able to run local servers that live update and auto compilation of CSS and JavaScript ﬁles is really nice, but there are other Apps like
CodeKit that also does this kind of thing for you.
So why use task runners instead of them?

@AshNolan_ :
Using a task runner helps to define a
consistent workflow across your team
The most valuable reason for using a task runner in my opinion is that they help you to define a consistent workflow across your team
So without using a task runner, if you want to use a preprocessor or even if you just want to simply minify and optimise your CSS, JavaScript and images, you don’t have a defined way of doing this.
Some people might use CodeKit, others might use command line, for minification you might just use an online tool. The problem with this is that for people new to a project, this is extremely slow and poorly
defined. They have to work out how to do these tasks when they get to it themselves as there’s no clear process. Worst case, they might even do it at all.
Using a task runner you can define the workflow of your project for anyone developing on it. Using Gulp or Grunt, you setup a bunch of tasks that are then available for anyone working on that project.

@AshNolan_ :
Even better, you can ensure tasks get run
on your production server when code is
deployed
For more advanced users, you can also make sure that certain tasks get run when your code is deployed.
So rather than manually compiling files yourself and putting them onto a server, you can setup a build server that can run tasks that you have defined and deploy that for you.
This means the risk of having un-minified code or unoptimised images on your website is zero – human error is removed.

@AshNolan_ :
…and you don’t need to know Node or
command line to use task runners
One of the common myths around task runners is that they’re difficult to learn.
Task runners are actually really simple – you don’t need to learn Node or be an expert in command line to use them, you just need to know how to type 'Gulp' or 'Grunt'.

@AshNolan_ :
Task Runners
Tutorials
- http://ashn.uk/grunt-tutorial
- http://trykickoff.github.io/learn/grunt.html
- http://ashn.uk/gulp-tutorial
- https://github.com/greypants/gulp-starter
Grunt
Gulp
Now unfortunately I don’t have time to go into how to actually setup and use these tools now, but I’ve put together a few links for anyone wanting to get started with either Grunt or Gulp.
I will show you just how streamlined you process can be once you have your task runner setup.

@AshNolan_ :
Static Generators
(26:00) Now the last thing I want to cover tonight is static site generators and why I think they’re useful.
So a static site generator is essentially a tool that takes some content or data that you give it, like markdown or JSON, a set of templates ﬁles written in HTML, and then combines them to compile a set of HTML
ﬁles.
So it’s a really a very simple way of being able to manage content while still being able to separate it from your HTML templates.

@AshNolan_ :https://www.staticgen.com/
So there are quite a few Static site generators around.
The most popular is called Jekyll, and it’s really good for creating simple sites. The one I use is called Assemble and I like using it because it’s a little bit less restrictive than Jekyll and you can do a lot more with it.

@AshNolan_ :http://ashn.uk/statix
Now I actually built a tool myself that uses Assemble, as well as the framework that I was talking about earlier, Kickoff.
And the idea of this tool was to make it really simple and quick to start developing templates, and it’s kind of grown into a tool I still use now because I ﬁnd it so useful.

@AshNolan_ :
Live workflow demo
So I’m going to ﬁnish by attempting to demo it to you very quickly as I think it gives a good example of how streamlined you can make your own workﬂow with a relatively small amount of effort.

@AshNolan_ :
- Preprocessors Good
- …but don’t forget CSS fundamentals
- Task Runners Good
- Aim for consistency and ease of setup
Front end Workﬂows
A Summary

Ashley Nolan
Senior UI Engineer at :
@AshNolan_
Thanks

Reworking our-workflows

More Related Content

What's hot

Viewers also liked

Similar to Reworking our-workflows

Recently uploaded

Reworking our-workflows