Building Services to GDS Standards Without a Frontend Framework

Introduction

Here’s a question for you: do you need to use a frontend framework to build a modern UK government service?

As readers of my blog will know, I’m a massive fan of the ⁠GOV.UK Design System and the team who work on and maintain it. Having worked with the team for several years, it’s fantastic to see people so dedicated to their craft and who understand the gigantic impact their work has on inclusive design across government.

At the heart of the Design System is ⁠GOV.UK Frontend, the component library used by services across Government Digital Service (GDS) and other government departments.

As you’ll see in the ⁠release notes for the latest version (v6.5.1 at the time of writing), the installation instructions specifically mention:

npm install govuk-frontend@6.5.1

A developer looking at GOV.UK Frontend for the first time could therefore reasonably assume that using the Design System means using only Node.js, npm, Nunjucks, and JavaScript.

And to be fair, that is often the easiest way to get started. But none of those technologies need to define the architecture of the service itself.

GOV.UK Frontend ultimately runs in the browser. The browser doesn’t care at all whether the HTML it receives was generated by Node.js, .NET, PHP, Ruby, Python, or something else entirely. What matters is that the service generates the correct HTML, CSS, and JavaScript, and does so consistently.

That leaves teams with much more freedom to choose a backend technology that suits their developers, their existing skills, their organisation, and the service they are building. Developer preference can absolutely be part of that decision. GOV.UK Frontend itself shouldn’t be the thing that makes the decision for them.

So, rather than just saying that this ought to be possible, I wanted to show you how well it works in practice.

The Experiment

So what exactly will I be building in the experiment?

1. Implement all GOV.UK Frontend components and fixture variations across each of the eight chosen backend languages, with automated tests to ensure 100% HTML parity.
2. Write a fake end-to-end service to apply for a licence for a fishing rod. Note: This is based on a real service: Buy a rod fishing licence.

FYI: You don’t actually need a licence to own a fishing rod in the UK, only to fish with one! My fake service deliberately gets this wrong and suggests you require a licence simply to own a fishing rod, which would be completely ridiculous!

This odd service choice is intentional. The last thing I want is someone stumbling across one of these demos and mistaking it for a real government service. I’ve added plenty of anti-SEO measures to prevent that happening, but when it comes to accidentally inventing government policy about owning a fishing rod, it’s probably best to err on the side of caution!

With that important disclaimer out of the way, I shall use the same fake service to build eight identical implementations, each using a different backend technology. Every implementation will generate real GOV.UK Frontend components. The eight backend technologies are:

• TypeScript + Node.js
• PHP
• Java
• .NET
• Ruby
• Python
• Go
• Rust

Yes, that’s 8 separate versions of the same frontend and component setup.

There is one important rule for all of these implementations: the HTML they generate must match the output from GOV.UK Frontend with 100% parity. Looking the same in the browser isn’t enough. The underlying HTML needs to be identical.

Thankfully, GOV.UK Frontend gives us a very useful way to verify this. With every release, the team provides ⁠HTML test fixtures that describe the expected HTML output for each of its components.

This significantly simplifies the experiment. So, rather than manually comparing components via the HTML source, or relying on visual testing, we can automate the process using whatever testing tools are available for each backend language. Give each implementation the same component data, render the component, and compare the resulting HTML against the official GOV.UK Frontend fixture.

If they match, we have parity!

What does “GDS-compliant” actually mean?

Before going any further, it’s probably worth explaining what I mean by “GDS-compliant”, particularly for readers who aren’t familiar with building UK government services.

Importantly, “GDS-compliant” is just a convenient shorthand I’m using throughout this post. It isn’t an official technical certification, nor does following a particular technology stack automatically make a service compliant.

For the purposes of this experiment, each implementation has been built around the principles, standards, and guidance that UK government services are expected to follow, including:

• the GOV.UK Service Standard
• the GOV.UK Design System
• GOV.UK Frontend
• meeting WCAG 2.2 AA requirements
• using Progressive enhancement
• considering Accessibility, resilience, performance, and maintainability.

There is something else worth pointing out here: The use of any particular JavaScript framework is not one of those requirements.

There is no requirement for a service to use React, Angular, Vue, Svelte, or indeed any other frontend framework to use the GOV.UK Design System or follow the Service Standard.

These are architectural choices that should be driven first and foremost by user needs, followed by the specific requirements of the service, its technical constraints, and the team responsible for building and maintaining it. They are not prerequisites for building a UK government service.

GOV.UK Frontend is not your application architecture

It’s essential to understand that GOV.UK Frontend does not define your application architecture. It simply provides components, styles, JavaScript behaviours, and conventions for building UK government services. It does not dictate how your application generates them.

GOV.UK Frontend uses Nunjucks templates to generate component HTML from configuration data, but you do not need to use Nunjucks yourself. Ultimately, the browser receives HTML, CSS, and JavaScript. Your backend can therefore use whatever templating system is appropriate for its language, provided it produces the same HTML and behaviour expected by GOV.UK Frontend.

The same applies to node package manager (npm). GOV.UK Frontend provides npm installation instructions, but that does not mean your application needs to be written in Node.js or JavaScript. The actual implementation technology is less important than the output it produces.

This is where the component test fixtures supplied with GOV.UK Frontend become particularly useful. When written correctly, tests can automatically render components using your chosen backend and compare the resulting HTML against the expected output for each fixture. So rather than manually checking whether your implementation still matches GOV.UK Frontend, these automated tests allow developers to continuously check for 100% HTML parity with complete confidence in a matter of minutes.

These fixtures also makes upgrades much easier. A developer can update to a new version of GOV.UK Frontend, run the fixture tests, and any differences are immediately visible. Instead of painstakingly comparing component implementations between releases, the test suite identifies exactly where your output has diverged.

That workflow is not tied to a particular backend language. Whether the application is written in Go, Java, PHP, Python, Ruby, Rust, or TypeScript, the principle remains the same: generate the HTML from the backend, test it against the GOV.UK Frontend fixtures, ensure they all pass, and continue to keep those tests “green” as GOV.UK Frontend evolves.

This allows developers to focus on building the service, with automated evidence that their component output continues to match what GOV.UK Frontend delivers.

The HTML is the contract

Essentially, what I’m trying to say is that the HTML that GOV.UK Frontend generates is the contract you should stick to, regardless of what backend you choose to build with.

A simple test fixture

Here’s an elementary example of how to use a test fixture:

Given this test JSON:

{
  "name": "default",
  "options": {
    "text": "Save and continue"
  },
  "html": "<button type=\"submit\" class=\"govuk-button\" data-module=\"govuk-button\">\n  Save and continue\n</button>"
}

And given some pseudocode for rendering HTML:

renderButton({
  text: "Save and continue"
})

And the resulting HTML is:

<button type="submit" class="govuk-button" data-module="govuk-button">
  Save and continue
</button>

The testing process then boils down to:

1. Load the button test fixture from GOV.UK Frontend.
2. Render the button HTML from whatever backend is chosen.
3. Test if the rendered HTML equals what is described in the test fixture.
4. Assuming they both match, the test passes, if not the test fails, and the component needs updating in the backend.

This gives developers something objective to test against. Rather than manually recreating components and hoping they remain compatible.

Repeating this process across Design System components automatically verifies that your backend produces the HTML expected by GOV.UK Frontend, ensuring its CSS, JavaScript, and images work as intended, provided they are implemented correctly.

As GOV.UK Frontend evolves, the fixtures evolve with it, covering new components as well as changes to existing ones. This makes future upgrades far simpler: update GOV.UK Frontend, run the tests, and immediately see where your implementation has diverged. It removes much of the manual effort and cognitive load from keeping components up to date.

One frontend to rule them all

Yes, this is a not particularly subtle nod to J. R. R. Tolkien’s The Lord of the Rings. Hopefully, though, what follows involves considerably less corruption, fewer Orcs, and no lengthy walks to Mordor!

While working at the GDS, I had a rather idealistic view of what the GOV.UK Design System could eventually become. I’m not sure everyone around me shared quite the same vision (especially at a senior level), but I still think its position within government gives it a unique opportunity.

For those unfamiliar with GDS, it sits at the centre of UK government and produces standards, guidance, and common technology that can be used across departments. Well, that's the theory, at least!

This makes the GOV.UK Design System particularly well-placed to become more than simply a library of reusable components.

The idea I always found appealing was the feedback loop that widespread adoption across government could create:

1. A department builds services using GOV.UK Frontend.
2. Those components are tested with that department’s particular set of users, across real services and real user journeys.
3. Service teams learn what works, what doesn’t, and where components or patterns could be improved.
4. Those findings can be fed back to the GOV.UK Design System team, thus helping the existing components evolve and be refined and improved over time.
5. Departments can also develop new components and patterns to meet needs that are not yet covered. Because the Design System is open source and available for all to see on GitHub, these can potentially be contributed back into the Design System for other departments to benefit from.

Now repeat that process across dozens of departments, hundreds of services, thousands of developers, designers, researchers, and accessibility specialists, and, most importantly, millions of users.

That is where the idea becomes fascinating.

A common frontend does not mean every government service has to use the same technology behind it. Different departments and service teams can make different backend choices without having to invent different frontend implementations. One service might use Java, another Go, another PHP, and another Ruby, but they can all present the same GOV.UK components to users.

Backend architecture and frontend presentation do not have to be coupled. As long as a backend can produce the correct HTML, CSS, and JavaScript required by GOV.UK Frontend, the technology generating it becomes largely irrelevant to the user. Their browser neither knows nor cares whether that HTML came from Go, Java, PHP, Ruby, or any other backend language.

That separation is what makes the idea particularly powerful at government scale.

The more widely GOV.UK Frontend is adopted, the greater the opportunity to learn from how its components perform in the real world. Those lessons can feed back into the Design System, which can then evolve and improve for the next service that uses it. That service generates more evidence, which feeds back into the Design System again.

Over time, you end up with something that no individual department could realistically build on its own: a common frontend shaped by the collective experience of services across government and the people who actually use them.

Instead of every department independently solving the same frontend problems, they can make the backend technology choices that suit their service while contributing to and benefiting from a shared frontend foundation. Improvements made because of users of one service can eventually benefit users of many others.

Perhaps that sounds a little idealistic. Thankfully, there are some fantastic examples of this feedback loop happening already on the GOV.UK Design System team’s GitHub project backlog:

1. Error messages: add guidance on how to write good ones from March 2018
2. Navigation — we want your input (examples, research, code) from October 2022
3. Multi File Upload from May 2024
4. Feedback component started in January 2018, released in v6.5.0 (August 2026)

With departments and service teams sharing research, proposing new components and patterns, and contributing improvements based on real user needs, this kind of collaboration is already happening. Individual teams solve real user problems, other departments learn from those solutions, improve upon them, and potentially contribute that knowledge back into the shared Design System for everyone to benefit from.

Looking at the dates on the backlog, you can see that this willingness to collaborate across government for the greater good has been there for years.

So perhaps the idea is not quite as idealistic as it first sounds. If we are going to have one frontend to rule them all, I can certainly think of worse ways to build it!

The rules of the experiment

So what exactly should the experiment achieve? Well, there needs to be a solid set of criteria that each build should meet to make a fair comparison. So I’m going to define some rules.

Every implementation must:

• Render GOV.UK Frontend components on the server side.
• Produce HTML that exactly matches the GOV.UK Frontend fixture HTML.
• Use the same version of GOV.UK Frontend. It simply wouldn’t be a fair test otherwise, as components and assets often change between versions. The version being used is ⁠v6.5.1, the latest release at the time of development.
• Work without JavaScript for all core journeys.
• Progressively enhance only where JavaScript adds value.
• Meet WCAG 2.2 AA requirements.
• Follow GOV.UK conventions and patterns, for example, the Service Manual and Service Standard.
• Use broadly equivalent pages and functionality, although I’m aiming for identical user-facing content and behaviour where possible.
• Serve equivalent HTML, CSS, JavaScript, and assets to the browser, regardless of the backend implementation.
• Have comprehensive automated tests, including tests for component fixture parity, integration, accessibility, and end-to-end behaviour where appropriate.
• Aim for 100% test coverage across lines, ⁠statements, ⁠branches, and ⁠functions, accounting for differences in the coverage tooling available for each language.
• Keep language-specific abstractions away from the UI code. The component-facing interface should remain consistent regardless of whether the backend is written in Go, Java, PHP, Python, Ruby, Rust, or TypeScript.

By setting these rules upfront, it becomes easier to implement the same thing consistently across different languages. They also make any comparisons between the implementations fairer and more credible, as we have a common benchmark to work from.

Eight backends, one GOV.UK Frontend

Now that we’ve got the implementation rules covered, it’s time to look at actual implementation (the fun part!)

TypeScript and Node.js

What are TypeScript and Node.js?

⁠TypeScript builds on JavaScript by adding static typing, while Node.js provides the runtime environment needed to execute JavaScript outside the browser, including on the server. TypeScript is compiled into JavaScript before being executed.

Together, they provide a relatively straightforward way of building server-rendered web applications while remaining within the JavaScript ecosystem which is used by GOV.UK Frontend.

How mature are TypeScript and Node.js?

TypeScript and Node.js are both mature and widely used technologies. Node.js was first released in 2009, while TypeScript followed in 2012.

Due to their widespread use they also come with a large ecosystem of libraries, tooling, documentation, and community support available when building server-rendered web applications.

In terms of popularity the following StackOverflow surveys reported:

2022

• Node.js most popular Web framework with 47.12%.
• TypeScript 4th most loved with 73.46%.

2025

• Node.js most popular Web framework with 48.7%.
• TypeScript 6th most popular language with 43.6%.

Using TypeScript and Node.js with GOV.UK Frontend

I’m considering this first implementation the baseline. There are numerous reasons for this:

• GOV.UK Frontend is distributed as a npm package, so there is already a very close relationship with how it is expected to be used. The release notes, for example, tell you to npm install govuk-frontend@6.5.1.
• GOV.UK Frontend’s component macros are written in Nunjucks, so using Node.js, Express, and Nunjucks gives us probably the easiest path between the reference implementation and a working example service.
• When used with ⁠Express, the setup is simple. Adding Nunjucks is just as straightforward, just a single command: npm install nunjucks.
• There is very little translation required between the ⁠GOV.UK Design System documentation and the application itself. Component examples and options can largely be used as documented.
• The npm package also gives us direct access to GOV.UK Frontend’s Sass, JavaScript, fonts, and other assets without requiring a language-specific port or alternative implementation.
• Most importantly for this experiment, it gives us a useful baseline. If implementations written in entirely different backend languages can produce the same component fixture HTML as GOV.UK Frontend, we then have a common benchmark which they can be compared against.

None of this means I consider TypeScript and Node.js to be the “best” backend choice. They simply provide the most straightforward starting point for an experiment centred around GOV.UK Frontend.

It is also worth making an important distinction here. Express, Nunjucks, and GOV.UK Frontend do not require a client-side frontend framework such as ⁠React, ⁠Angular, ⁠Vue, or ⁠Svelte. Express handles the HTTP requests, Nunjucks renders the templates, and GOV.UK Frontend provides the components, styles, and JavaScript for progressive enhancement where required.

Ultimately, what arrives in the browser is still HTML, CSS, and JavaScript. Exactly what every fast and inclusive government service needs!

Note: If I were building a larger production service using TypeScript, I would certainly consider ⁠NestJS rather than using Express directly. Its opinionated structure, modules, dependency injection, controllers, and testing support are likely to make larger TypeScript applications considerably easier to structure and maintain. For this example, however, Express keeps things simple and makes it easier to see exactly what is happening.

Advantages and disadvantages of TypeScript and Node.js for GOV.UK services

As this implementation provides the baseline for the experiment, these advantages, and disadvantages describe the TypeScript and Node.js approach itself. The other backend implementations shall then be compared against it.

Advantages

• Direct access to the GOV.UK Frontend npm package
• Native use of GOV.UK Frontend’s Nunjucks macros
• Very little translation from Design System examples
• Direct access to Sass, JavaScript, fonts, and assets
• Large Node.js and TypeScript ecosystem
• Straightforward GOV.UK Frontend upgrades via npm install govuk-frontend@latest

Disadvantages

• Requires Node.js in production
• Larger dependency tree than some alternatives
• npm dependency management requires ongoing maintenance
• Express provides relatively little application structure by itself
• Larger services would benefit from an additional framework such as NestJS

TypeScript and Node.js GOV.UK Frontend example

Here you will find links to the demo and associated resources:

• GitHub repository
• Example service^† and components^†
• AI-specific context: govuk-frontend-typescript.mdc

^† These demos are hosted on Render's free tier, so the first request after a period of inactivity may take around 50 seconds while the service starts up.

Go

What is Go?

I don’t think you could get a much simpler name for a backend programming language than ⁠Go. As its homepage says, it’s an open-source programming language supported by Google. It is designed to be easy to learn and work well across teams, with built-in concurrency, a robust standard library, and a large ecosystem of tools, communities, and partners.

How mature is Go?

Go was first released by Google in late 2009, although it wasn’t until 2012 that version 1.0 was released. I find it’s always frightening to think that 2009 was actually 17 years ago! So, despite sometimes feeling like a relatively modern choice, Go is ultimately a pretty mature language.

Its popularity with developers has also grown, over the past few years:

• 2022: Go was used by 11.15% of all respondents.
• 2025: Go was used by 16.4% of all respondents, demonstrating an increase in popularity since 2022.

Using Go with GOV.UK Frontend

Go’s standard library includes its own built-in HTML templating package, ⁠html/template. This means you can generate server-rendered HTML without introducing a third-party templating dependency.

That makes it particularly interesting for this experiment. GOV.UK Frontend does not require a particular backend or templating language, so Go can render the same GOV.UK components on the server while keeping the backend dependency footprint relatively small.

Advantages and disadvantages of Go for GOV.UK services

Compared with the TypeScript and Node.js baseline for server-rendered government services, Go has some clear advantages, but also introduces some additional work.

Advantages

• Fast and lightweight
• Small dependency footprint
• Simple deployment
• Strong typing
• Excellent standard library
• Secure HTML escaping by default

Disadvantages

• No official GOV.UK Go templates
• Ongoing component parity requires maintenance
• Less expressive templating
• Much smaller GOV.UK ecosystem
• GOV.UK Frontend still requires Node tooling
• More work when GOV.UK components change

Go GOV.UK Frontend example

Here you will find links to the demo and associated resources:

• GitHub Repository.
• Example Service^† and components^†.
• AI-specific context: govuk-frontend-go.mdc

^† These demos are hosted on Render's free tier, so the first request after a period of inactivity may take around 50 seconds while the service starts up.

Java

What is Java?

I have to admit, when I think of Java, I always think of those horrendous Java Applets that were all over the web in the mid-90’s. Again showing my age… But from what I hear from colleagues at work it’s a very popular and widespread backend language used across vast swathes of the internet.

Java was created at Sun Microsystems way back in 1991 by James Gosling and a small team, originally under the name Oak. It was designed to be portable across different types of hardware, leading to the principle “write once, run anywhere” through the Java Virtual Machine (JVM). It was later renamed Java, and was publicly released in 1995, just as the web was rapidly growing.

Java has since become one of the dominant languages for enterprise and server-side development, particularly through technologies such as Java Platform Enterprise Edition (Java EE) and frameworks such as Spring. Oracle acquired Sun Microsystems in 2010 and has stewarded Java since. Today, Java remains widely used for large-scale backend systems, enterprise applications, financial services, and government services, with regular releases continuing to modernise the language and JVM.

How mature is Java?

If you read the above paragraphs I’m not sure if I really need to answer this. As my dad would say, Java is older than Gods dog! Having been created in 1991 by Sun Microsystems under the name Oak, it was later renamed Java and was released in 1995, hence all the Java Applets! So to directly answer the question, Java is very mature!

If we go back to our trusty old StackOverflow Surveys:

• 2022: Java is 6th most popular language with 33.27% of all respondents saying they use it.
• 2025: Java is 7th most popular language with 29.4% of all respondents saying they use it.

Using Java with GOV.UK Frontend

Using Java with GOV.UK Frontend is relatively straightforward to get running, particularly for teams already familiar with Spring. The example I created uses Java 25, Spring Boot 4.1, Spring MVC, and Thymeleaf to produce server-rendered pages. GOV.UK components are rendered using native Java implementations based on the official template.njk macros, with their output checked against GOV.UK Frontend’s HTML fixtures. GOV.UK Frontend itself still provides the Sass, CSS, JavaScript, fonts, and other assets, with JavaScript used only to progressively enhance the server-rendered HTML.

The greater challenge is keeping the Java implementation aligned with GOV.UK Frontend over time. Node.js is still used to install GOV.UK Frontend, compile its Sass, and access the official test fixtures, but it plays no part in rendering pages. Because the component templates are effectively being reimplemented in Java, each GOV.UK Frontend upgrade can introduce changes to the expected HTML. Those changes need to be reflected in the Java renderers and verified against the official fixtures to ensure the implementation remains compatible.

Advantages and disadvantages of Java for GOV.UK services

Advantages

• Java is already common and used in many UK government departments, with long-term support releases, a large hiring pool, and mature operations particularly around Spring Boot.
• Server-rendered HTML fits perfectly with GOV.UK Frontend. Spring MVC and Thymeleaf can send a complete page on the initial response, and the official GOV.UK Frontend JavaScript only enhances it.
• The type system, tests, and build tooling make form handling, validation, and security headers easier to keep consistent, precisely what government services use to collect user data.
• A service can use GOV.UK Frontend’s CSS and JavaScript without running Node on each request. The linked repository below outputs HTML using Java renderers which have been checked against the official component fixtures.

Disadvantages

• GOV.UK Frontend is published using Nunjucks Macros. There is no official Java port, so component HTML has to be reimplemented and rechecked with every Frontend release.
• The HTML parity work is the expensive part for service teams. Even a small template change upstream can mean a Java change and a full fixture run, but as is shown in the repository, the test fixtures help massively when automated with fixture testing.
• The stack is heavier than the Node stack: it requires a Java Virtual Machine (JVM), Maven, and a separate Sass build just to compile GOV.UK Frontend’s CSS.
• Pages and components are split between Thymeleaf templates and handwritten Java renderers. This creates a significant barrier for designers and frontend developers, as changing the HTML is less straightforward than with template languages such as Nunjucks.
• Java, Spring Boot, and coverage tools all have their own upgrade cycles, in addition to GOV.UK Frontend. Keeping everything up to date can therefore become a lengthy process and create a significant maintenance overhead, particularly for smaller teams.

Java GOV.UK Frontend example

Here you will find links to the demo and associated resources:

• GitHub Repository
• Example Service^† and components^†
• AI-specific context: govuk-frontend-java.mdc

^† These demos are hosted on Render's free tier, so the first request after a period of inactivity may take around 50 seconds while the service starts up.

C# and .NET

What is C# and .NET?

Another memory I have when it comes to .NET is the magazine, I assume they are in no way related, but I do think of it every time someone mentions it! Looking closer at their website it may be a UK-only magazine, so not at all related!

C# and .NET were developed by Microsoft in the late 1990s as part of its push to create a modern platform for building applications. C#, led by Anders Hejlsberg, was first released in 2000, with .NET Framework 1.0 following in 2002. C# combined ideas from languages such as C++, Java, and Delphi, while .NET provided the runtime, libraries, and tooling needed to build and run applications.

Originally focused heavily on Windows, the ecosystem changed significantly when Microsoft introduced the open-source, cross-platform .NET Core in 2016. From .NET 5 in 2020, Microsoft unified the platform under the “.NET” name. Modern C# and .NET are now open source and cross-platform, supporting Windows, Linux, and macOS, and are widely used for web APIs, cloud services, enterprise applications, desktop software, and increasingly cloud-native workloads.

How mature is C# and .NET?

Yet another section that really doesn’t need to be answered because of the section above but I will anyway for completeness. C# and .NET are mature, well-established technologies with over 25 years of development, now open source, cross-platform, and actively maintained by Microsoft.

Using C# and .NET with GOV.UK Frontend

Using C# and .NET with GOV.UK Frontend is straightforward if you are already familiar with ASP.NET Core. Pages are built using standard Razor Pages, while each GOV.UK component is implemented as a C# renderer using options that closely follow the equivalent Design System macro. The server returns complete HTML, so there is no need for Nunjucks, Blazor, or a client-side framework to render the interface.

The implementation in the example repository given below uses .NET 10 and ASP.NET Core Razor Pages for the application and user journey, with C# renderers producing the govuk-* component markup. These renderers are kept aligned with GOV.UK Frontend’s Nunjucks templates and checked against its official GOV.UK Frontend HTML test fixtures. GOV.UK Frontend still provides the CSS, fonts, assets, and JavaScript used for progressive enhancement. Node is only needed to install GOV.UK Frontend, compile the Sass, and validate the fixtures. It plays no part in rendering the response.

It is worth noting that Sass compilation remains part of the Node-based build pipeline rather than .NET. While this could be integrated more closely with the .NET build, doing so adds complexity for little benefit. Node and npm are already used to install GOV.UK Frontend, compile its Sass, process its assets, and verify the C# renderers against the official Nunjucks fixtures. For that reason, I have deliberately kept these build-time tasks in Node in the example repositories and demos, while .NET remains responsible for rendering and serving the application.

Advantages and disadvantages of C# and .NET for GOV.UK services

Advantages

• Server-rendered ASP.NET Core fits GOV.UK services well. Razor Pages produce the whole form journey in the initial response, and GOV.UK Frontend JavaScript only enhances it where required. Furthermore, there is no client-side UI framework to load, secure, or keep accessible.
• The HTML contract is checkable. C# renderers are compared with every official GOV.UK Frontend HTML fixture release. This ensures a GOV.UK Frontend upgrade fails the build when the markup drifts. Plain text is encoded by default, and trusted HTML is a separate type.
• The .NET platform already covers the rest of a government service functionality by default e.g. forms, validation, sessions, authentication, compression, and security headers. .NET 10 is a supported long-term release with nullable types, analysers, and a coverage gate.

Disadvantages

• As mention earlier in the post, GOV.UK Frontend is published as Nunjucks, Sass, and a npm package. The repository I have created keeps a parallel C# renderer for every component, and that renderer has to be updated on each new Frontend release. Since there is no official GDS version of GOV.UK Frontend in .NET, any team wanting to adopt it would need to factor this required work into their ongoing maintenance plans.
• Node stays in the toolchain. It installs govuk-frontend, compiles Sass, copies fonts and JavaScript, and checks that fixtures are still updated. Although the running site does not call Node, developers still need to support both stacks.
• Government designers typically prototype services using Nunjucks in the ⁠GOV.UK Prototype Kit, so their code cannot be reused directly in Razor and must be translated into the equivalent C# component API.
• Using .NET and the GOV.UK Design System does not automatically make a service assessment-ready. User research, assisted digital support, accessibility audits, and operational evidence still sit outside the application, but following established GOV.UK frontend patterns provides a strong technical foundation to take into a Service assessment.

C# and .NET GOV.UK Frontend example

Here you will find links to the demo and associated resources:

• GitHub Repository
• Example Service^† and components^†
• AI-specific context: govuk-frontend-dotnet.mdc

^† These demos are hosted on Render's free tier, so the first request after a period of inactivity may take around 50 seconds while the service starts up.

Python

What is Python?

I must admit, I know very little about Python, apart from: it is relatively easy to learn and a great language to start your programming journey with. It is also hugely popular with data scientists, thanks to its excellent machine learning support, including PyTorch and TensorFlow, and visualisation libraries such as Matplotlib and Plotly.

Python was created by Guido van Rossum in the late 1980s and first released in 1991. It was designed to be easy to read, simple to learn, and productive to work with, favouring clear, concise code over unnecessary complexity. Its name was inspired by Monty Python, rather than the snake. 🐍

Since then, Python has grown into one of the world’s most widely used programming languages. Python 2 arrived in 2000, followed by the deliberately cleaner but initially incompatible Python 3 in 2008. Today, Python is a mature, open-source language used extensively for web development, automation, scientific computing, data science, AI, and machine learning, supported by a vast ecosystem of libraries including the ones I mentioned in the first paragraph above.

How mature is Python?

Python was developed in the late 1980s and first released in 1991. There was then quite a wait for Python 2, which arrived nine years later in 2000, followed by Python 3 in 2008, which remains the current major version today. So, considering its initial release coincided with the early development of the World Wide Web, it’s safe to say Python is pretty mature!

Using Python with GOV.UK Frontend

Using Python with GOV.UK Frontend is straightforward, particularly if you already know Django. Pages are rendered server-side using Django views, forms, and templates, with native Python components and {% govuk %} template tags generating the GOV.UK Frontend HTML. As with other languages, GOV.UK Frontend provides the Sass-compiled CSS and official JavaScript for progressive enhancement, with no Node.js required at request time. There is no need for React, Vue, or any other client-side frontend framework to render anything in the browser.

If you’ve read this post from the start, you will see this is becoming quite a common theme: the more difficult part is keeping the Python component layer in sync with GOV.UK Frontend. As already mentioned, GOV.UK Frontend is distributed as a Node.js package and its components are implemented using Nunjucks macros. These need to be completely reimplemented in Python and checked against the official GOV.UK Frontend fixtures to ensure the generated HTML remains identical. In practice, building every day Django pages is simple; maintaining compatibility with GOV.UK Frontend as it evolves is where most of the additional work lies. So if a service team nails down this particular workflow, Python looks like a very reasonable language to use as its backend.

Advantages and disadvantages of Python for GOV.UK services

Advantages

• Django is built for server-rendered pages by default: forms, sessions, and Cross-Site Request forgery (CSRF), which matches GOV.UK’s progressive-enhancement model (HTML first, minimal Frontend JS as enhancement, only when required).
• You can ship a "GOV.UK service UI" without the need for React, Vue, or any other client-side library. Pages use standard HTTP requests and responses, so accessibility and “works without JavaScript” are easier to verify.
• Python is already common in many government departments for APIs, data, and services (e.g. GOV.UK Notify). One language can cover the service and the HTML if you accept a native Frontend wrapper.
• Django views, forms, validation, and the test client line up well with question pages, error summary, and retaining values on error.
• Component HTML can be rendered in Python and compared to official govuk-frontend fixtures without a browser. The repository I’ve shared below treats that parity as the contract.

Disadvantages

• GOV.UK Frontend ships as a Node package with Nunjucks macros. Python has to reimplement template.njk (the repo in my example uses govuk_components.rendering), so you don’t get the macro support “for free”.
• The Node stack is still required for GOV.UK Frontend install, Sass, fixtures, and upgrade checks. Production HTML is Python; the design system’s source of truth is still using Nunjucks.
• Every Frontend release can change markup. The Python renderer and fixture suite must be updated, and there is no official GDS Python renderer to lean on, so this is a manual task, although test automation against the HTML fixtures provides help with this.
• Most GOV.UK Frontend examples and documentation are written for Nunjucks and Node, so when using Django you have to translate these into Django template tags rather than using them directly.
• A Python Platform as a Service (PaaS) environment may not include Node.js, which is still needed to compile GOV.UK Frontend’s Sass. For the example I’ve used Docker, so Node.js can build the styles and Gunicorn can run the Django application within the same image.

Python GOV.UK Frontend example

Here you will find links to the demo and associated resources:

• GitHub Repository
• Example Service^† and components^†
• AI-specific context: govuk-frontend-python.mdc

^† These demos are hosted on Render's free tier, so the first request after a period of inactivity may take around 50 seconds while the service starts up.

PHP

What is PHP?

When I think of PHP my first thought is WordPress, as I remember cranking out custom WordPress themes when I first got started in Web Development, all those many years ago!

Although it’s challenging to remember now (probably because I’m old), I’d say PHP + MySQL were my first foray into backend development as a frontend developer.

Looking at the stats from the 2025 Web Almanac, I think there were most likely plenty of developers who did the same given how insanely dominant Wordpress’s use as a CMS is in the research. With a whopping 64.3% usage on the web out of all the sites surveyed! It even has its own entire section in the CMS chapter.

How mature is PHP?

Although I’ve used PHP a fair amount over the years, I’ve never really stopped to look into its history. I have heard a rumour related to PHP, although I have absolutely no idea if it is true:

In the early days of its development (1994), Rasmus Lerdorf asked people using it to send him postcards. Partly to convince his girlfriend that all the time he was spending on it was actually having an impact on the Web. Apparently, quite a few turned up!

Given that Lerdorf has also famously said, “I really don’t like programming. I built this tool to program less so that I could just reuse code”, PHP’s eventual success is perhaps even more impressive.

Given the usage statistics above, it would certainly be difficult to argue that PHP isn’t mature. Whether you’d actually choose it for your next backend is, of course, an entirely different question. I’ll leave that particular can of worms firmly closed!

As mentioned above PHP was created by Rasmus Lerdorf in 1994, initially as a small collection of tools for maintaining his personal website. Originally called “Personal Home Page Tools”, it evolved into a server-side scripting language, with PHP/FI released publicly in 1995. PHP 3 followed in 1998, establishing much of the language we would recognise today and introducing the recursive name PHP: Hypertext Preprocessor.

PHP grew rapidly alongside the Web, becoming particularly popular for building dynamic websites and applications. Major releases including PHP 5 in 2004, PHP 7 in 2015, and PHP 8 in 2020 significantly improved its object-oriented features, performance, type system, and overall developer experience. After more than 30 years, PHP remains a mature and widely used web technology, powering platforms such as WordPress, Drupal, and frameworks including Laravel and Symfony.

Using PHP with GOV.UK Frontend

Using PHP with GOV.UK Frontend is fairly straightforward, particularly if you already know Laravel. Pages are rendered server-side using Laravel and Blade, with native PHP components generating the GOV.UK HTML. GOV.UK Frontend provides the official CSS, fonts, assets, and JavaScript for progressive enhancement, with no client-side frameworks, Nunjucks, or Node.js required at request time. Node.js is only used during development to install GOV.UK Frontend, compile the Sass, and run the shared HTML fixture checks.

As with the other implementations mentioned in the post, the more difficult part is keeping the PHP components in sync with GOV.UK Frontend components. The native PHP renderers need to follow the official Nunjucks macros and template.njk files, with their output checked against the official fixtures to ensure the generated HTML remains identical. In practice, building everyday Laravel pages is the easy part. Maintaining that compatibility as GOV.UK Frontend evolves is where most of the additional work lies.

Advantages and disadvantages of PHP for GOV.UK services

Advantages

• Fits the GOV.UK model: server-rendered HTML, one thing per page, forms that work without JavaScript. Progressive enhancement is natural in PHP/Laravel, not an afterthought.
• No frontend UI framework required. Official GOV.UK Frontend CSS/JS (pinned 6.5.1 here) is enough. React/Vue/etc. just add cost in time and complexity.
• Laravel is strong for journeys: sessions, CSRF, validation, Blade pages, middleware (security headers, proxies). That maps cleanly onto Design System patterns (error summary, retained values, novalidate).
• PHP is still widely used in UK public-sector backends, so hiring and existing systems can be easier than introducing a new language just for the UI.
• The example I’ve created shows you can prove correctness with official fixtures.json (byte-for-byte PHP HTML vs Frontend), which is what GOV.UK Frontend actually allows teams to test.

Disadvantages

• GOV.UK Frontend is a Node + Nunjucks product. PHP cannot call the macros in-process, so you must reimplement HTML in native PHP and keep it in sync with template.njk manually.
• This synchronisation process is higher maintenance than a Node-only stack: every Frontend upgrade is PHP renderer work plus fixture test re-runs, not a simple “bump npm and the macros emit the brand new fully compliant HTML”.
• The use of Node in the toolchain is still a hard requirement e.g. to install govuk-frontend, its Sass, and shared fixture checks. The runtime is PHP, but the design-system toolchain is not. This equals two ecosystems, two lock files, and Docker often needs both.
• The GOV.UK Frontend Official docs, examples, and community answers assume Nunjucks is being used. PHP teams will need to translate options/escaping themselves which is easy to drift on whitespace, attributes, html vs text.
• Hosting takes more work than Node.js, where many platforms provide sensible defaults out of the box. Laravel requires some additional configuration and infrastructure, which is perfectly manageable for the example in my repository, but would need more thought and operational support for a government service in production.

PHP GOV.UK Frontend example

Here you will find links to the demo and associated resources:

• GitHub Repository
• Example Service^† and components^†
• AI-specific context: govuk-frontend-php.mdc

^† These demos are hosted on Render's free tier, so the first request after a period of inactivity may take around 50 seconds while the service starts up.

Ruby

What is Ruby?

The main thing I know about Ruby is that GOV.UK (www.gov.uk) is built with it. I also spent a fair amount of time annoying Ruby developers whenever I wanted to change something on the frontend. This is how I learned that the Rails asset pipeline is apparently a magical black box that nobody should look at too closely!

Ruby was created by Japanese programmer Yukihiro “Matz” Matsumoto in 1993 and publicly released in 1995. He designed it to make programming enjoyable and productive, combining ideas from languages such as Perl, Smalltalk, and Lisp. Ruby is an object-oriented, dynamically typed language known for its readable, expressive syntax and its philosophy of optimising for developer happiness.

Ruby became significantly more popular after the release of Ruby on Rails in 2004. Rails made it possible to build web applications quickly using conventions rather than large amounts of configuration, and it became particularly influential during the Web 2.0 era. While Ruby is less dominant in new web projects today, it remains a mature, well-supported language with a large ecosystem and continues to power major production systems.

How mature is Ruby?

Do I even need to bother with this section? Directly above it literally says:

While Ruby is less dominant in new web projects today, it remains a mature, well-supported language with a large ecosystem and continues to power major production systems.

Using Ruby with GOV.UK Frontend

Using Ruby with GOV.UK Frontend is fairly straightforward, particularly if you're familiar with Ruby on Rails. Pages are rendered server-side using Rails and its built-in ERB templates, with native Ruby components generating the GOV.UK HTML. GOV.UK Frontend provides the official CSS, fonts, assets, and JavaScript for progressive enhancement, with no client-side frameworks, Nunjucks, or Node.js required at request time. Node.js is only used during development to install GOV.UK Frontend, compile the Sass, and run the shared HTML fixture checks.

As with the other implementations, the main challenge is maintaining compatibility with GOV.UK Frontend. The native Ruby renderers need to replicate the official Nunjucks macros and template.njk files, with their output tested against the official fixtures to ensure the generated HTML remains identical. Rails makes building server-rendered pages relatively straightforward, but keeping those components aligned with future GOV.UK Frontend releases introduces additional maintenance. As with PHP, the complexity isn't really in the backend framework itself, but in maintaining the HTML contract that GOV.UK Frontend expects.

It’s worth mentioning that www.gov.uk, is built on Ruby on Rails and its components and documentation are all available on GitHub.

Advantages and disadvantages of Ruby for GOV.UK services

Advantages

• GDS and many other UK government departments already run Rails/Sinatra services, so hiring, patterns, and DevOps knowledge exist in-house and among suppliers across the whole public sector.
• Server-rendered Rails journeys fit the Service Manual perfectly, with progressive enhancement, forms, Post/Redirect/Get (PRG), sessions, and accessible HTML all fitting naturally into the Rails model, without the need for any client-side framework.
• The Ruby ecosystem covers routing, CSRF, cookies, validation, and ViewComponent-style composition for multistep government services.
• RSpec makes it straightforward to test HTML output against GOV.UK Frontend fixtures, helping ensure components remain in parity with the Design System.
• Concise syntax and Rails conventions help small teams ship content-heavy, form-led services quickly.
• Native Ruby can follow the Nunjucks macros and prove its HTML output matches the official GOV.UK Frontend fixtures, without relying on React, Vue, Angular, Svelte, or any other client-side framework.

Disadvantages

• As we have already discussed many, many times GOV.UK Frontend is built with Node + Nunjucks, so Ruby must reimplement or wrap component HTML and treat upgrades as careful parity work rather than drop-in macros.
• You still require the Node stack for GOV.UK Frontend's, Sass, and fixtures alongside Ruby/Bundler, which adds install and CI complexity and maintenance surface.
• The Design System examples and community packages use Nunjucks/JS, so Ruby ports can lag or diverge unless you (or your team) invest in regular parity updates.
• Rails apps are more resource-heavy compared to minimal Node/static setups, and free-tier or container images need care around native gems, assets, and memory.
• Ruby on Rails, typically running across multiple Puma processes, is well suited to most services, although other stacks can handle very high levels of concurrent I/O more efficiently.
• Some newer service teams prefer TypeScript end-to-end, as its popularity has grown over the years, so Ruby skills are common in GOV.UK circles but not universal across digital suppliers outside the public sector.

Ruby GOV.UK Frontend example

Here you will find links to the demo and associated resources:

• GitHub Repository
• Example Service^† and components^†
• AI-specific context: govuk-frontend-ruby.mdc

^† These demos are hosted on Render's free tier, so the first request after a period of inactivity may take around 50 seconds while the service starts up.

Rust

What is Rust?

I must admit, I know very little about Rust apart from the huge number of times it has been mentioned on Hacker News. Many themes seem to be about migrating from x to Rust, so I guess the hype train is real. So let’s find out more, this can be a TIL for me too!

Rust began as a personal project by Mozilla developer Graydon Hoare in 2006, before Mozilla started sponsoring its development in 2009. The first stable release, Rust 1.0, arrived in 2015. It was designed as a systems programming language offering performance comparable to C and C++, while preventing many common memory-safety problems without relying on a garbage collector.

Since then, Rust has grown into a mature, open-source language governed through the Rust Foundation. Its strong memory-safety guarantees, performance, modern tooling, and support for concurrency have led to adoption in everything from operating systems and browsers to web services and cloud infrastructure.

How mature is Rust?

Yet again pipped to the post by the section above!

Rust has grown into a mature, open-source language governed through the Rust Foundation. Its strong memory-safety guarantees, performance, modern tooling, and support for concurrency have led to adoption in everything from operating systems and browsers to web services and cloud infrastructure.

Using Rust with GOV.UK Frontend

Using Rust with GOV.UK Frontend is entirely possible, although it requires a little more work than some of the other backend languages examined. Pages are rendered server-side using Rust and its native HTML templating capabilities, with custom Rust components generating the GOV.UK HTML. GOV.UK Frontend provides the official CSS, fonts, assets, and JavaScript for progressive enhancement, with no client-side frameworks, Nunjucks, or Node.js required at request time. Node.js is only used during development to install GOV.UK Frontend, compile the Sass, and run the shared HTML fixture checks.

As with the other implementations, the main challenge is maintaining compatibility with GOV.UK Frontend. The native Rust renderers need to replicate the official Nunjucks macros and template.njk files, with their output tested against the official fixtures to ensure the generated HTML remains identical. Rust's strong type system and memory safety offer some advantages, but its steeper learning curve, longer compilation times, and smaller ecosystem of GOV.UK-specific tooling can introduce additional complexity. In practice, building server-rendered pages is relatively straightforward once the foundations are in place. Maintaining compatibility with GOV.UK Frontend as it evolves remains the more significant long-term consideration.

Advantages and disadvantages of Rust for GOV.UK services

Advantages

• Efficient binaries and low memory use; suitable for high-traffic or constrained hosting.
• Memory safety and strong typing reduce common classes of runtime bugs.
• Fits a strict security baseline (e.g. headers, Content Security Policy (CSP), careful handling of trusted HTML).
• Supports server-rendered GOV.UK Frontend with progressive enhancement with no requirement for any client-side UI frameworks.
• Deploys as a single static binary without a heavy application runtime.
• Strong concurrency model for many concurrent form journeys.
• Ownership and typing make it easier to keep untrusted input separate from trusted HTML.

Disadvantages

• Smaller civil-service and GOV.UK developer pool than TypeScript, Python, or Java, so very likely to be much harder to recruit for.
• GOV.UK Frontend is Node/Nunjucks-first. Developers must reimplement Nunjucks macros in Rust and maintain fixture parity on all future upgrades.
• Rust has a steeper learning curve than many common government technology stacks, and compile times can be relatively slow.
• Fewer ready-made GOV.UK libraries, middleware, and examples than Node, Rails, or Django.
• As with all other languages Rust still depends on Node for GOV.UK Frontend, Sass, and HTML fixtures.
• Less widespread DevOps and assessment familiarity than more common departmental technology stacks like Java and .NET.
• For simple, form-based government services, Rust’s performance benefits may not justify the added development complexity.

Rust GOV.UK Frontend example

Here you will find links to the demo and associated resources:

• GitHub Repository
• Service^† and components^†
• AI-specific context: govuk-frontend-rust.mdc

^† These demos are hosted on Render's free tier, so the first request after a period of inactivity may take around 50 seconds while the service starts up.

How do the implementations compare?

In the tables below I have brought all of the above discussions together and focussed on each individual implementation.

The following metrics have been used for evaluation:

The experiment evaluation table below is wider than the standard blog content area. You can use the Expand table button to view it at full-screen width, and Collapse table to return to the standard width, if you find that easier than scrolling the table.

How popular and mature are these languages?

Let’s now look at the popularity and maturity of each language across the wider web, beyond just the UK public sector.

Important: Just because a technology is popular doesn't mean it's the right choice. Popularity and suitability are two very different things.

Just because a language is widely adopted, loved by developers, or considered the latest and greatest doesn't mean it's the right choice for a UK government service. Technology decisions should be driven by the needs of the service and its users, not developer popularity contests.

TypeScript and Node.js

TypeScript and Node.js are both firmly established technologies, with large communities and widespread use across the public and private sectors. In the 2025 Stack Overflow Developer Survey, 48.8% of professional developers reported using TypeScript, while 49.1% reported using Node.js. TypeScript's growth is particularly noticeable. In 2025, it became the most-used language on GitHub by monthly contributor count, reaching 2.64 million contributors and growing by 66.6% year-on-year. (Stack Overflow Developer Survey 2025)

Neither technology is particularly new anymore. TypeScript was first released publicly in 2012, while Node.js dates back to 2009, giving both ecosystems plenty of time to mature and build up a large pool of experienced developers. Both remain actively maintained. TypeScript typically releases around every three months, while Node.js has a formal LTS lifecycle providing around 30 months of long-term support. Real-world use is also easy to find. GDS explicitly uses Node.js for server-side JavaScript, including projects such as GOV.UK Pay, GOV.UK Frontend, GOV.UK Prototype Kit, and GOV.UK One Login. Overall, TypeScript usage appears to be growing strongly, while Node.js looks mature and stable, with a giant established user base. (GDS Way)

Key statistics

• 48.8% of professional developers reported using TypeScript in the 2025 Stack Overflow Developer Survey. (Stack Overflow Developer Survey 2025)
• 49.1% of professional developers reported using Node.js in the 2025 Stack Overflow Developer Survey. (Stack Overflow Developer Survey 2025)
• TypeScript became the #1 language on GitHub by monthly contributors in August 2025, with 2.64 million contributors, up 66.6% year-on-year. (GitHub Octoverse 2025)
• W3Techs detects Node.js on 7.2% of websites where the web server can be identified, rising to 23.1% among the top 1,000 websites. (W3Techs)
• TypeScript was first unveiled in 2012, making it around 14 years old. (Microsoft TypeScript Blog)
• Node.js dates back to 2009, making it around 17 years old.
• TypeScript typically releases around every three months. (TypeScript release process)
• Node.js LTS releases typically receive critical fixes for 30 months. (Node.js release schedule)
• GDS lists Node.js as one of its core backend development technologies and uses it across several major GOV.UK products. (GDS Way)

Overall: Very high adoption, mature, actively maintained, and a large pool of experienced developers. TypeScript usage is increasing strongly, while Node.js remains a well-established and widely used server-side platform.

Go

Go is now a well-established backend language with a sizeable and growing professional developer community. In the 2025 Stack Overflow Developer Survey, 17.4% of professional developers reported using Go, up from 14.4% in 2024. The wider developer figure also increased from 13.5% to 16.4%, suggesting that Go is still gaining adoption rather than simply maintaining an existing user base. GitHub provides another strong signal: Go remained one of the top 10 most-used languages on GitHub in 2025, alongside much older languages such as Java, C#, C++, and PHP. (Stack Overflow Developer Survey 2025)

Go is not particularly new anymore either. It was created at Google in 2007 and released publicly in November 2009, making it around 17 years old. It remains very actively maintained, with a predictable six-month major release cycle and a strong backwards compatibility guarantee. The developer pool is also considerably larger than its Stack Overflow percentage might propose: JetBrains estimates that 2.2 million professional developers use Go as their primary language, and well over 5 million use it as either a primary or secondary language. Real-world use spans both sectors, from GOV.UK Platform Engineering in the UK public sector to Google, PayPal, American Express, Cloudflare, Netflix, Uber, and many others internationally. Overall, Go appears to be mature, actively maintained, and continuing to grow, particularly for backend services, APIs, cloud infrastructure, and platform engineering. (JetBrains)

Key statistics

• 17.4% of professional developers reported using Go in the 2025 Stack Overflow Developer Survey, up from 14.4% in 2024. (Stack Overflow Developer Survey 2025)
• Across all respondents, Go usage increased from 13.5% in 2024 to 16.4% in 2025. (Stack Overflow Developer Survey 2025)
• 56.5% of developers already using Go want to continue using it, while Stack Overflow specifically notes that Python developers show strong interest in Go for high-performance systems programming. (Stack Overflow Developer Survey 2025)
• Go remained one of the top 10 programming languages on GitHub in 2025. GitHub has previously highlighted cloud-native projects such as Kubernetes and Prometheus as major contributors to Go's growth. (GitHub Octoverse 2025)
• JetBrains estimates that 2.2 million professional developers use Go as their primary language, around twice as many as five years earlier. Including developers who use Go as a secondary language takes the estimate to more than 5 million professional developers. (JetBrains Developer Ecosystem 2025)
• In the official 2025 Go Developer Survey, 87% of respondents were professional developers, 82% used Go for their primary job, and 75% had at least six years of professional development experience. (Go Developer Survey 2025)
• Go became a public open-source project in November 2009, making it around 17 years old. (Go FAQ)
• Go has a predictable six-month major release cycle. The current Go 1.27 release arrived in August 2026, six months after Go 1.26. (Go release cycle)
• Each major Go release is supported until two newer major releases have been published, with critical bugs and security issues fixed through minor releases. (Go release history)
• GDS describes Go as an actively used language, with GOV.UK Platform Engineering using it for Kubernetes operators, command-line tools, APIs, microservices, and services including GOV.UK Router and GOV.UK Mirror. (GDS Way)
• Go's official case studies document production use by organisations including Google, PayPal, American Express, Cloudflare, Netflix, Uber, Dropbox, Microsoft, Twitch, and Mercado Libre. (Go case studies)

Overall: High and growing adoption, mature, actively maintained, and supported by a large pool of experienced developers. Go is less ubiquitous than languages such as JavaScript, TypeScript, Java, or Python, but its usage continues to increase, and it is particularly well established for backend services, cloud infrastructure, APIs, and platform engineering.

Java

Java remains one of the world's most widely used programming languages, particularly for backend and enterprise software. In the 2025 Stack Overflow Developer Survey, 29.6% of professional developers reported using Java, putting it alongside C# and comfortably ahead of languages such as Go, Rust, Kotlin, and Ruby. GitHub tells a similar story: Java was the fourth most-used language on GitHub in 2025, with its monthly contributor base growing by 20.7% year-on-year. More than 3.5 million new Java repositories were created during the Octoverse reporting period, showing that Java is not simply surviving because of old enterprise systems, but continues to be used for substantial amounts of new development. (Stack Overflow Developer Survey 2025)

Java is also one of the most mature languages in this comparison. It was first released by Sun Microsystems in 1995, making it more than 31 years old, but development of the platform remains extremely active. Java now follows a predictable six-month release cycle, with Java 27 released in September 2026, while designated LTS releases provide organisations with much longer support windows. Its age also means there is an unusually large pool of experienced developers: JetBrains' 2025 research describes Java developers as a seasoned global community, with nearly half having at least 6 to 10 years of professional experience. Real-world use spans both sectors, from Java being one of GDS's core backend languages in the UK government to large-scale private-sector systems at organisations such as Uber. Overall, Java looks mature and remarkably stable, while GitHub activity suggests that active development is still growing rather than simply maintaining legacy systems. (The State of Java 2025)

Key statistics

• 29.6% of professional developers reported using Java in the 2025 Stack Overflow Developer Survey, with 29.4% across all respondents. (Stack Overflow Developer Survey 2025)
• Java usage across all Stack Overflow respondents changed only slightly from 30.3% in 2024 to 29.4% in 2025, proposing a large and broadly stable developer base. (Stack Overflow Developer Survey 2024)
• Java was the #4 programming language on GitHub in 2025, behind TypeScript, Python, and JavaScript. (GitHub Octoverse 2025)
• Java added approximately 174,700 monthly contributors on GitHub between August 2024 and August 2025, representing 20.7% year-on-year growth. (GitHub Octoverse 2025)
• More than 3.52 million new repositories primarily using Java were created on GitHub between September 2024 and August 2025, an increase of 9.35% over the comparable previous period. (GitHub Octoverse 2025)
• Maven Central, the largest repository for Java-based components, recorded 839 billion downloads in 2025, up 19.4% year-on-year, with more than 808,000 components and almost 25 million releases in its cumulative catalogue. (Sonatype State of the Software Supply Chain 2026)
• Java was first publicly released in 1995, making it more than 31 years old. (Java.com)
• Java uses a predictable six-month feature release cycle, with new releases arriving every March and September. Java 27 was released in September 2026. (Java platform evolution)
• Oracle currently designates Java 8, 11, 17, 21, and 25 as Long-Term Support releases, with future LTS releases planned every two years. Java 25, for example, has Premier Support planned until September 2030 and Extended Support until September 2033. (Oracle Java SE Support Roadmap)
• JetBrains' 2025 research describes Java as a seasoned global developer community, with nearly half of surveyed Java developers having 6 to 10 years of professional experience or more. (The State of Java 2025)
• GDS lists Java as one of its core backend development languages, alongside Python, Ruby, and JavaScript/Node.js, and recommends these languages for new backend development. (GDS Way)
• Large private-sector engineering organisations continue to use Java in production. Uber, for example, identifies Java as one of its supported backend languages and has used it across its services and infrastructure. (Uber Engineering)

Overall: Very high adoption, extremely mature, actively maintained, and supported by a gigantic pool of experienced developers. Java's overall developer share appears broadly stable, while GitHub activity continues to grow strongly. More than 30 years after its introduction, it remains particularly well established for backend services, enterprise applications, high-volume transactional systems, and long-lived public and private-sector software.

C# and .NET

C# and .NET are firmly established technologies with particularly strong adoption in backend, enterprise, cloud, and business software. In the 2025 Stack Overflow Developer Survey, 29.9% of professional developers reported using C#, up slightly from 28.8% in 2024. GitHub provides another strong signal: C# was the fifth most-used language on GitHub in 2025, adding around 136,700 monthly contributors and growing by 22.2% year-on-year. Nearly 1.48 million new repositories primarily using C# were also created during the Octoverse reporting period, showing that C# remains a language used for substantial amounts of new development rather than simply maintaining older .NET applications. (Stack Overflow Developer Survey 2025)

Neither C# nor .NET are particularly new anymore. C# 1.0 and .NET Framework 1.0 were released in 2002, making the stack around 24 years old. Modern .NET remains very actively developed, with a new major release every November, monthly servicing updates, and LTS releases receiving three years of support. There is also a large pool of experienced developers: JetBrains' 2025 .NET survey found that 59% of respondents had six or more years of professional coding experience. Real-world use spans both the public and private sectors, with the UK Department for Education maintaining multiple C# and ASP.NET Core services, while organisations such as Stack Overflow and Microsoft use .NET in production. Overall, C# and .NET appear to be mature, actively maintained, and broadly stable to growing, with GitHub activity showing particularly healthy growth. (The State of .NET 2025)

Key statistics

• 29.9% of professional developers reported using C# in the 2025 Stack Overflow Developer Survey, up from 28.8% in 2024. (Stack Overflow Developer Survey 2025)
• Across all Stack Overflow respondents, C# usage increased from 27.1% in 2024 to 27.8% in 2025, suggesting a large and broadly stable developer base with modest recent growth. (Stack Overflow Developer Survey 2025)
• C# was the #5 programming language on GitHub in 2025, behind TypeScript, Python, JavaScript, and Java. (GitHub Octoverse 2025)
• C# added approximately 136,700 monthly contributors on GitHub between August 2024 and August 2025, representing 22.2% year-on-year growth. (GitHub Octoverse 2025)
• Around 1.48 million new repositories primarily using C# were created on GitHub between September 2024 and August 2025, an increase of 10.6% over the comparable previous period. (GitHub Octoverse 2025)
• W3Techs detects ASP.NET on 4.2% of websites where the server-side language can be identified, rising to 10.9% among the top one million websites and 13.5% among the top 100,000. (W3Techs)
• C# 1.0 was released in January 2002, making the language around 24 years old. The first widely distributed C# implementation had appeared as part of Microsoft's .NET initiative in 2000. (Microsoft C# version history)
• The .NET Framework 1.0 was released in 2002, while the modern cross-platform .NET lineage began with .NET Core in 2016. (Microsoft .NET lifecycle)
• Modern .NET has a predictable annual major release every November, alongside monthly servicing updates. Even-numbered releases such as .NET 10 are LTS releases and receive three years of support. (.NET support policy)
• The current stable platform is .NET 10 LTS, released in November 2025 and supported until November 2028. C# 14 was released alongside the .NET 10 generation in November 2025. (.NET support policy)
• In JetBrains' 2025 .NET research, 59% of respondents had six or more years of professional coding experience, including 24% with more than 16 years, providing a strong indication of the availability of experienced developers. (The State of .NET 2025)
• The same JetBrains survey found that 68% of .NET developers work on web applications and 50% work on backend services, making backend web development one of the ecosystem's main use cases. (The State of .NET 2025)
• The UK Department for Education actively maintains numerous C# and .NET services, including its Teaching Record System, Get Information About Pupils service, Family Hubs services, and education APIs. (Department for Education on GitHub)
• Large private-sector organisations using .NET include Stack Overflow, Fidelity, Chipotle, H&R Block, Microsoft Teams, Microsoft Graph, and others documented in Microsoft's production customer case studies. (.NET customer showcase)

Overall: Very high adoption, extremely mature, actively maintained, and supported by a massive pool of experienced developers. C# usage appears broadly stable with signs of continued growth, particularly on GitHub. Modern .NET has evolved well beyond its original Windows-only roots into an actively developed, cross-platform platform for web applications, backend services, APIs, cloud workloads, and large enterprise systems.

Python

Python is one of the world's most widely used programming languages, with a particularly strong presence in backend development, data science, automation, and AI. In the 2025 Stack Overflow Developer Survey, 54.8% of professional developers reported using Python, while usage across all respondents reached 57.9%, up from 51% in 2024. GitHub provides an equally strong signal: Python was the second most-used language on GitHub in 2025, adding around 850,000 contributors and growing by 48.8% year-on-year. Its recent growth has been particularly strong because of AI and machine learning, but its use extends well beyond these areas into web applications, APIs, scripting, infrastructure, and general backend development. (Stack Overflow Developer Survey 2025)

Python is also one of the most mature languages in this comparison. Development began in 1989, with its first public release in 1991, making it around 35 years old. Despite that age, Python remains very actively developed, with a predictable annual feature release every October and each release supported for five years. There is also a considerable pool of experienced developers, supported by decades of commercial use and an enormous global community. Real-world use spans both sectors: GDS lists Python as one of its core backend languages, with services such as GOV.UK Notify running Python in production, while Meta uses Python and Django for the backend of Instagram and Threads. Overall, Python appears to be mature, actively maintained, and growing strongly, with particularly rapid recent growth around AI, data, and backend development. (Python release cycle)

Key statistics

• 54.8% of professional developers reported using Python in the 2025 Stack Overflow Developer Survey. (Stack Overflow Developer Survey 2025)
• Across all Stack Overflow respondents, Python usage increased from 51% in 2024 to 57.9% in 2025, an increase of around 7 percentage points in a single year. (Stack Overflow Developer Survey 2025)
• Among people learning to code, 71.8% reported using Python, the highest figure for any programming language in that group. (Stack Overflow Developer Survey 2025)
• Python was the #2 programming language on GitHub in 2025, behind TypeScript and ahead of JavaScript, Java, and C#. (GitHub Octoverse 2025)
• Python added approximately 850,000 monthly contributors on GitHub between August 2024 and August 2025, representing 48.8% year-on-year growth. (GitHub Octoverse 2025)
• Nearly half of all new AI projects on GitHub in 2025 were primarily written in Python, with around 582,000 new Python AI repositories, up 50.7% year-on-year. (GitHub Octoverse 2025)
• W3Techs detects Python on 1.1% of websites where the server-side programming language can be identified, rising to 2.5% among the top 1,000 websites. This is worth treating cautiously because server-side languages cannot always be detected externally. (W3Techs)
• The Python Developers Survey attracted more than 30,000 Python developers and enthusiasts from almost 200 countries and regions, demonstrating the scale and geographical spread of the community. (Python Developers Survey 2024)
• In the same survey, 48% of developers who primarily use Python reported using it for web development, while 49% reported using it for data analysis and 42% for machine learning. (Python Developers Survey 2024)
• Python's first public release was in February 1991, making the language around 35 years old. (Python documentation)
• Python follows a predictable annual feature release cycle, with a new feature version scheduled every October. Each release is supported for five years, currently consisting of two years of full bug-fix support followed by three years of security fixes. (PEP 602)
• In the web-focused 2025 Django Developer Survey, 56% of respondents had at least six years of professional coding experience, while 56% had been programming in Python for at least six years, providing a useful indication of the availability of experienced Python web developers. (Django Developer Survey 2025)
• GDS lists Python as one of its core backend development languages and recommends it for new backend development. GOV.UK Notify's API and frontend applications currently run Python 3.13 in production. (GDS Way, GOV.UK Notify API)
• Large private-sector systems continue to use Python at significant scale. Meta states that Instagram uses Python and Django for its backend, with Threads reusing the same backend technology, data models, business logic, security features, and server infrastructure. (Meta Engineering)

Overall: Very high adoption, extremely mature, actively maintained, and supported by a very large pool of experienced developers. Python was already one of the world's most widely used languages, but current evidence suggests its usage is growing strongly rather than simply remaining stable. Although much of the recent growth is being driven by AI and data science, Python also has a long-established role in backend web development, APIs, automation, public-sector services, and large-scale commercial systems.

PHP

PHP remains one of the most widely deployed server-side languages on the web, even if it receives less attention than newer languages. In the 2025 Stack Overflow Developer Survey, 19.1% of professional developers reported using PHP, while usage across all respondents reached 18.9%, up slightly from 18.2% in 2024. GitHub provides another useful signal: PHP was still the sixth most-used programming language on GitHub in 2025, ahead of Shell, C++, HCL, and Go. Its real-world deployment footprint is even more striking. W3Techs detects PHP on 69.8% of websites where the server-side language can be identified, making it by far the most widely detected server-side language on the web. (Stack Overflow Developer Survey 2025)

PHP is also one of the more mature languages in this comparison. It was created in 1994 and publicly released in 1995, making it around 31 years old. It remains actively developed, with regular yearly feature releases, frequent maintenance releases, and four years of support for each current release branch. Its developer community is similarly mature: JetBrains found that 88% of PHP developers have more than three years of experience, with the largest group having between six and ten years. PHP is also still used extensively across both sectors, from the PHP-based VA.gov content management platform in the US public sector to the enormous WordPress ecosystem. Overall, PHP looks mature and broadly stable from a developer-adoption perspective, while its share of detectable server-side websites is gradually declining from an exceptionally large installed base. (The State of PHP 2025)

Key statistics

• 19.1% of professional developers reported using PHP in the 2025 Stack Overflow Developer Survey, compared with around 18.7% in 2024. (Stack Overflow Developer Survey 2025)
• Across all Stack Overflow respondents, PHP usage increased slightly from 18.2% in 2024 to 18.9% in 2025, suggesting a large and broadly stable developer community rather than rapid decline. (Stack Overflow Developer Survey 2024, Stack Overflow Developer Survey 2025)
• PHP was the #6 programming language on GitHub in 2025, behind TypeScript, Python, JavaScript, Java, and C#. (GitHub Octoverse 2025)
• W3Techs detects PHP on 69.8% of all websites where the server-side programming language can be identified. Even among the top 1,000 websites, PHP is detected on 58.8%. (W3Techs)
• PHP's server-side web share is gradually declining, from 76.8% in October 2023 to 69.8% in October 2026, but it remains by far the dominant detectable server-side language. (W3Techs historical trends)
• WordPress, which is built on PHP, is used by around 40.1% of all websites and holds approximately 58.6% of the identifiable CMS market. (W3Techs WordPress statistics)
• Packagist, the main public repository for Composer packages, now contains more than 469,000 PHP packages, 5.8 million package versions, and has passed 200 billion package installations. (Packagist, 15 years of Packagist)
• Packagist recorded more than 36 billion package installations during 2026 alone by late September, already exceeding the total for the whole of 2025, with monthly installs reaching 4.9 billion in August 2026. (15 years of Packagist)
• PHP was created in 1994 and its source code was first released publicly in June 1995, making the public language around 31 years old. (PHP history)
• PHP follows a broadly annual feature release cycle. PHP 8.5 was released in November 2025, while PHP 8.6 is already in release-candidate testing ahead of its next stable release. (PHP releases, PHP 2026 news archive)
• Each current PHP release branch receives two years of full support followed by two additional years of security fixes, giving each release around four years of official support. (PHP supported versions)
• In JetBrains' 2025 research, 88% of PHP developers had more than three years of experience, with the largest individual group having six to ten years of experience. Almost three-quarters, 72%, had been using PHP for more than four years. (The State of PHP 2025)
• The same JetBrains survey found that 58% of PHP developers did not plan to migrate away from PHP during the following year, while Laravel remained the most commonly used PHP framework among respondents at 64%. (The State of PHP 2025)

Overall: High adoption, extremely mature, actively maintained, and supported by a large and experienced developer community. PHP is not growing as quickly as languages such as TypeScript, Python, or Go, and its share of detectable server-side websites is gradually falling. However, that decline is from an exceptionally large installed base: PHP remains the dominant detectable server-side language on the web, ranks sixth on GitHub, and continues to support an enormous ecosystem of modern applications, frameworks, content platforms, public-sector services, and commercial websites.

Ruby

Ruby remains a well-established backend language, although its developer share is considerably smaller than languages such as Java, Python, C#, or TypeScript. In the 2025 Stack Overflow Developer Survey, 6.9% of professional developers reported using Ruby, up from 5.8% in 2024, while 6.4% of all respondents reported using it, up from 5.2%. Ruby on Rails also remains actively used, with 6.2% of professional developers reporting Rails usage. The longer-term picture is more mixed: JetBrains describes Ruby as being in a gradual long-term decline, but the most recent Stack Overflow figures actually increased. More importantly, real-world deployment remains substantial: W3Techs detects Ruby on 7.1% of websites where the server-side language can be identified, rising to 12.4% among the top one million websites. (Stack Overflow Developer Survey 2025)

Ruby is also one of the most mature languages in this comparison. It was first released publicly in 1995, making it around 31 years old, and remains actively developed, with Ruby 4.0 released in December 2025 and regular maintenance releases continuing throughout 2026. Its smaller community is also unusually experienced: in the 2024 Ruby on Rails Community Survey, 70% of respondents had at least seven years of Rails experience and 53% had ten years or more. Real-world use spans both sectors. GOV.UK consists of at least 59 applications, most of which are built using Ruby on Rails, while GitHub.com remains a Rails application approaching two million lines of code and worked on by more than 1,000 engineers. Overall, Ruby looks mature and actively maintained, with a smaller but highly experienced developer community and substantial existing production use, despite evidence of a longer-term decline in its relative popularity. (GOV.UK Developer Documentation)

Key statistics

• 6.9% of professional developers reported using Ruby in the 2025 Stack Overflow Developer Survey, up from 5.8% in 2024. (Stack Overflow Developer Survey 2025)
• Across all Stack Overflow respondents, Ruby usage increased from 5.2% in 2024 to 6.4% in 2025. This is a useful recent increase, although it should not be treated as proof that the longer-term decline has reversed. (Stack Overflow Developer Survey 2025)
• 6.2% of professional developers reported using Ruby on Rails in 2025, up from 5.2% in 2024. Across all respondents, Rails increased from 4.7% to 5.9%. (Stack Overflow Developer Survey 2025)
• JetBrains' 2025 Developer Ecosystem research, based on 24,534 developers across 194 countries, identifies Ruby as one of the languages experiencing a long-term decline in relative usage, alongside PHP and Objective-C. (JetBrains Developer Ecosystem 2025)
• W3Techs detects Ruby on 7.1% of websites where the server-side programming language can be identified, rising to 12.4% among the top one million websites and 8.1% among the top 1,000. (W3Techs)
• RubyGems.org currently hosts more than 197,000 gems from around 250,000 registered users, with more than 268 billion cumulative package downloads. (RubyGems statistics)
• Ruby was first publicly released in 1995, making the language around 31 years old. Development of the language itself began in 1993. (Ruby history)
• Ruby continues to receive major language releases regularly. Ruby 3.3 was released in December 2023, Ruby 3.4 in December 2024, and Ruby 4.0 in December 2025. The latest Ruby 4.0 maintenance release, Ruby 4.0.7, was released in September 2026. (Ruby releases)
• Ruby uses defined maintenance phases. Ruby 4.0 is currently under normal maintenance until March 2028, followed by security maintenance until approximately March 2029. (Ruby maintenance branches)
• Current stable Ruby branches receive frequent maintenance releases. Ruby's maintainers have previously targeted a release roughly every two months for the latest stable branch, with earlier releases where significant fixes are required. (Ruby release schedule)
• The 2024 Ruby on Rails Community Survey received responses from 2,709 Rails developers across 106 countries. Around 70% had seven or more years of Rails experience, while approximately 53% had ten years or more, indicating a smaller but particularly experienced developer community. (Ruby on Rails Community Survey 2024)
• The same survey found that more than half of Rails developers had deployed a new Rails application during the previous two years, showing that the ecosystem is not limited to maintaining legacy applications. (Ruby on Rails Community Survey 2024)
• GDS lists Ruby as one of its core backend development languages and recommends it as an option for new backend development. GOV.UK itself consists of at least 59 separate applications, most of which are built using Ruby on Rails. (GDS Way, GOV.UK Developer Documentation)
• GitHub.com has been a Ruby on Rails application since its beginning. GitHub reported that the application had grown to nearly two million lines of code, with more than 1,000 engineers collaborating on it daily and deployments taking place as often as 20 times per day. (GitHub Engineering)
• Shopify is another major Ruby user. Its core Rails application has grown to millions of lines of Ruby code, and Shopify has invested directly in improving Ruby, Rails, YJIT, performance, tooling, and scalability. (Shopify Engineering)
• Rails continues to support large-scale commercial services. Cookpad, for example, uses Rails for a platform serving well over 100 million home cooks each month. (Ruby on Rails case study)

Overall: Moderate global developer adoption, extremely mature, actively maintained, and supported by a smaller but highly experienced pool of developers. Ruby's relative popularity has declined considerably from its peak, and the available developer pool is smaller than for JavaScript, Python, Java, or C#. However, recent Stack Overflow figures show a modest increase, its package and production ecosystems remain substantial, and Ruby continues to power major systems including GOV.UK, GitHub, Shopify, and other large-scale commercial services. It would therefore be difficult to describe Ruby as obsolete or unused. It is better characterised as an established, mature technology with a smaller and more specialised community than it once had.

Rust

Rust has a smaller developer community than languages such as Java, Python, C#, or TypeScript, but the evidence points strongly towards continued growth. In the 2025 Stack Overflow Developer Survey, 14.5% of professional developers reported using Rust, while usage across all respondents reached 14.8%, up from 12.6% in 2024. Rust was also Stack Overflow's most admired programming language again in 2025, with 72% of developers who use it wanting to continue doing so. GitHub has identified a similar trend: its 2024 Octoverse ranked Rust seventh among the fastest-growing languages, while JetBrains' 2025 research places Rust alongside TypeScript and Go as one of the languages with the strongest perceived growth potential. (Stack Overflow Developer Survey 2025)

Rust is younger than most of the other languages in this comparison, but it has now been stable for more than a decade. Development began as a research project before Rust 1.0 was released in May 2015, making the stable language around 11 years old. It remains extremely actively maintained, with a new stable release every six weeks and strong backwards compatibility guarantees. Professional use is also becoming much more significant: the official State of Rust survey found that 45% of respondents worked at organisations making non-trivial use of Rust, while JetBrains estimates that around 2.27 million developers used Rust during a 12-month period. Real-world adoption includes backend services, cloud infrastructure, operating systems, embedded software, and performance-critical APIs, with production users including AWS, Meta, Google, Microsoft, Discord, and Cloudflare. Public-sector use is smaller but growing too, including Rust-based backend APIs within the UK Department for Transport's Connectivity Tool. Overall, Rust appears to be maturing quickly and growing strongly, although experienced Rust developers remain less widely available than developers for longer-established languages. (State of Rust Survey)

Key statistics

• 14.5% of professional developers reported using Rust in the 2025 Stack Overflow Developer Survey, while 14.8% of all respondents reported using it. (Stack Overflow Developer Survey 2025)
• Across all Stack Overflow respondents, Rust usage increased from 12.6% in 2024 to 14.8% in 2025, suggesting continued growth rather than a stable or declining developer base. (Stack Overflow Developer Survey 2024, Stack Overflow Developer Survey 2025)
• Rust was Stack Overflow's most admired programming language in 2025, with around 72% of existing Rust users wanting to continue using it. Rust also held the top position in 2024 when its admiration score was 83%. (Stack Overflow Developer Survey 2025)
• GitHub's 2024 Octoverse ranked Rust #7 among the fastest-growing programming languages and highlighted its continuing growth for safety, performance, and productivity. Rust did not enter GitHub's overall top 10 languages by contributor count in the 2025 report, showing that its community remains considerably smaller than languages such as TypeScript, Python, Java, C#, PHP, and Go. (GitHub Octoverse 2024, GitHub Octoverse 2025)
• JetBrains estimates that around 2.27 million developers used Rust during a 12-month period, with approximately 709,000 identifying Rust as their primary programming language. (JetBrains)
• JetBrains' 2025 research found that 26% of Rust developers surveyed already use Rust for professional projects, while the proportion of developers with three or more years of Rust experience continues to increase. (The State of Rust 2025)
• The official 2024 State of Rust Survey found that 38% of respondents used Rust for the majority of their coding at work, up from 34% the previous year. (State of Rust Survey 2024)
• 45% of respondents to the same survey worked for organisations making non-trivial use of Rust, up seven percentage points from 2023, while 82% said Rust had helped their company achieve its goals. (State of Rust Survey 2024)
• Rust expertise is increasing alongside adoption. In the 2024 State of Rust Survey, 53% of respondents considered themselves productive in Rust, up from 47% the previous year. The 2025 survey subsequently reported this increasing again to around 57%. (State of Rust Survey 2024, State of Rust Survey 2025)
• Rust 1.0 was released on 15 May 2015, making the stable language around 11 years old. The project itself dates back further, with its origins around 2006 to 2010. (Announcing Rust 1.0)
• Rust uses an unusually frequent and predictable six-week stable release cycle, which it has followed since Rust 1.0. The current stable version, Rust 1.99, was released on 1 October 2026. (Rust release model, Rust 1.99)
• Rust places considerable emphasis on backwards compatibility. Rust 1.0 established a commitment to stability, allowing the language to evolve through frequent releases without routinely breaking existing stable code. (Announcing Rust 1.0)
• The Rust package ecosystem is also growing rapidly. The crates.io team reported that package and download counts had been increasing by roughly 2 to 3 times year-on-year, while Rust infrastructure maintainers subsequently described download traffic as continuing roughly to double each year. (crates.io)
• AWS uses Rust in production across technologies including Firecracker, Amazon S3, EC2, CloudFront, Route 53, Bottlerocket, and components of the AWS Nitro System. Firecracker provides the virtualisation technology behind AWS Lambda and other serverless services. (AWS Open Source)
• Meta has made Rust one of its officially supported server-side programming languages, alongside languages such as C++, Python, and Hack, following accelerating internal adoption. (Meta Engineering)
• Discord identifies Rust as one of its most actively developed languages and has moved substantial production workloads to it. By February 2026, more than 80% of Discord's audio and video backend traffic was being served by its new Rust-based backend. (Discord Engineering, Discord 2026)
• Google's Android teams use Rust as part of their strategy for replacing memory-unsafe code, including extending its use into low-level firmware and security-critical components. (Google Security Blog)
• The UK Department for Transport's Connectivity Tool uses Cloud Run-hosted Rust and Python backend APIs for computationally intensive services, providing a current UK public-sector example of Rust being used in a digital service. (UK Government Digital Outcomes)
• Public-sector interest extends beyond the UK. The US Defense Advanced Research Projects Agency's Translating All C To Rust (TRACTOR) programme is funding research into automatically translating legacy C software into Rust. (DARPA FY2026 budget documentation)

Overall: Moderate but rapidly growing global adoption, increasingly mature, extremely actively maintained, and supported by a growing pool of experienced developers. Rust does not yet have the sheer developer availability of Java, Python, C#, PHP, or TypeScript, which remains an important consideration for mainstream service teams. However, adoption is consistently increasing, commercial use is becoming significantly more common, and Rust is already being trusted with performance-critical and security-sensitive production systems at some of the world's largest technology organisations. For backend web services it remains less mainstream than the older languages in this comparison, but it can no longer reasonably be described as niche or experimental.

So, where are the frontend frameworks?

Well, that’s an excellent question, isn’t it? Where are the frontend frameworks?

I’m pleased to say that none of the eight versions needed one. No React, Angular, Vue, Svelte or any other client-side framework. All eight services can deliver the same GOV.UK Frontend components and user journeys using only server-rendered HTML, with JavaScript added progressively where it actually improves the user experience.

That’s not to say frontend frameworks are bad. They absolutely have their place. But for most government services, I strongly believe they should be the exception rather than the default.

So, if you’re working on a government service and considering adding a frontend framework, I’d encourage you to ask two questions first:

What problem is adding a frontend framework actually solving?

And, perhaps more importantly:

What tangible benefit does it provide to the users of the service?

If it’s difficult to give a clear answer to either of those questions, then there’s a strong chance you don’t need a frontend framework at all.

I would rather not turn this into an “anti-framework” section of the post, but let’s discuss what problems frontend frameworks actually solve?

• Complex client-side state: Managing lots of interdependent state that changes without navigating to a new page.
• Highly interactive interfaces: Applications where users constantly manipulate, filter, rearrange, or interact with content.
• Frequent partial UI updates: Updating small parts of a page without repeatedly requesting and rendering whole pages.
• Reusable interactive components: Building complex components with behaviour, state, and rendering packaged together.
• Real-time experiences: Interfaces that continuously update from live data, such as dashboards, monitoring tools, or collaborative applications.
• Complex client-side workflows: Multi-step experiences where substantial logic needs to happen in the browser.
• Optimistic interfaces: Updating the UI immediately while an operation completes asynchronously in the background.
• Rich application-like experiences: Interfaces closer to desktop software than traditional document or form-based websites.
• Large-scale UI composition: Coordinating many independently changing parts of a complex interface.
• Shared client-side application architecture: Giving large frontend teams established patterns for state, routing, components, testing, and application structure.

The key distinction here is that most transactional government services are primarily forms, and their typical user journeys involve:

• content
• validation
• navigation
• standard HTTP request/response page flows

These services do not inherently require a frontend framework, as my elementary Fishing rod licence examples have shown.

If you require further evidence, it's worth looking at the Resources and tools page on the GOV.UK Design System website. Every tool listed must meet strict contribution criteria, and you'll notice that all but one of the tools listed is a backend languages or framework. That's no coincidence. With GOV.UK Frontend, you can build government services without needing a frontend framework at all!

Problems frontend frameworks can create

I won’t be calling out any particular framework, but in general frontend frameworks bring:

• Additional client-side dependencies: Frameworks usually introduce their own runtime, supporting libraries, build tooling, and third-party packages that need to be downloaded, maintained, updated, and secured.
• More JavaScript execution: More work is downloaded onto the user’s device, which can affect responsiveness, battery usage, and performance, particularly on older or lower-powered devices.
• Larger page weight: Framework runtimes, application bundles, and supporting dependencies can increase the amount of data users need to download before a service becomes fully usable.
• Hydration and lifecycle complexity: Where hydration is used, the browser has to reconcile server-rendered HTML with client-side application state, introducing another lifecycle and another potential source of failure.
• Accessibility responsibilities move into application code: Navigation, focus management, page titles, announcements, validation, and other browser behaviours may need to be explicitly recreated and tested.
• Progressive enhancement can become harder: If JavaScript becomes responsible for rendering or navigating the core service, providing a resilient HTML-first experience requires additional architectural effort.
• More failure modes: A service can now fail because of JavaScript errors, failed bundle downloads, hydration problems, client-side state bugs, API failures, or incompatibilities between server and client code.
• Greater reliance on APIs: Client-rendered applications commonly require additional HTTP APIs, creating another interface that needs designing, securing, versioning, testing, and operating.
• Duplicated state and validation: Business rules, validation, or application state can end up represented on both the client and server, increasing the risk of inconsistent behaviour.
• More complex build pipelines: Bundling, transpilation, code splitting, source maps, dependency management, and framework-specific tooling add additional moving parts to development and deployment.
• Long-term maintenance and framework churn: Frameworks, build tools, recommended patterns, and supporting ecosystems evolve, sometimes requiring substantial upgrades or application rewrites over the lifetime of a service.
• Larger security and dependency surface: More packages and more code running in the browser mean more dependencies, vulnerabilities, advisories, and updates for teams to monitor.
• Greater testing requirements: Teams may need to test server rendering, client rendering, hydration, JavaScript failure, navigation, accessibility, browser compatibility, and interactions between each layer.
• More demanding performance optimisation: Bundle sizes, code splitting, hydration cost, long tasks, and third-party dependencies become additional performance concerns that teams need to understand and manage.
• Browser behaviour may have to be recreated: Traditional HTML navigation provides features like browser history, URLs, scrolling, focus management, and document titles for free. Frontend frameworks may require additional JavaScript to recreate behaviour the browser already provides by default.
• Observability becomes more complicated: Failures can happen entirely within the browser, requiring client-side error reporting and monitoring alongside traditional server-side observability.
• More specialist skills are required: Future maintainers need to understand not only HTML, CSS, JavaScript, HTTP, and the backend, but also the framework, its architecture, build tooling, state management, and ecosystem.
• Harder handover between disciplines: Designers and frontend developers familiar with GOV.UK Frontend’s HTML and Nunjucks examples may have to understand framework-specific abstractions before making relatively simple frontend changes.
• More architectural coupling: Choosing a frontend framework can influence routing, state management, APIs, rendering strategy, deployment, testing, and hosting, making it harder to change one part of the architecture independently.
• More code between GOV.UK Frontend and the browser: Additional abstractions can make it harder to see exactly what HTML is ultimately being delivered and whether it still matches the GOV.UK Frontend component contract.
• More work during GOV.UK Frontend upgrades: Wrappers, adapters, or framework-specific component implementations may need updating when upstream component markup or behaviour changes.
• A higher maintenance baseline: Even a relatively simple forms-based service inherits the operational and technical complexity of the framework whether or not the service actually requires its capabilities.

Now, I realise a reader may look at the list above and think, “Wow, that’s a lot of negatives”. It certainly is!

But, before anyone reaches for their pitchforks and accuses me of having a personal vendetta against frontend frameworks, there are genuinely good reasons to use them in government services in certain scenarios. I even wrote about one recently. Yes, really!

In my recent post, "Progressively Enhancing Maps for UK Government Services", I looked at the Defra Interactive Map component and how its resilience could potentially be improved by progressively enhancing the experience, with static maps as a fallback when JavaScript fails. Defra has a genuine need for interactive maps. Given that they’re the Department for Environment, Food and Rural Affairs, that’s hardly surprising!

In this case, the additional complexity of a frontend framework is justified because it solves a real user need, rather than introducing complexity for the sake of it. For example, Defra services handle:

• Flood warnings: show the geographical extent of a flood warning or severe flood warning, rather than relying on place names alone.
• Flood defences: show flood walls, embankments, pumping stations, barriers, and other flood defence infrastructure.
• River and catchment management: show rivers, catchments, river basin districts, water bodies, and areas covered by particular management measures.
• Environmental permits: allow somebody to identify exactly where an activity will take place and understand environmental constraints around it. Current permit guidance already directs users towards Multi-Agency Geographic Information for the Countryside (MAGIC) for this purpose.
• Farming land parcels: let farmers identify or select the individual fields and parcels that make up their holding.
• Agricultural schemes: show which pieces of land are included in Sustainable Farming Incentive, Countryside Stewardship, or other environmental land management agreements.
• Applying for farming payments: allow somebody to select a field, woodland, hedge, pond, or other feature when applying for a scheme.
• Land eligibility: visually explain why part of a field is eligible or ineligible for a particular payment or environmental action.
• Water quality: show the ecological or chemical status of rivers, lakes, groundwater, and coastal waters.
• And plenty more: These are just a few examples of where interactive maps can help users navigate environmental and rural matters.

All of these sound like perfectly legitimate reasons to use an interactive map in a service. And importantly, they cover both government administration, such as civil servants managing land, and citizen-facing services, such as farmers applying for schemes.

I mention this component because it uses React to render its interactive maps. This kind of rich interaction requires JavaScript, and a frontend framework can make building and maintaining that complexity easier.

And there you have it: a legitimate reason to use a frontend framework in a UK government service. Not because it is fashionable or familiar, but because it solves a genuine problem, meets a real user need, and ultimately makes the service better for the people using it.

Progressive enhancement without a framework

All the examples in this post share the same progressive enhancement principles:

• The core journey works without JavaScript: Users can navigate through the service, complete forms, submit information, receive validation errors, and complete the journey using server-rendered HTML alone. JavaScript is an enhancement, not a requirement.
• GOV.UK Frontend JavaScript enhances components only where it is needed: Components such as accordions, character counts, and notification banners can gain additional behaviour when JavaScript is available, but the underlying content and core journey remain usable without it.
• The backend language makes no difference to the progressive enhancement model: Whether the HTML is generated using TypeScript, Java, C#, Python, PHP, Ruby, Go, or Rust, the browser ultimately receives the same thing: HTML, CSS, and a relatively small amount of progressively enhancing JavaScript. Progressive enhancement is an architectural approach, not something tied to a particular backend language or framework.
• Server-rendered HTML makes the service incredibly resilient: The browser receives usable HTML directly from the server, so it does not need JavaScript to construct the page before the user can interact with it. If JavaScript fails to download, is blocked, contains an error, or simply does not run, the core service journey will continue to work. The enhancements may disappear, but the service itself does not.
• GOV.UK Frontend provides a strong accessibility foundation: By maintaining HTML parity with the official GOV.UK Frontend components, each implementation benefits from the accessibility work already carried out by the GOV.UK Design System team. The components are designed and tested with accessibility in mind, including the WCAG 2.2 requirements that government services are legally required to meet.

As for the last point, this takes a significant amount of work away from individual service teams, but it does not make the finished service automatically accessible. You can take perfectly accessible components and put them together in inaccessible ways! Teams still need to test the HTML produced by their backend, the overall page structure, content, validation, focus behaviour, user journeys, and any custom components or JavaScript.

GOV.UK Frontend provides an excellent foundation for accessibility, but ensuring the entire end-to-end user journey is accessible remains the responsibility of the service team.

Teaching the AI about UK government services

If you hadn’t guessed already, I used AI to build these 8 near-identical services using the different backend languages. The methodology I used was to first create a “template repository”. This template acted as the shared source of truth for all the other examples. It defines the common contracts, baseline, styles, documentation, and agent skills that can be kept in sync across each implementation. Each individual language repository is free to render GOV.UK Frontend in the way that makes the most sense for the specific language, while still matching the same Frontend macros, fixtures, and operational baseline.

The key part of this template is the training and context I gave the AI before any code was even written. When coding with AI, you need to clearly explain what you want to achieve, how you want it done, and the rules it should follow. Without that context, it has an infinite number of possible approaches to choose from, and it will simply make decisions for you, these decisions are very frequently not the ones you would have made!

You could include all of this context in every prompt, but that quickly becomes repetitive and unmanageable. This is where AGENTS.md and Agent Skills become incredibly useful. Think of them as a shared, long-term set of instructions containing the rules, dos and don'ts, conventions, and important context the AI needs whenever it works on the codebase.

This is where building UK government services with AI has a distinct advantage over other sectors, and even other governments around the world. Over the years, GDS and the wider government community have produced a huge amount of guidance on how good public services should be designed, built, tested, and operated.

More importantly, that guidance is incredibly diverse. It does not just cover technology and writing code. The same problem is often considered from multiple perspectives, including accessibility, inclusive design, user research, content design, security, performance, and operating a service in the real world.

This gives AI something particularly valuable: not just instructions on how to build a government service, but the context behind why it should be built that way. If the AI understands why progressive enhancement matters, why accessibility cannot be an afterthought, and why services need to work for people with different devices, connections, skills, and circumstances, it has much better context for making sensible decisions. When there is no explicit instruction telling it exactly what to do.

In other words, we are not just giving the AI a set of technical rules to follow. We can give it decades of accumulated knowledge about what a good government service actually looks like, drawn from a diverse range of experiences, disciplines, and perspectives.

AI Training

So, how exactly do you train an AI? Well, it’s a lot simpler than it sounds! For example, the resources I used for the templates AGENTS.md file are as follows:

1. Design System homepage
2. GOV.UK Frontend Roadmap
3. GOV.UK Design System: Discuss styles, components, and patterns
4. GOV.UK Design System cycle board
5. GOV.UK Frontend Releases
6. Service standard homepage
7. Service Manual homepage
8. Service assessments and applying the Service Standard
9. The Technology Code of Practice
10. Understanding accessibility requirements for public sector bodies
11. GOV.UK Frontend Documentation
12. Test if your HTML matches GOV.UK Frontend
13. Building a robust frontend using progressive enhancement
14. Artificial Intelligence Playbook for the UK Government (HTML)

Those are the main ones, but if I were working within a particular department, I’d also include their internal guidance too.

That last link (14) is wonderfully meta: government guidance telling the AI how to use government guidance to build better government services. We may have reached peak guidance!

Hopefully, you can see how diverse the data I’m giving the AI is. Yes, there’s a lot of technical data there, but there’s also more general information sources about the why’s and how’s of why frontends are built the way they are. Furthermore, some decision histories related to GDS guidance and frontends. Now that I have a list of resources I want to train it on, I simply give my AI agent a prompt such as:

Take all the links below and research them thoroughly, including relevant pages, guidance, standards, and documentation they link to.

Use this research to create a comprehensive but succinct AGENTS.md file that provides an AI coding agent with the context it needs to build high-quality UK government services.

Do not simply summarise each source. Instead, synthesise the guidance into a coherent set of principles, rules, constraints, and recommended approaches that an agent can apply when making implementation decisions.

The AGENTS.md file should:

* Explain what an agent should do, but also why the guidance exists, particularly where it relates to user needs, accessibility, inclusion, progressive enhancement, performance, security, resilience, and maintainability.
* Combine technical and non-technical guidance so that implementation decisions are informed by the wider principles of designing and delivering UK government services.
* Consider different perspectives on the same problem, including user experience, design, accessibility, engineering, content, security, operations, and service delivery.
* Distinguish between requirements, strong recommendations, and contextual guidance.
* Prefer official and authoritative UK government guidance where sources overlap or conflict.
* Preserve important nuance and exceptions rather than turning guidance into absolute rules where none exist.
* Translate guidance into practical instructions that an AI coding agent can follow while designing, generating, reviewing, refactoring, and testing code.
* Include enough context for the agent to make sensible decisions when it encounters situations that are not explicitly covered.
* Avoid unnecessary duplication, lengthy quotations, and generic software engineering advice that is not relevant to building UK government services.
* Structure the file so that important instructions are easy for an AI agent to locate and apply.

The final AGENTS.md should act as a practical decision-making guide, not simply a summary of the source material. Its purpose is to help an AI coding agent understand the standards, principles, constraints, and reasoning behind how good UK government services should be built.

Sources:

[INSERT LINKS HERE]

If you are wondering what the resulting AGENTS.md file looks like you can find it in a Gist here (opens in new tab).

By doing this, I’m taking decades of GDS and other departmental expertise, contributed by countless talented and dedicated civil servants, and squeezing it into a single AGENTS.md file for the AI to reference. All that knowledge and experience, condensed into a humble Markdown file. What a time to be alive! I am indeed, kneeling on the shoulders of giants!

Now, this next point is particularly important: you don't need to write the AGENTS.md file yourself. In fact, I'd strongly recommend that you don't.

Instead, give the AI the relevant guidance, documentation, and context, and let it generate the file for you. That way, it can bring together decades of knowledge from a diverse range of sources and structure the instructions in a way that makes them useful for future prompts. Your responsibility is to review, challenge, and refine what it produces, not blindly accept it.

And yes, I realise this is starting to sound like Inception. AI writing instructions for AI to follow when writing more AI-generated code. We're only a few layers away from needing a totem (spinning top)!

The use of an AGENTS.md is slowly becoming the de facto standard, some other tools like Claude have their own versions. You can repoint Claude to reference the AGENTS.md file by creating a CLAUDE.md file and adding the following:

# Project Instructions

All project instructions, coding standards, architectural decisions, and development guidelines are maintained in [AGENTS.md](./AGENTS.md).

Read and follow `AGENTS.md` before making any changes to this project. Treat its instructions as authoritative and do not duplicate them here.

[Claude-specific instructions here]

If you do happen to have Claude-specific instructions you can keep those in the file too.

MDC files

Speaking of AI-specific instruction files, this brings me on to Cursor AI and the files it uses in addition to the standard AGENTS.md file. Cursor had its own file format called Markdown Cursor (*.mdc), it uses these files for additional prompt context. These files are both human and AI readable since it’s only Markdown after all, but cursor keeps them in a .cursor directory in the project root. They are just like standard Markdown files only they start with some YAML frontmatter. What I tend to do in my projects is to have the bulk of the context in the AGENTS.md, and then use mdc files for very specific other tasks or skills. I can give you an example of a mdc instruction on this blog.

I use Cloudflare Pages to host my blog, which supports various build frameworks and build images with different versions of Node.js, Go, Python, and other tools.

I've never had much luck overriding the default Node.js version, which has occasionally caused builds to fail when updated dependencies require a newer version. So, I got Cursor to create an .mdc rule that checks a dependency's Node.js requirements before upgrading it. If it needs anything newer than the build image's Node.js v22.16.0, Cursor simply skips the upgrade.

A rather simple solution that's saved me a few broken builds! A link to an example file that applies the above rule can be found here: cloudflare-node-compatibility.mdc (opens in new tab).

Using Markdown Cursor (.mdc) and AGENTS.md files gives you a powerful way to guide AI agents, constrain implementation decisions, and encourage better engineering practices. The result? Code that’s considered, maintainable, and actually works, rather than yet another steaming pile of AI-generated slop!

If you are interested in the language-specific mdc files I used to create the 8 backend examples in this post, I've added links to them in the Eight backends, one GOV.UK Frontend section earlier in the post, but you can also find them all here too:

• TypeScript + Node
• Go
• Java
• C# and .NET
• Python
• PHP
• Ruby
• Rust

A warning about the demos

All eight examples are hosted on Render.com using its free hosting tier. The downside? Free services spin down after a period of inactivity, meaning the first request has to wake everything up again. This is known as a cold start and can take around 50 seconds, so please be patient! Once running, subsequent requests are much faster. Importantly, this delay is entirely down to the free hosting environment and isn't representative of the performance of the languages or frameworks being demonstrated. It also means you shouldn't use the initial loading time to compare their performance!

A warning about the repositories

All eight repositories are intended as demonstrations, not production-ready starter projects. They're also not actively maintained, so dependencies will inevitably become outdated over time.

You’re more than welcome to fork them, experiment, and adapt them to your needs, but please don’t blindly deploy them into production! Think of them as little sourdough starters for government services. They’re a good starting point, and with a little bit of care, regular feeding, and ongoing maintenance, they could grow into something capable of supporting a real UK government service.

What does the experiment actually prove?

Eight very different backend languages and frameworks, all using the same GOV.UK Frontend, producing the same HTML, following the same accessibility requirements, and applying the same progressive enhancement principles. Most importantly, none of them needed an application-level frontend framework like React, Angular, Vue, Svelte or any other client-side framework to achieve this.

What does this tell us? GOV.UK Frontend doesn’t dictate which backend technology you should use. You can build accessible, progressively enhanced government services using a wide variety of languages and frameworks. Ultimately, the choice of backend should come down to the needs of the service, the skills of your team, and your organisation’s technology strategy, not an assumption that you need a particular technology to use GOV.UK Frontend.

Choose your backend for the right reasons

If there’s one message I hope readers take away from this blog post, it’s that choosing the right backend technology genuinely matters, especially for government services. Once a service goes live and people depend on it, replacing or decommissioning it can be incredibly difficult. Some government services run for years, even decades!

It’s also worth remembering that the developers who build a service today are highly unlikely to be the ones maintaining it in five, ten, or even twenty years time. Someone else will inherit the code, along with the bug fixes, security patches, maintenance, and new feature requests. That’s why selecting a backend shouldn’t come down to personal preference or whichever technology happens to be popular at the time. It’s a long-term commitment, and changing that decision later could mean a costly and complicated rewrite. So costly in fact, GDS have multiple streams of work ongoing to try to tackle legacy Systems, details of these work-streams I have given below for readers who are interested:

A Roadmap for Modern Digital Government published January 2026

Published in January 2026 it is the main cross-government strategy currently being implemented. You can find Modern Digital Government guidance here.

Upgrading Outdated Legacy Systems in Key Public Services (2026)

In these plans also published in 2026, GDS outlines specific legacy modernisation projects taking place across government. Some departments included in the report are: Department for Work and Pensions (DWP), DEFRA, and the Home Office. You can find the Upgrading Outdated Legacy Systems in Key Public Services report here.

Understanding Our Digital Systems to Improve Them (2026)

This document describes how GDS intends to coordinate legacy technology management across government. You can read about these technology assessment plans here.

Updated Definition of Legacy IT (August 2026)

This is one of the most interesting recent publications, particularly when discussing technology choices, it was published in August 2026, and it changes how government defines legacy technology. It really is a fascinating read which I have linked to here: Updated Definition of Legacy IT.

Off the back of that report, it’s worth remembering that what’s considered modern today can quickly become tomorrow’s legacy system, and if there’s one thing government is fantastic at, it’s keeping legacy systems running long after everyone who originally built them has moved on! So spare a thought for the poor developers and service teams who might inherit your decisions in 10 or 20 years.

Rather than choosing TypeScript over Java because it’s “better”, more “modern”, or simply because you prefer it, we should be asking some far more practical questions. And this applies to any combination of the eight backends examined:

• What skills are already available within the organisation?
• What infrastructure is already in place?
• How mature are the organisation’s operational processes?
• What security tools and processes are already established?
• How easily can the code be maintained?
• How easy will it be to recruit developers with the necessary skills?
• What are the actual performance requirements of the service?
• What technologies are already used by existing services?
• Who will maintain and support the service in the long term?

The crucial point is to choose the backend that makes the most sense for the organisation and the service. As we’ve seen, GOV.UK Frontend doesn’t dictate that decision for us. As long as the generated HTML matches the official GOV.UK Frontend test fixtures, you’re well on your way to building a frontend that follows GDS standards and guidance.

GOV.UK Frontend is backend agnostic

As you’ve probably gathered by now, GOV.UK Frontend is completely backend-agnostic. Any backend capable of serving static assets and generating accurate HTML can use it. GOV.UK Frontend doesn’t know or care what technology is generating its HTML, and neither does the browser. All a browser needs is semantic, accessible HTML, CSS, and a little JavaScript for progressive enhancement.

Whichever backend you choose, it needs to work for your organisation and department, but above all else, it needs to work for the people who actually use the service.

And that’s really what this entire experiment has been about. It wasn’t simply an exercise in building the same government service eight different ways, although I’ve certainly spent enough time doing exactly that! It was about demonstrating that the choice of backend technology doesn’t need to dictate how we build the frontend. Nor does it prevent us from taking advantage of the years of research, testing, and expertise that have gone into the GOV.UK Design System.

Treat the HTML as the contract, test it against the GOV.UK Frontend fixtures, progressively enhance where there’s a genuine user need, and select the backend technology that makes the most sense for your service and department.

And that brings us back to the point I made at the beginning of this experiment:

GOV.UK Frontend doesn’t care whether your HTML is generated by Node.js, Go, Java, .NET, Python, PHP, Ruby, or Rust. Neither does the browser.

Summary

So, after building the same fictional government service eight different ways, what have we actually learned? Apart from the fact that I’ve probably spent far too much of my spare time generating HTML for fishing rod licences!

Well, hopefully quite a lot.

We’ve demonstrated that eight very different backend technologies can produce the same GOV.UK Frontend components, follow the same progressive enhancement principles, and deliver the same user experience without needing React, Angular, Vue, Svelte, or any other client-side framework.

We’ve also seen that while some backend technologies make integrating and maintaining GOV.UK Frontend easier than others, none of them fundamentally changes what the browser receives. The HTML is the contract, and the official GOV.UK Frontend test fixtures give us a reliable way to verify that contract, regardless of how the HTML was generated.

But I think there’s a much larger point here.

The GOV.UK Design System represents years of research, accessibility testing, collaboration, and experience from people across government. By building on that shared foundation, service teams can spend less time reinventing frontend components and more time solving the problems their users actually have.

When choosing technology, we must consider the users who rely on the service today, the developers who maintain it tomorrow, and the organisation responsible for keeping it running for years to come.

Frontend frameworks aren’t inherently bad, and there will always be legitimate reasons to use them. But those reasons should come from genuine user needs, not personal preferences, familiarity, or simply because that’s how we’ve always built things.

Start with user needs. Choose the simplest architecture that meets them. Treat HTML as the contract. Progressively enhance where it adds value. And make technology decisions that future developers won’t despise you for.

After all, the goal was never to build eight different frontends. It was to demonstrate that we don’t need eight different approaches to delivering the same accessible, consistent user experience.

Eight backends. One GOV.UK Frontend. Zero frontend frameworks required.

And hopefully, one less unnecessary technology decision for the next government service team to make 🤞

The end! Thanks so much for reading another one of my incredibly long blog posts! One day, I’ll manage to write more succinctly, I promise! As always feedback, corrections, and comments and more than welcome, just let me know!

P.S. Remember the question I asked right at the start? Do you need a frontend framework to build a modern UK government service?

No. You really don’t.

Post changelog:

• 15/10/26: Initial post published.