[APPLAUSE] Thank you.

Oh, what an introduction.

That's lovely.

So much explaining to do, but I'll save that for another time I think.

First of all, thanks for having me.

I'm really delighted to be here.

Fronteers is just one of my absolute favorite conferences, and it's great to get a chance to just come and attend, let alone come and be on the terrifying stage.

So I'm really, really delighted to be here.

A very quick introduction.

As Bruce says, I'm Phil, Phil Hawksworth.

And I work at an agency in London, kind of an advertising agency in London called R/GA.

There's going to be some Q&A at the end.

But if you don't get a chance to get a question on there, you can grab me afterwards.

Or you can tweet at me.

My Twitter handle is just my name.

So it's easy at least for me to remember, @philhawksworth.

So yes, and any questions you like, or any comments.

Arguments, if you disagree with the kind of things that I'm saying.

Suggestions.

Maybe you guys are doing things better than the way that I'm describing them.

Hangover remedies, also very willing to hear some of those.

Any of these things are fine.

You choose which you think is the most appropriate.

I'm really impressed, by the way.

Congratulations to you guys for making it here this morning.

(9)00 AM is an early start after the festivities last night.

Who made it to the after party last night? Were many people up? Pretty much most people.

That's impressive.

And how many of those people hit snooze more times than they usually would this morning? Pretty good discipline.

Most people have done well.

Well, I think you guys are the real heroes of the conference, the ones who've made it here for this session.

A bit of an apology to start off with.

I will be using some large fonts in this presentation.

So apologies for people with the sore heads.

There will also be bright colors.

Whoa! I can see that's bright already.

Jesus.

Occasionally, I will be using both big fonts and bright colors.

So hold onto your hats.

So as I mentioned, yeah, I work at an agency in London called R/GA.

And we make stuff for clients.

We work for people like Nike, Google, Beats by Dre.

Fairly large brands.

We make all kinds of things for them.

But the stuff that I care about is the stuff that we make for the web.

I hate people who come to conferences and try and use their talk as a chance to hire people.

So we won't do that.

I won't mention that we're hiring.

I won't mention that it's for front end developers or that it's in London.

We'll skip past that, because no one wants to be that guy.

So let's try and get back to the point, this talk about static sites and how they can go all Hollywood.

This talk really has been born from a bunch of other rants that I've had in the past.

And all of those are really around the fact that I love the web.

I really love the web deeply, and I think it's something that's an amazing industry to work in and to be a part of.

And I really particularly love the URL and the power that it has, and how it's this building block of the web.

I'm keen at this point to share something with you that has damaged me.

And that is this view of the URL, which I've discovered that-- Alex Sexton introduced this to me-- the fact that every URL has HTTP double meh in it.

And if you're kind of curious, there he is.

There he is! So that's not helpful.

There's no value you get from that.

But I'd just like to share that, because I don't want to be the only person who's damaged by that vision.

A few years ago, I came and stood on this stage, and I gave a talk about content management systems, and how they smell.

And CMS's-- I don't know how you pluralize CMS's.

Content Management Systems, CMS's.

It's kind of-- it's tricky.

I don't know.

CMS's was something I talked about, and how difficult they were to do well.

It's all fine now.

So that's fine.

That's all solved.

Well, it's not completely solved.

It's still a bit tricky.

But we've moved along.

There's still a lot of complexity in content management systems and how they impose things on the web.

But that's not what we're talking about today.

But I want to mention it, because the talk that I'm going to give has been born from the fact that building stuff for the web can be hard.

It's really difficult. And

for those people who are the-- I was going to call it the smack-down.

It wasn't the smack-down.

It was the jam sessions.

But I'm thinking about the Jake/PPK debate that was there.

That kind of is testament to the fact that the technologies that we're using are complicated, and there are many of them.

And it can be a hard environment to work in.

Not least of all, as well, because of the devices that we have to support.

We have no idea what devices are under the Christmas tree at the end of the year, as Brad Frost likes to say.

And building for those things is hard.

And also, we don't necessarily know what view-ports there are, what screen sizes do we have to fit things into? It's incredibly difficult to do this stuff now.

I really love as well-- this is just a bunch of visualizations captured from people's analytics about the screen sizes of the most popular views of their site.

It's fascinating to me that every different site has a completely different kind of footprint.

It's really interesting to me.

Let me grab some water way over here.

And so-- that's dangerous.

Now I'm very interested in removing the obstructions to building with quality.

These things are really hard.

So any way that we can simplify, I'm really keen.

I also think of that as removing obstructions to longevity.

Because the web should be something that lasts for more than a blink of an eye.

At R/GA, we are often involved in building campaign sites as well as products.

And those campaign sites don't always necessarily have an intended, long shelf life.

But I really care about building things that do, and that can live on.

I'm amazed that this is the first time this has been up on the screen, I think, and the conference.

But it might not be the last.

But the first web page is still very much accessible and viewable and available on the URL that it was published on.

It's still there for us to see.

And that's partly due to the simplicity that's there.

It's really doing things at the minimum viable web page, you could argue.

But it's this notion of simplicity that I really love and I really embrace.

And that's captured, a little bit, in this phrase "bake don't fry," which this slide actually doesn't make some sense here.

This is a guy called Paul Hollywood, who was involved in the great British bake off in England.

I was very motivated by Alice's talk yesterday, where she really went the extra mile and started doing research about the accessibility guidelines in Holland-- in the Netherlands, rather.

So I wanted to go the extra mile as well and try and do my research as well.

So Heel Holland Bakt is the program over here, I understand.

And Robert van Bakeoven… Bakeoven? Really? Is that his name? Does anyone know? Nobody knows this guy.

But it doesn't matter, because this phrase, of course, really is one that was popularized by Aaron Schwartz, who coined this phrase, or really kind of heard it and made it popular when he was looking at ways to make his blog more efficient.

You know, this is not a new thought.

Aaron Schwartz said some very poignant things.

And this isn't necessarily the most poignant, but it resonates with me.

He mentioned that, I care about not having to maintain cranky AOL server, PostgreS, and Oracle installs.

He said this back in 2002.

This really resonates with me.

You know, often the kind of default stack that we use on some of our sites is incredibly complicated.

Because those are the tools that are available.

We want to use the new shiny, and so we use them.

But Aaron was kind of thinking about the best fit for his blog.

What are the tools that are exactly right just for a blog? And critically there, he was thinking about what is the usage on a site like that? There may be only a few writes, but many, many reads.

And so finding the tools that service that correctly, that's really valuable.

And you have an opportunity to strive for some simplicity that takes a lot of pain and anguish out of the way.

Now simplicity isn't very Hollywood.

It's not the sexiest thing to hear about, and especially after dragging yourself out of bed with a hangover in the morning.

But simplicity is beautiful.

And simplicity, critically, is not dumbing down.

I think that's a really important point.

And on the web, we've got plenty of opportunities for complexity to creep in.

We've all built things that started simple and then ended up more complicated.

And simplicity is something that's very, very apparent here.

But I'm also very conscious that we don't want to just make things as bland or as base as possible.

You know, there's room for creativity, as well.

And that, of course, lives on.

I related very much to some of the comments from the guys from Primate yesterday.

Esben, I think, was talking about his desire to keep a lot of creativity in the web, and experimenting with things in the front-end that maybe are a little bit out of vogue.

And this kind of came to mind, this illustration that a friend of mine did for an article.

There's a few subtle things in here.

I don't know if you can pick up the message he had.

He's an Illustrator, and he's very frustrated with the way that so many of us are striving for design patents that are very similar to each other, and kind of quite uniform.

This particular guy who drew this, I worked at an agency with him.

And at the point I joined, we were building a site for a well-known restaurant in London, and it was being built as a big flash extravaganza.

And my first point of order was, well, maybe we're going to build this from the web, rather than that.

And the guy who built this, Steve, he's a Flash developer.

And he knew how to make everything he needed to come to life in that.

There's a subtle thing in this picture.

He did say to me, please, Phil, don't take my Flash away from me.

I don't know if anyone noticed the subtle message he was sending me, I think, as he drew this.

But the idea that things are becoming uniform and kind of following the same patterns is something that I know that people are cautious of.

But I'd say, again, that simplifying is not dumbing down.

Let's just focus on what really matters.

And that really lets us tune in on getting things absolutely right and delivering the right kind of experience, the right kind of optimizations for the users and the experiences that we need.

Alice's talk yesterday was a great example of that, of how beautiful design doesn't necessarily need to be flashy.

It's about doing the right thing.

So static sites.

I want to just pause for a moment and talk about some of the benefits.

I'm just going to do that quite briefly, and then move on to more detail afterwards.

Some of these things will kind of seem obvious, I think.

The fact that if you got a static site that you're serving, you've got access to much cheaper, sometimes free, simpler hosting.

Because you're just serving static files.

There are fewer points of failure as a result of that.

You haven't got lots of machinery and moving parts in your production environment, which is a fantastic thing.

Because that means that you've got fewer vulnerabilities, fewer attack vectors for people to tinker with your site, and just fewer places for things to go wrong.

Easier compliance is something which of course gets all of our blood pumping on a morning like this.

But it's kind of important, the fact that if you're working with clients that have very, very strict controls over their infrastructure and where you can host your site that you're building for them, the simpler that can be, the better in many cases.

Because especially with big companies, the kind of control and rigor that they have, and the level of audits you have to go through with every piece of technology you deploy, can be a huge barrier.

So building things in a simple way that you can just, here are some files, those get deployed into your static serving environment.

It's incredibly liberating.

And of course there's things like greater portability.

You're not coupled to an environment if it's just serving static files.

It's very easy to move from one place to another.

I'm sure we've all intended to move our blog or our site from one place to another.

And then, ah, it's just a little bit more painful than I thought.

This kind of eases that as well.

And then there's things like having sandbox environments.

It's very easy to replicate the environment that you have from one place to another because of the simpler set of tools that you're using.

And things like, you can avoid attrition over time.

That's my favorite, the fact that my web host sometimes upgrades its environment, which is wonderful.

But sometimes that breaks things for me if I've got a lot of complexity there.

I don't really like to knock WordPress, because I think WordPress is a fantastic product.

But this is a kind of screen that I've seen lots of times in the past.

This is my favorite.

I don't know if this is familiar to many people.

I really like this because of the fact that it says error, error, error, error, success! Yay! I was always confused by that.

But again, I'm not bashing WordPress.

WordPress is just an incredibly wonderful product, incredibly powerful.

And we use it a lot at R/GA as well.

And I have also seen it used as the engine for a static site generator that actually outputs static sites as well.

So certainly not trying to knock WordPress.

So I want to just talk a little bit about the credibility of static sites.

Because it could seem that-- these things are fine, but they're for simple things.

They're just for your little product landing page, or a little campaign site that's going to be gone very quickly.

Because it's not the case.

Many people have seen this.

Again, this isn't new.

This is like 2012.

We're not trying to elect Obama anymore.

That job is done.

This is a very well known case study, a guy called Kyle Rush who was involved in re-architecting that site, raising funds for that campaign.

And the aim of that was to really reduce the time for iterating the site, make it cheaper and easier to serve the site.

The stats on there, it's a really fantastic case study to read, if you ever missed it before.

It's things like 60% faster load times as a results of the re-architecture.

Over a six month lifespan, it had 81 and 1/2 million views, something like 18 million uniques.

So static sites are perfect for serving that kind of large audiences and being able to iterate really quickly.

That's a great case study to look at.

That site was baked with Jekyll.

So it's a very, very popular static site generator that many people will be familiar with.

As I mentioned, it had a very large audience.

The rapid iterations were something that were key, and being able to simplify that environment and iterate quickly was a real goal.

And it was hosted statically.

A project we did at R/GA a year or so ago was the Google web fundamentals site that many people will be familiar with.

This also was a static site.

The content was managed on GitHub, in the open.

You can contribute to it yourselves.

It was baked, again, with Jekyll.

And then that was served statically by Google in their hosting environment.

This again is-- the decisions to work in this way were incredibly liberating.

Building a site like this, an external agency being involved in doing that, it's just incredibly difficult for many organizations.

And Google, of course, are very cautious about what code anyone can deploy onto their dot com.

So the fact that it's static, and it's managed internally, it's just incredibly powerful.

So it's that reduction of risk that is just an incredibly empowering thing.

Just another quick example.

You know, Google Year in Search, another project that we worked on.

Again, it's a static site that you may have seen at the end of last year.

It's the kind of annual retrospective of what's happened in search that Google do.

And this had a very large audience.

And it was infrequently updated.

So it's kind of a prime candidate for this kind of write once, or write very few times, and then be read many times kind of model.

This is a classic example of a site that really needs to have a long life.

I mean, I think all sites should.

But this is something that's a retrospective for years to come.

And it's not very large.

So it's only 40 bits of content, 40 stories.

But those are all translated into 52 languages.

And there's a big audience for this.

I don't have the actual end analytics for the site, but there were like 2.6 billion impressions

on social that were all feeding to this in the few months leading towards the end of last year.

So this was a site that was built in a similar way to the ones that you've seen just before.

The content was abstracted out, and it was baked with something called Goro, which is a static site generator internally at Google.

And it was served statically.

And it's another one of these examples where the desire to have a fairly complex authoring environment for lots of different authors to work on should never really impact the production environment.

We wanted to break those things apart so that we wouldn't be terrified that the things would fall over as the audience came along.

So the point that I'm trying to make with just those three little examples is that static sites are already mainstream.

They're already in production and out there for large brands and large projects, and it doesn't need to just be the small campaigns that are using them.

And that's come about because of a few different enablers.

We can be much more effective now.

The front-end tooling that exists is a key part to this.

And Wes is going to do a talk following this which is going to dig into that a lot more.

But you know, the environment has moved on for us in the front end of the tools that we have.

You know, this is a common conversation I used to have years ago.

I would talk to someone, say, oh, I'm a software engineer.

And they'd say, oh, what language do you use? And I'd say JavaScript.

And then they'd have this kind of immediate response.

Thankfully, we've moved on from that now.

We're much more credible.

We're not trying to be convinced to learn Java as a couple of people were talking about yesterday.

And so this leads us to the incredible wealth of generators and templating engines there are for us to use when we're building these things out.

Staticsitegenerators.net

is this site that you may have seen that catalogs as many known static site generators as possible.

393 there are for you to learn.

So we better get started.

Number one, we're going to go through.

So there's lots of these things, and this changes all the time.

And I find this really difficult, because I always want to see what the latest one is and start experimenting with it, and try and resist the temptation to migrate my site over to it, because it's the new toy.

And I kind of talk about this sometimes as like the hipster tax of wanting to use the latest and greatest kind of trendy toy.

But that's a bit of a danger.

So yesterday, Anna spoke about style guides, gave a great talk on style guides, and covered a lot of things that I don't need to talk about now, which is great.

But one of the things I love about using static site generators is that you can build things in such a way that a style guide can kind of be a side effect, or more like an artifact of what you're building.

It's maybe not completely fair.

That may be oversimplifying a little.

I prefer to think of the style guide as being part of the process.

It's the way that you can build things that produces a style guide, as well as your ultimate site.

Nicole Sullivan talks about style guide driven development a little bit, as well, which I'll touch on in a second.

And certainly when we were working on the web fundamentals project, having a style guide was incredibly important.

This is a tool that enabled us to move very, very quickly.

That project took just over a month, really, to do.

And the only way that that could happen was by getting into the browser quickly and showing components that we're building in a browser, so that we could then iterate them there.

And Anna talked a little bit about things like style tiles yesterday, and giving visual roots very quickly, and designed Roots very quickly, that we could then iterate on.

And that was a core kind of principle of this particular project.

And I just want to touch on how that can happen, and how a style guide can almost be a secondary output, or another output, of your process.

You know, you can start building a library of modules or of patents, I think, as Anna was talking about them yesterday, elements that are going to live across your site, and then incorporate those into some templates through your build process.

And static site generators often have some build tools of their own.

But otherwise, you might be using some of the popular ones that exist that I imagine Wes might be talking about later on.

And those can generate your style guide.

You can be combining your modules through these templates and outputting a style guide.

And then your build process might be doing deployment to a staging environment, or a UAT environment, or any environment for people to be able to check and understand the style guides and see what the building blocks of your site are.

But then critically, you want to start adding more templates here that are actually going to be the meat of your sites, your actual site.

And then, by incorporating the content into those, but then still using the same modules and the same patterns, your build process can then start outputting both your style guide and your actual site.

But it's very important that those things are kind of using the same modules, the same building blocks.

Anna talked a little bit yesterday about zombie style guides, and that's the thing to avoid.

And in production, I guess, you have some optimization in there as well.

So quite quickly, you can start building up this kind of framework, where you're using the same tools to output your style guide as you are to output your site.

And I think this is really important.

I like to think that unless this is part of your build, your style guide is just more documentation to maintain.

Again, this notion of a zombie style guide.

And that was talked about a little bit later on.

It's such a common thing to start with the best of intentions and create a style guide at the beginning that's not part of your build, not part of your actual tools that you're building in the production site, only to then have to maintain them forever.

And it's another piece of documentation.

So keeping them together is critical.

Again, to quote Anna from just yesterday, it's a system which is talking about pattern libraries.

A system-- a living, breathing library of components.

And I think that's a really critical thing to keep in mind.

And that, of course, is enabled by the kind of automation that we have now.

The fact that we have tools like Grunt, like Gulp, like Brunch.

There are others.

There's probably Belch, Burp, Cough.

Sneeze is coming.

Sneeze is going to be a good one.

This is the hipster tax zone again.

I actually put this slide up at another conference and before I'd even sat down, someone had registered sneezedeploy.com

and was like, let's do this! And we're ready to go.

I love the idea that you can sneeze it to production.

But watch this space, I think.

But the key is that these kind of tools allow us to not just build, but also deploy faster and deploy more safely.

Reducing the friction there means that you can update faster and update more frequently, which makes things feel very much more dynamic.

The fact that there's less risk, less friction to deploying things means that they're updated more frequently.

And there are some fantastic tools for doing rapid deployments of static sites.

I really like this one, which I think has been talked about quite a bit-- Surge.

Incredibly simple tool to use that-- you install MPN-- MPM, sorry.

And then it's just a single command for you to push the folder that you're in up to a host and creates a virtual host for you there.

Really, really simple to be able to just push things out there.

And this has-- obviously it does more than this, and you can use it in much more powerful ways.

But just really, really reduces that friction.

So all of these tools exist, and it's great we can feel, OK, yeah, we can start using static site generators.

We can start managing the content in ways that's going to be quite easy for us to use.

But eventually, you do hit this ceiling.

And I think one the reasons for that is because a lot of these tools do require us to have a bit of a developer mindset.

Not everyone who's going to be involved in updating on a content on a site is going to want to work in this way.

Developer mindset isn't very Hollywood, necessarily.

Although sometimes we all relate very, very closely to the life of a developer as portrayed in the movies.

But we still want that kind of shizzle, that excitement.

And users and content managers still want to be able to manage the content themselves without having to become a developer.

So we should look at ways that we can kind of take the complexity out of this a little bit.

So to do that, I want to look at some common complexity in typical sites.

So where do we start? We start with some views, some templates-- the kind of thing that many of us have been involved in building.

And those will be outputting some content for the user to consume.

And those views, or templates, those are probably driven by some kind of server logic that's talking to some database, some source of content, and then populating the templates and then outputting them as needed.

And at some point, we're probably going to put some kind of caching layer in front of that to speed things up a bit.

And we can confidently feel that we're delivering something to a user that's usable.

And then, at some point, we're going to come along and go, well, now we need to administrate this content.

So we need an admin view of this stuff as well.

And so templates are built for that, to serve that to the admin users.

And that has some server logic itself, and that's probably manipulating the same set of data that then is going to be passed out to the other users.

And that's all kind of wrapped up in some kind of production environment, maybe on one server, maybe on several.

Who's to say? And that's all replicated across into probably a staging environment, probably a QA environment as well, and also a development environment.

So this starts getting-- there are lots of moving parts here.

There are lots of bits of integration, lots of bits of plumbing that happen.

And I was saying at the start that I want to reduce complexity.

And so it's something that I'm really keen on doing at the moment is using other people's plumbing.

It's not a very pleasant expression, not wildly keen on it.

But the idea that we can use other people's infrastructure is kind of attractive to me.

So how might that look? Well, let's start this time-- instead of with a production environment, let's start with a development environment, see what things look like there.

I'm assuming that we're going to have some kind of static site generator, one of the 393 that I showed on screen earlier on.

Something like Jekyll, perhaps.

And that may or may not include its own build process, but we might use something like Gulp or Grunt or something similar-- Sneeze, if it's there-- to kind of help us output and generate that static site.

And that, in itself, is enough to kind of create something statically and put it where you want to host it, serve it to the user.

That's your kind of minimum viable environment.

But we want to be able to manage content on here, as well.

We want people who aren't developers to be able to manage content.

So I quite like the idea of pushing that content management process out of our world completely and starting to use content management as a service.

And then that itself can serve the administration views.

You don't have to worry about that.

It's not coupled to your production environment at all anymore.

And then that can be populating content that your build includes-- build time, so that you can see it while you're developing.

And then [INAUDIBLE] also push to production.

And then you kind of want to go a stage further and think, well, how do I make sure that all of my changes, when I make them, are also deployed without me needing to do too much? So there are tools now that offer deployment as a service, which will monitor your repositories.

And when changes happen to your repositories in the code, it'll go, OK, well, we'll run the build, and then we'll push the resulting static files out to a static host somewhere.

And this is-- another place that this can work is that this can also be monitoring the content.

So it's both monitoring changes that your developers are making to your templates and also changes that content editors are making to the content-- building up your site, packaging it, and spitting it out.

So I guess you could look at this, and kind of squint at me, and say, well, that's not simplifying anything.

There's just as many lines and boxes on that slide as there were on the previous one.

And that's fair.

But I think it's about shifting complexity.

It's about outsourcing complexity and moving it away from the user.

I really like the idea of putting some distance between the user and the complexity.

Where are the points of failure? Where are the chances for things to go wrong? And getting some distance between the user and those points as much as possible.

This kind of model includes sourcing the content at build time rather than execution time.

And as a result, it's more suitable for some things than others.

And we'll touch on that briefly.

But it means that that bottleneck of populating templates-- sourcing content and fulfilling that-- that bottleneck's moved completely away from the user.

So I think it's going to be much more performant.

Things like Jekyll do this quite nicely when they-- I think over a year ago, a couple of years ago now, they introduced their new data model where, in a data directory, if you put any YAML file in there, the structure of that YAML then became available to your templates.

And that kind of abstraction was really nice, because those things were already something that a non-developer could edit, could be managing content in that way.

But I like the idea of going a little bit further.

And so that's why I like this idea of a tool like Contentful.

So Contentful is this content management as a service, if you like.

It offers a hosted CMS interface that you don't have to build, maintain, make sure it's running.

It does it all for you.

And then it exposes the content that lives there on an API for you to consume.

It does things like supporting the translations for you.

So localization is kind of another pain point that's difficult to work through in content management systems.

And it supports that for you and offers localization tools.

And it also does a lot of the kind of boring stuff that you don't want to have to manage yourself, like doing the user roles and all of the different permissions.

It's there and it's available for you to use.

And it offers serving up the content to different environments, different versioning of your API that it exposes, all of these things that are a bit of a faf to have to build and maintain and keep running yourself.

So the critical thing I think this does is it decouples the Content Administration from the production environment.

It's an entire headache that you never need to worry about-- the risk of something going wrong in that environment is completely decoupled from what the user will see when they're visiting your static site.

And so this kind of fills in this little box over here, this content as a service, content management as a service.

And there are lots of integrations for this and tools like it.

I'm using Jekyll as the example quite often, but other static site generators are available.

But there are plug-ins and tools available for things like Jekyll now, which make it very straightforward as the model of sourcing the content from that API and bringing it into your build.

I also really love an aesthetic site generator called Roots.

Has anyone seen Roots before? Anyone? A couple of hands going up.

Roots is great.

I mean, I'm actually at the beginning.

I'm kind of a JavaScript guy.

And so using Jekyll meant that I had to manage a Ruby environment on my machine and those kind of things.

And if it goes well, great.

If it doesn't go well, I don't know how to fix that.

Roots [? does ?] JavaScript through and through, and does a fantastic job of pulling in content from other resources, and offers incredible templating as well that really supports the kind of model we were talking about earlier on of style guides and pattern libraries being generated from the same place.

And a quick note on hosting, or hosting plus, or hosting with benefits.

That last box that was in the diagram there.

There's a fantastic tool that I've been experimenting with recently called Netlify, which started off just as a static host, but then started to do a little bit more.

And that's this box here.

It offers deployment as a service and the hosting all in one.

So this, again, is a chance for us to simplify our environment and reduce the number of tools we use.

It used to be called BitBalloon, and people may have been familiar with this.

It offers kind of a similar deployment experience to search that we mentioned earlier on, which was from the command line.

BitBalloon as it was, and Netlify, you can simply drag your folder on there, and it does magic, optimizes things, put them in a CDN for you, and creates your site.

It's incredibly powerful and very, very simple, but it gets much better when we start putting in things like the commit hooks that are there, and the fact that it can also run your builds.

So an example of that, we see in this video here, you can link it to your repository, and it will give it permission to see your repository.

And then you'll be able to see the projects that exist.

And actually, when you choose it, it actually analyzes the code that's there.

So it can identify what kind of project it might be.

So then it will actually run your build.

So if you've got a Gulp build, or if it's just a static site generator that has a build process of its own, it'll recognize that and start suggesting what's the command to kick that off.

But you can control that, as well.

And then when you run that, it runs through the build process, installs all of the dependencies of the build, and then generates the site and outputs it.

Once it's got to the point that it's done that the first time, it's installed those dependencies, any incremental deployments you do, it just installs the new dependencies.

Or if there's no more, it's just blazing fast.

So deployments are super quick.

This also has a command line interface as well that allows quite a lot more power.

And it's incredibly portable.

It's nicely self-contained.

it's a nice pattern that we're seeing more and more often now of having a single config file in the root of your project that really configures all of that environment for you.

So it's very quick to move from one developer to another and say, OK, check out the environment, run the build, the deployment's all automated.

Really, really nice and straightforward.

And it offers great power through things like web hooks, like notifications.

Gives you control of the headers, so you can control the caching, which is a real bugbear of other static hosts I've found in the past.

Offers things like basic authentication.

So the tools are all starting to come to really produce an environment that you can have a lot of control, and a lot of that control you've allowed to be managed by another tool.

Now of course there are limitations here.

There are lots of limitations on the kind of thing that we can do with this.

Personalisation is a core scenario that we're going to run into trouble.

The idea of having a profile for each person, something that's going to serve content specific to you as an individual user, that's the kind of thing you can't really bake in ahead of time with such ease.

Very, very large sites also potentially are going to start to hit a bit of a ceiling here.

It's something that has hundreds of thousands of pages.

The fact that you might be recompiling and rebuilding all of these templates, these pages, every time you make changes, that might be a bit cumbersome in your development environment.

And user generated content can be something of a struggle.

But there are lots of sites that we work on that these aren't necessarily an issue, although we can push out.

I think it's all about choosing the right tools for the right jobs and finding opportunities to simplify.

Lisa yesterday talked about not every organization even knows why they have a site or how to use it, and finding the best fit is really important.

I'm working in an environment where we're very quick to jump on trends, and we're very quick to look at things that we think are the must have feature.

We use hashtags for everything.

Every campaign has a hashtag.

Chocolate bars have a hashtag on them at the moment, which drives me out of my mind.

But I think the key is that we're sensitive about what we choose and think, well, it depends.

We don't know necessarily we can apply the same rules for everything.

But choosing the right environment for the right kind of project is so key.

So kind of wrapping things up, the points that I want to get across really today are that simplifying the production environment is a huge win.

And any opportunity to do is incredibly valuable.

It's so rewarding to put some distance between your user and the complexity.

It makes you sleep a little bit easier at night when you know that something breaks in one part of the environment, the user isn't going to be affected.

Static site generators and build automation tools are maturing at an incredible rate, and they're really starting to become very rich in the features that they have.

And the powerful hosted tools, these third party tools which solve so many of the problems that otherwise we would have had that would stop us using static sites, these tools are becoming available as well.

My final point is that job interviews at R/GA are very unlike the ones at Swordfish.

I won't mention recruiting again.

Some links to things I've spoken about there are in the slides.

And the slides are online at this URL.

Thanks so much for your time and for staying awake through your hangovers.

Thanks ever so much.

[APPLAUSE] So Pip-- can I call you Pip? You can call me anything you like, Bruce.

Come over the the comfy chair, and you sit there, because Anna told me yesterday that I was sitting in the limelight, and she said I'm hideous and ugly.

Frankly unfair.

So Pippin-- can I call you Pippin? It's getting a little informal, but that's fine.

OK.

So you hate databases.

I don't hate databases.

I really don't.

And people have often said to me, why is it that you just want to avoid ever using a database? And it's not about that for me.

You know, I'm not very good at managing databases.

And they introduce complexity.

And they're very powerful, and they do exactly what we need in lots of cases.

But it shouldn't be our default.

We shouldn't just always think, well, this is the environment we need to do our website and put a database in by default.

I think it's just a very common pattern to just deploy all of the infrastructure that you can think of, because that's what you used on the last thing, or that's the most powerful thing.

But often, it's overkill.

And so I really like to find opportunities to take infrastructure out.

One of the questions was, what happens-- you've made your site using Jeckyll or any of the other things that you've shown, and everything is working really nicely.

And then phase two of the project, the client just comes in and says, oh, didn't I mention we need all this dynamic data going on? How difficult is it to unwind and go dynamic again? Yeah.

Well, I think it's actually not as painful as you might expect.

Because especially if you're building things in a way where you're building modular-- you're building components.

You've modularized your code.

And even though the output is a bunch of static assets, you still have the logic and the structure in the underlying code and assets.

That actually means that it can be quite straightforward.

Or straightforward is oversimplifying it, but it can be a natural progression to then take that and integrate it with something else.

We worked on a project just recently, actually, where we ended up having to integrate into a big Java based content management system.

And actually, the fact that we were going through the process of building it statically first-- and mostly that was for the purposes of having our living style guide-- that actually ended up being a real boon when it came to integrating it later on.

Because although the templating languages were different, we'd already componentized the logic in all of the templates that existed.

And so it was much simpler for the people who were doing that integration to go, ah, this blog does this.

And it was very logical for them to make that translation.

Whereas you can't always assume that it's going to be very easy to change one templating language to another.

Just the fact that we'd already been through the process of marginalizing it actually was a real aid to that.

So build it right, and then it's easy to migrate or much about later.

Exactly.

Yeah.

Excellent.

[INAUDIBLE] So Jerome said, what's the tipping point? How do you know the planning phases of a project? What are the klaxons that go off that say, this is a job for static site generation? Yeah, I think that comes down to, first of all, the size of the site, the number of pages.

But the threshold for that is huge.

The threshold for that is really large.

I mean, we're talking about newspaper type size sites that I think you-- [INAUDIBLE] hang on.

We're not going to build it that way.

But I think more importantly, it's the kind of interactions that exist and the kind of features that you expect in the personalisation that exists.

I mentioned at the end there that it's not very well suited for serving you one piece of content and me another piece.

That, naturally, is going to be something that's going to be much better served by something that has some server logic that's going to get some data from a database.

But if you can find that, actually, there's not personalisation-- I don't have to segment the audience to that degree-- even if there are different types of user, even if you say, well, we might still identify one type of user versus another and serve a few different types of content, that can still be achieved.

And even through to the point of localization.

That all is a perfect kind of marriage at this kind of site, I think.

But for me, the question is, what are the features? How dynamic do the features really have to be? And that's the crux of it all.

And the last question is, I'm kind of faced with a paradox of choice here.

Because there seem to be a last count, and it's gone up since you started doing the talk.

About 744 different ones.

How do I choose which one? So the way I choose is a personal thing about the language I like to develop in.

I like being able to use a stack that's familiar to me.

I like to look at tools and think about how mature they are and how well supported they are.

Lots of these tools that exist are-- that long 400 or so list, a lot of those are pet projects.

So I think finding one that's got a community around it and is being proven to-- is still being developed, still evolving.

That's key.

And looking at things like, how well are the features documented? And what kind of features exist? I've started down tinkering with one of these tools before and then discovered that, oh, I can't use the kind of templating engine that I prefer.

And so that can be a factor, as well.

So the kind of features they have, how well supported they are, and just personal taste in how you like to develop.

I think those are all important factors.

So the usual open source, choosy way of, do people talk about this? Do pull requests ever get accepted? Yeah, exactly.

Is the author traceable? Et cetera.

Yeah.

I mentioned Roots earlier on.

And that actually is a fairly small community at the moment that's on that.

However, it was built by an agency that uses it internally.

And the contributors to that are just incredibly prolific and really engaged with the community as it grows.

And the amount of support I've seen for the questions that come out has been really impressive.

And even though it doesn't have a massive community yet, I think they've been using it internally for a couple of versions.

This is version 3.0, I think,

that's out at the moment.

And so it's matured quite well.

Before they've said, oh actually, this is something that's useful for the wider audience.

So it's showing that kind of maturity and engagement with the community.

There's a classic open source win-win, isn't it? People use it internally, so you know they care, and they're likely to continue developing it.

Right.

And they get new features, because they've open sourced it.

Exactly.

So other people are doing the work.

Yep.

Yep.

[INAUDIBLE].

Thanks very much, Phil.

Ladies and gentleman, Pippity Poo Hawksworth.

Thank you.