Ashley Nolan

Senior UI Engineer at :

@AshNolan_

Exploring our Front End Workflows

Hi, I’m Ashley Nolan. I’m a Senior UI Engineer working just down the road at JUST EAT here 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 workflows.

@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 workflow.

I’ll go into some of that throughout my talk but if you have any questions about that or anything else that I cover today, there will be some time for questions at the end of the talk or just come and grab me later and I’ll do my best to answer anything.

@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 that was when I was first 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 workflow 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 CSS 1.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 flawed.

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

CSS CSS 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_ :

(5: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 find.

@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 finally 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 fleshed out and the browsers to implement all of the features that could help us.

So how do we mitigate for this in the meantime?

@AshNolan_ :

The obvious answer is to use CSS Preprocessors.

So out of interest, how many developers here use preprocessors in their workflow?

Preprocessors now are pretty mature – lots of developers are using them, which is great because they are extremely useful.

@AshNolan_ :

Current statistics for usage of CSS Preprocessors Based on a survey of 2028 devs – September 2015

http://ashn.uk/survey-res

In fact, I actually ran a survey last month on Front-End tooling, in which over 2 thousand front-end developers answered some questions about the tools that they currently use.

One of the questions I asked was about preprocessors. As you can see from this chart, 85% replied that they now used a preprocessor in their workflow – which just goes to show how important a tool they have become.

I know for me personally, they are one part of my workflow that I would genuinely find it hard to develop without.

@AshNolan_ :

Benefits?

But what are the benefits of using a preprocessor?

So I get that I’m preaching to the converted a bit here, but I want to highlight the things that I think are the killer features of preprocessors.

So forget nesting and mixins, which are really handy when structuring your CSS, I think there are a few 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_ :

Why use Preprocessors?

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 file paths, when using images for example, specifying your major breakpoints when using media queries, and for defining 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_ :

Why use Preprocessors?

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_ :

Why use Preprocessors?

IV. Inlining Images (using postcss-assets)

/* inline('path') automatically converts an image to a data uri */

background-image: inline('icon-arrow.png');

background-image: inline('logo-fb.svg');

Inlining images

One of the biggest bottlenecks to performance on mobile is http requests, as they cost you a lot in terms of the amount of time spent looking up assets.

Now, to avoid this, you can inline some of your images within your CSS, particularly icons that are an enhancement to text.

So to do this, you can use a plugin that let’s you simply write inline() and this will convert the image specified into a data uri when your CSS gets compiled.

@AshNolan_ :

PostCSS

https://github.com/postcss

(11:00) Now Autoprefixer and PostCSS assets are actually plugins for a different kind of processor – and that’s a tool called PostCSS.

PostCSS is actually a pretty new tool which has started to gain some attention because of the success of AutoPrefixer – 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 something like 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 pluginsif 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 prefixes (using autoprefixer), 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 full 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. Instead we’re using it in addition to Sass, using just the features we need.

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 they’re 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_ :

@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 inflicted.

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_ :

Keep selectors short and clear so that they are more extensible and reusable

Try to keep your selectors short, so that they are more extensible and reusable.

As a general rule, you should never be nesting more than 3 levels deep.

@AshNolan_ :

.btn {

font-weight: bold;

}

.header .btn {

color: red;

}

.myOtherBtn {

@extend .btn;

}

Irresponsible Preprocessing

@extends

//compiles to the following CSS

.btn,

.myOtherBtn {

font-weight: bold;

}

.header .btn,

.header .myOtherBtn {

color: red;

}

Another often abused feature of preprocessors is the @extends functionality, and this is often because people don’t properly understand how it works.

@AshNolan_ :

.btn,

%btn {

font-weight: bold;

}

.header .btn {

color: red;

}

.myOtherBtn {

@extend %btn;

}

Irresponsible Preprocessing

@extends using placeholders

//compiles to the following CSS

.btn,

.myOtherBtn {

font-weight: bold;

}

.header .btn {

color: red;

}

@AshNolan_ :

Use Preprocessors Responsibly.

Only use them when they help with Structure and Maintenance.

Be sensible with preprocessors – only use them when they help with your projects structure and maintenance.

That’s the good thing about preprocessors, if you don’t know Sass or Less, you can simply write CSS and it’ll still work.

So enhance where you can improve that base functionality – don’t go nuts simply because you can.

@AshNolan_ :

- Structure

- Maintainability

- Flexiblility

(18: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_ :

- Modular Code

- Thinking (and styling) in Components

- Avoid undoing styling, encourage extension of styles

- Reuse

- Consistency

CSS Methodologies

What they encourage

So a CSS Methodology is just a way of thinking about writing and structuring your CSS and they are all about encouraging:

– very modular code– Thinking and Styling in components– To avoid undoing styles, and instead extend styles with each class that you add to an element– they encourage writing CSS that can be reused across components– and encouraging consistency in the styles that you write – which is really important on team projects where you have multiple developers editing the same CSS.

@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.

So SMACSS is all about making your CSS more modular, so it’s easily reusable, but the book also goes into a lot of detail over idea’s around components and common issues people face on larger projects – and the author applies this to the work that he did while he worked at Yahoo.

@AshNolan_ :

- SMACSS

- OOCSS

- Atomic Design

- BEM

- ITCSS

- SUIT

CSS Methodologies

Loving the Acronyms

Now in terms of other methodologies out there, here are a few more of the most popular ones.

– So you’ve got SMACSS, which I just mentioned…– OOCSS – Extending classes to build up styles on components…– Atomic Design – Breaking components down into the smallest reusable chunks and building larger modules out of these…– ITCSS – about having clearly defined structure and modularity in your code

Now the important thing to consider when thinking about all of these 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.

To take this even further, it can be a good idea to build up your own base projects, taking the parts of the methodologies and frameworks that you think are the most relevant.

@AshNolan_ :http://ashn.uk/ko-intro

As an 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 a base framework, called Kickoff. The only aim for Kickoff was to provide a similar folder and file structure when building sites, and to define consistent naming conventions.

The framework basically took the parts of different methodologies that we liked to give us the minimal possible starting point on projects.

@AshNolan_ :

It’s best to understand and adapt CSS Methodologies and Naming Schemes, as

that’s where their true power lies.

So like I said before – as with any kind of best practice advice, it’s best to understand and adapt CSS methodologies and naming schemes, as that’s where their true power lies.

It’s by doing this that you can adapt that knowledge specifically for your project and for your team.

One of the most obvious examples of this is when using CSS Naming Schemes…

@AshNolan_ :

Naming Schemes i.e. BEM or SUIT

(23:00) Naming schemes have become very popular over the last couple of years. They are heavily related to CSS Methodologies as they fit well into component driven CSS and that’s why a lot of people have started using them.

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, breaking things down into components, a naming scheme helps to describe the relationship between the classes in your CSS.

@AshNolan_ :

Now naming schemes aren’t designed to be restrictive. By using them, we’re not trying to make people do something they don’t want to.

They are simply to encourage people in the same team to write CSS classes in roughly the same kind of way, much like it’s sensible to enforce coding patterns when writing code for any programming language so that it looks consistent across a project.

@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 project2. Show the relationship between classes so that it’s clear from looking at a class which component it is a part of3. They help to show when someone has extended a class and modified it, reusing the existing styles4. And they help people write consistent state and utility classnames (such as active or open on an accordion)

@AshNolan_ :

Naming Schemes

Key Aspects of a naming scheme (BEM)

– Blocks i.e. -> .nav

– Elements i.e. -> .nav-item

– Modifiers i.e. -> .nav--inline

Naming schemes work by writing our classes in a certain way.

So we split our components up into clear chunks. We have blocks, which is the base of our components.

Elements, which are the pieces that make up our blocks. Elements therefore only make sense within the context of the block they belong to. If this isn’t true, then the class you give that element may be a component in it’s own right.

Modifiers are used when we need to create a block (or component) that is very similar to an existing one, but with a slightly different appearance of behaviour.

@AshNolan_ :

Naming Schemes

Blocks

Example of blocks

@AshNolan_ :

Naming Schemes

Elements

Elements

@AshNolan_ :

Naming Schemes

Modifiers

Modifiers

@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 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 fit with how our team want to work.

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 { ... }

http://ashn.uk/je-naming

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…

So everything is very tightly coupled. You can’t reuse classes such as rating, as they’re specified quite deep. 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 { ... }

http://ashn.uk/je-naming

Here you can clearly see relationships between classes within a component. So you have classes specific to a searchresults components, then a more generic listing component.

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

Using a naming scheme helps to re-enforce writing component driven CSS.

Using components is a good idea because it encourages reuse of classes and actually using the C in CSS, which is the cascade – and when used properly, this is the most powerful thing about CSS.

@AshNolan_ :

Methodologies and naming schemesare good

Now I could talk about component driven CSS all day long, but hopefully through the examples I’ve shown, you’ve got a sense of why it’s important to think about writing CSS in a more modular way and why naming schemes are a good idea.

I’ve only really scratched the surface of it, but there’s lots of great books and articles out there that go into a lot more detail, and I’d highly recommend checking out a few of them if you get chance.

@AshNolan_ :

Atomic OOBEMITSCSS

http://ashn.uk/css-meths

Sitepoint actually published a really good article on this very subject a few months ago – 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 for consistency

CSS Workflow

A Summary

@AshNolan_ :

Task Runners

(31:00) Now the other biggest workflow 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 files 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…?

Now what you may be thinking is – I can do all of these things already with other tools.

While there are a tonne of cool things that task runners can do, like running local servers that live update and auto compilation of your CSS and JavaScript files, there are other Apps like CodeKit that also does this kind of thing for you.

So why would you use a task runner 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 build server when code gets 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.

What I will show you in just a second is how streamlined your process can be once you have your task runner setup.

@AshNolan_ :

Static Generators

(35:00) Now the last thing I want to cover 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 files written in HTML, and then combines them to compile a set of HTML files.

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

Static Site Generators

Styleguides

Now I actually built a tool myself that uses Assemble, and was another tool we used at my last company when starting projects.

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 find it so useful.

@AshNolan_ :

Static Site Generators

Styleguides

Similarly, we use Assemble to build our front-end documentation and Styleguide at JUST EAT. Now this is useful, because it runs off all the same CSS as the live site does, so if someone changes a colour or typography sizing in the site CSS, it automatically gets reflected in the Style Guide.

And I’ll show you a live example of that in just a second.

@AshNolan_ :

Live workflow demo

So I’m going to finish 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 workflow with a relatively small amount of effort.

@AshNolan_ :

- Preprocessors Good

- …but don’t forget CSS fundamentals

- Task runners help align teams and projects

- Static Site generators can streamline your workflow

- Aim for consistency and ease of setup

Front end Workflows

A Summary

@AshNolan_ :

ashn.uk/exploring-our-workflows

The slides are up here

Ashley Nolan

Senior UI Engineer at :

@AshNolan_

Thanks