I've written my ninth (?) blog post for GDS, titled How we retired a web application to make GOV.UK simpler to run.
It's a technical subject written for a non-technical audience, so hopefully it should make sense whatever your background.
Writing and publishing
It's been nearly four years since I last wrote an article for any of the GDS blogs. I think the gap was partly because I didn't have a good subject and partly because of the complexity of the process. Fortunately, this time the process was quite smooth - one editor helped refine the article, there were a few layers of approval (no changes) and then a fairly quick publish. I think I started writing the article in January, so that's not a bad turnaround for us.
I'm pleased to have got it out and done and the work it talks about is something I'm very happy about. That said, I'm slightly disappointed that the article couldn't go into more technical detail, but that would have made it too long and unappealing to a lot of people.
The passage of time
Static's story is an interesting one. It was created for a specific purpose and it did that very well, but as the years passed our technology and approaches improved, and it slowly changed from an essential part of our infrastructure to something slightly redundant, to eventually a hindrance.
One of the biggest changes was the introduction of govuk_publishing_components (our components gem) in 2017, which took responsibility for a big chunk of Static's work. It also did it in a much more lightweight and easier to maintain way, improving our developer experience significantly, and allowing us to have a proper component guide for the first time. I'm proud to have been a part of the team that built it.
You can see that component guide here. It's not really designed for anyone but developers on GOV.UK - there's no fancy navigation, introduction or categorisation of the components - but it works for us and we can run it locally very easily. It was also the first time we'd been able to see and develop our components and all their variations together in one place in isolation. Before that, making a change to a component would have meant checking it across GOV.UK before deployment, which was time consuming and frustrating. We've worked hard since then to preserve this approach.
The developer experience
One of the hardest aspects of working with Static from my perspective was making it run locally. This happened quite a lot, particularly during specific projects.
An example of this was when working on changes to our analytics code, which ran on every GOV.UK page. The code was held in the components gem, loaded uniquely by Static, but then run in a page generated by an application. That meant to test changes we had to run a local Static with a local application, both of them pointed at a local copy of the components gem.
We had docker set up to do this, but the multiple layers of caching that a change had to get through often meant that what I'd just written wouldn't appear in the browser. Sometimes that could be fixed with a hard refresh, or a more complex solution was required. Far too often I would have to completely delete my docker setup and rebuild the whole thing from scratch, which on my laptop could take ten or twenty minutes or even longer. That's a huge investment of time and frustration for making what would often be a very small change.
Static's legacy
Static also caused an over-complexity in our CSS. Most of our Sass is held in our components gem, but applications imported various bits of it (mostly Sass for specific components). We also had a model of loading per page component CSS files, to improve caching and reduce page weight - basically to only load the CSS we need on each page.
What that all meant was we had to structure our Sass so that Static could import some of it and applications could import other bits of it, but when it was all brought together (as a single page on GOV.UK featuring one application CSS and one CSS from Static) there was as little duplication as possible. We had it working, but it was complex.
Removing Static highlighted some problems in our Sass compilation, to do with precedence and order of styles. Suddenly little problems started appearing around the site - elements with incorrect margins, or (more worryingly) incorrect text colours. This eventually led to us removing our per page component CSS model, which was sad (a lot of work had gone into it) but we were able to show data to prove that this was the right decision.
All of this was hugely complicated, but now that Static's gone we've started to restructure our Sass. This was another big challenge, but the result is a far cleaner and more understandable Sass structure.
Final thoughts
One of the main reasons for writing an article about removing Static was to encourage other developers working with something similar. We've all been there - that essential bit of the system that's just not quite right, but the cost of fixing or replacing it is simply too much, or not high profile enough to convince the organisation of the value of the work.
There is hope - it is possible. You'll need to convince people, and show them the benefits, and maybe do some of it in small chunks in the background, but eventually, with enough time and work, you can do it - just like we did. It took two RFCs, multiple developers, years of work - but we got it done in the end.
There's a lot more that could be said about what Static did and what was involved in removing it, but those are stories for another time.