The 2021 Frontend survey asks additional questions in a different order from the previous surveys, 2016 and 2018. For this survey, we are not interested in prototyping projects and those responses are not included in the results.
Respondents can skip any question and where users do skip, it's recorded as 'No answer'.
Question 1: Thinking about your current project, how would you describe it? If you work on more than one project, pick the one you spend the most time on. Keep this project in mind for the rest of the survey.
| Name | Count | Percentage |
|---|---|---|
| Live service/website | 34 | 61.82% |
| Service/website that will go live in the future | 20 | 36.36% |
| Design system across department | 1 | 1.82% |
| Name | Count | Percentage |
|---|---|---|
| Public-facing transactional service | 20 | 36.36% |
| Public-facing website | 10 | 18.18% |
| Case working system | 8 | 14.55% |
| Internal transactional service | 8 | 14.55% |
| Internal website | 2 | 3.64% |
| A platform other services use to send emails, sms messages, letters and now emergency alerts. | 1 | 1.82% |
| Currently internal with public facing parts in the roadmap. | 1 | 1.82% |
| Dept to business service - for use by educational institutions. | 1 | 1.82% |
| Has a public facing section but is mostly 'internal' for use by providers of legal services | 1 | 1.82% |
| NHS digital service for NHS clinicians | 1 | 1.82% |
| Publicly available but intended to be used by department | 1 | 1.82% |
| Register with publicly facing external web applications & internal web applications. | 1 | 1.82% |
| Name | Count | Percentage |
|---|---|---|
| Cabinet Office (inc GDS) | 7 | 12.73% |
| DWP | 6 | 10.91% |
| MOJ | 5 | 9.09% |
| Home Office | 5 | 9.09% |
| NHS | 5 | 9.09% |
| HMRC | 3 | 5.45% |
| DfT (DVLA, DVSA) | 4 | 7.27% |
| The National Archives | 4 | 7.27% |
| DfE / ESFA | 4 | 7.27% |
| DIT | 2 | 3.64% |
| DEFRA | 2 | 3.64% |
| Local authority | 2 | 3.64% |
| OFGEM | 1 | 1.82% |
| Solicitors Regulation Authority | 1 | 1.82% |
| CQC | 1 | 1.82% |
| UKHO | 1 | 1.82% |
| BEIS and DCMS | 1 | 1.82% |
| Not Government | 1 | 1.82% |
| Name | Count | Percentage |
|---|---|---|
| Frontend development | 26 | 47.27% |
| Full stack development | 16 | 29.09% |
| Design | 5 | 9.09% |
| Backend development | 2 | 3.64% |
| Content | 1 | 1.82% |
| Product Manager | 1 | 1.82% |
| Product Owner | 1 | 1.82% |
| Project management | 1 | 1.82% |
| SRE | 1 | 1.82% |
| Technical Architect | 1 | 1.82% |
Question 5: If you're happy to share it, tell us the code repository URL(s) for your project. Getting to see your repository can help us understand how frontend technologies are used in your project.
Answers are not shared.
| Name | Count | Percentage |
|---|---|---|
| Node.js | 18 | 32.73% |
| Ruby on Rails | 13 | 23.64% |
| React | 13 | 23.64% |
| .NET / C# | 5 | 9.09% |
| Python | 4 | 7.27% |
| Angular | 3 | 5.45% |
| Scala and Play | 3 | 5.45% |
| Next.js | 2 | 3.64% |
| Java | 1 | 1.82% |
| PHP | 1 | 1.82% |
| jQuery | 1 | 1.82% |
| Go | 1 | 1.82% |
| MS Powerapp | 1 | 1.82% |
| Do not know | 1 | 1.82% |
| No frameworks | 1 | 1.82% |
| Name | Count | Percentage |
|---|---|---|
| React | 12 | 23.64% |
| Nunjucks | 11 | 21.82% |
| ERB | 7 | 12.73% |
| haml | 3 | 5.45% |
| Razor | 3 | 5.45% |
| Twirl | 3 | 5.45% |
| Django templates | 2 | 3.64% |
| Jinja | 2 | 3.64% |
| Angular | 1 | 1.82% |
| ASP.NET Razor Pages | 1 | 1.82% |
| C# | 1 | 1.82% |
| Vue.js | 1 | 1.82% |
| Ruby "helpers" with HAML | 1 | 1.82% |
| Slim | 1 | 1.82% |
| Twig | 1 | 1.82% |
| None | 1 | 1.82% |
| I do not know | 4 | 7.27% |
Question 8 and 9: Does your project need to support any legacy or non-standard browsers? These are usually browsers not included in the list of browsers to test in in the Service Manual. How long do you plan to continue supporting any legacy or non-standard browsers?
| Name | Count | Percentage | How long? |
|---|---|---|---|
| Internet Explorer 8 | 3 | 5.45% | 33% no decision 67% continue for now |
| Internet Explorer 9 | 6 | 10.91% | 16.7% up to 12 months 50% no decision 33% continue for now |
| Internet Explorer 10 | 9 | 16.36% | 11% up to 12 months 56% no decision 33% continue for now |
| Internet Explorer 11 | 23 | 41.82% | 4% up to 6 months 9% up to 12 months 44% no decision 35% continue for now |
| No, our project only needs to support browsers listed in the Service Manual | 25 | 45.45% | N/A |
| I do not know | 9 | 16.36% | N/A |
| unclear | 1 | 1.82% | N/A |
Question 10: Could you explain why you've decided to support the legacy or non-standard browsers for the time being?
Answers are summarised
- Staff still uses Internet Explorer.
- Support browser our internal agents uses
- Support as many users as possible.
- Old system still relies on older technologies, although support is functional rather than full compliance
- Use-statistics shows hundreds of thousands still uses IE11
- Users can only access system through IE due to group policy
- Support whatever is listed on the GDS website
Question 11: What frontend resources from government or public sector does your project use? We'd like to hear about frontend resources other than those offered by GDS. This can include departmental design systems or departmental frameworks.
| Name | Count | Percentage |
|---|---|---|
| GOV.UK Design System (GOV.UK Frontend) | 45 | 81.82% |
| GOV.UK Prototype Kit | 19 | 34.55% |
| GOV.UK Design System Community resource | 10 | 18.18% |
| GOV.UK Frontend Toolkit | 10 | 18.18% |
| GOV.UK Elements | 5 | 9.09% |
| GOV.UK Template | 5 | 9.09% |
| NHS Design System (NHS Frontend) | 4 | 7.27% |
| govuk-react | 2 | 3.64% |
| HMRC Design System (HMRC Frontend) | 2 | 3.64% |
| MOJ Pattern Library (an extension of the GOV.UK Design System) | 2 | 3.64% |
| GOVUK publishing components | 1 | 1.82% |
| Hackney Design System | 1 | 1.82% |
| None | 4 | 7.27% |
| Don't know | 2 | 3.64% |
Answer are categorised
| Name | Count | Percentage |
|---|---|---|
| npm | 22 | 40.00% |
| Manually | 1 | 1.82% |
| Gulp | 1 | 1.82% |
| We don't | 1 | 1.82% |
| Departmental resource | 3 | 5.45% |
| Gem | 2 | 3.64% |
| Webpack | 2 | 3.64% |
| Other | 2 | 3.64% |
| Package manager | 1 | 1.82% |
| NuGet | 1 | 1.82% |
| No answer | 19 | 34.55% |
Answer are categorised
| Name | Count | Percentage |
|---|---|---|
| npm | 11 | 20.00% |
| Dependency notification service (e.g Dependabot) | 9 | 16.36% |
| CI/CD pipeline | 5 | 9.09% |
| Manually | 4 | 7.27% |
| Watch for changes | 2 | 3.64% |
| Rarely | 2 | 3.64% |
| Bundler | 1 | 1.82% |
| With difficulty | 1 | 1.82% |
| Not sure | 1 | 1.82% |
| No answer | 19 | 34.55% |
Question 14: Does your project use any automated accessibility or performance testing tools? List any tools that you find useful in your project.
| Name | Count | Percentage |
|---|---|---|
| aXe | 18 | 32.73% |
| Lighthouse | 8 | 14.55% |
| Cypress | 4 | 7.27% |
| Wave | 3 | 5.45% |
| Cucumber | 3 | 5.45% |
| Speed Curve | 3 | 5.45% |
| SiteImprove | 1 | 1.82% |
| Firefox Accessibility Inspector | 1 | 1.82% |
| Webpack bundle checkers | 1 | 1.82% |
| JavaScript tests | 1 | 1.82% |
| Not sure | 2 | 3.64% |
| No | 9 | 16.36% |
| No Answer | 17 | 30.91% |
| Name | Count | Percentage |
|---|---|---|
| Sass | 40 | 72.73% |
| We don't use a pre-processor | 4 | 7.27% |
| Less | 2 | 3.64% |
| PostCSS | 1 | 1.82% |
| SCSS | 1 | 1.82% |
| We don't write our own styles | 1 | 1.82% |
| I do not know | 7 | 12.73% |
| Name | Count | Percentage |
|---|---|---|
| Dart Sass | 12 | 21.82% |
| LibSass (including node-sass) | 7 | 12.73% |
| Ruby Sass | 4 | 7.27% |
| gulp-sass | 1 | 1.82% |
| Multiple | 1 | 1.82% |
| I do not know | 12 | 21.82% |
| No answer | 18 | 32.73% |
Question 17 and 18: Ruby Sass and Lib Sass (including node-sass) are deprecated. Do you have any plans to migrate to Dart Sass? Can you explain why you haven't made any plans to migrate to Dart Sass?
| Name | Count | Explanation (Q18) |
|---|---|---|
| I did not know that they were deprecated | 2 | - |
| Once our webpack update is done. | 1 | - |
| We do not have any plans to migrate for now | 5 | Budget Not project critical Time and effort At the moment there are higher priority things to do. |
| Yes, in the next 12 months | 1 | - |
| Yes, in the next 3 months | 1 | It was seen as a low priority for us |
No answers for question 19.
| Name | Count | Percentage |
|---|---|---|
| BEM | 22 | 40.00% |
| ITCSS | 3 | 5.45% |
| CSS-in-JS | 2 | 3.64% |
| SMACCS | 1 | 1.82% |
| We don't write our own styles | 4 | 7.27% |
| We don't follow a CSS architecture | 12 | 21.82% |
| Don't know | 9 | 16.36% |
| No Answer | 2 | 3.64% |
Question 21: How do you write JavaScript in your project? This is how you write JavaScript in the developer environment (before it might get transformed or transpiled).
| Name | Count | Percentage |
|---|---|---|
| ECMAScript 2015 (ES6) or later | 38 | 69.09% |
| ECMAScript 3 (ES3) | 7 | 12.73% |
| We don't write our own JavaScript | 1 | 1.82% |
| I do not know | 9 | 16.36% |
| Name | Count | Percentage |
|---|---|---|
| Webpack | 24 | 43.64% |
| Babel | 15 | 27.27% |
| Typescript | 12 | 21.82% |
| Rollup | 4 | 7.27% |
| Gulp | 3 | 5.45% |
| Browserify | 1 | 1.82% |
| BuildBundlerMinifier | 1 | 1.82% |
| Grunt | 1 | 1.82% |
| We do not use JavaScript on this project | 2 | 3.64% |
| None | 8 | 14.55% |
| I do not know | 10 | 18.18% |
Question 23: If you transform or transpile your JavaScript to another format for production environment, can you tell us what the format is?
Answers are summarised
- ES5
- @babel/preset-env
- Minification
- ES6 with babel where we need older browser support
- TypeScript
- Use rollup to package javascript in the cjs format
Question 24: Describe how your project, on average, uses JavaScript? (Project can choose multiple options)
| Name | Count | Percentage |
|---|---|---|
| We write JavaScript to create our own components | 30 | 54.55% |
| We bring in JavaScript components and/or functionality from elsewhere and write JavaScript to initialise them and connect them to our project | 26 | 47.27% |
| We write substantial JavaScript to modify how components and/or functionality brought in from elsewhere work | 15 | 27.27% |
| We use JavaScript to create all or part of our user interface | 14 | 25.45% |
| We don't use any or use very little JavaScript on our project | 12 | 21.82% |
| We use JavaScript on the client side to handle page level interactions such as routing of pages | 11 | 20.00% |
| We use JavaScript to manage tooling and/or deployments | 10 | 18.18% |
| I do not know | 7 | 12.73% |
Answers are summarised
- Use Node, so JS is server-side
- Use as little as possible
- Typescript not JS
- Trying to achieve smaller micro-frontend apps that render server side and bring in a minimal of progressively enhanced JS components
- Reducing client side JS and custom JS from inherited project
- Use default GOV.UK / department's design system
- JS approached based on progressive enhancement
- JS is required for UI elements (filter, auto complete) to work well
- Bespoke components (dynamic search and table select/sort)
- Modified existing component using JS
- Follow govuk-frontend convention
- Use Javascript for the orchestration of micro-frontends
- Use Javascript to prevent auto-suggesting previous answers
- Use a combination of JavaScript on the client side and Python on the server-side to update parts of our pages, through AJAX calls to Python endpoints.
- Currently use very little JS. If we didn't have to support users without JavaScript, we would switch to using SPAs and use the same generators as our internal apps.
- Use JavaScript to call various APIs on the client-side, such as webauth and websharing
- A specific page only works with JavaScript, it needs to extract client-side metadata (file path, last modified date, calculated checksum) from files being uploaded
| Name | Count | Percentage |
|---|---|---|
| We test that users can still complete all the tasks without JavaScript | 23 | 41.82% |
| We don't test how the project works if JavaScript does not load | 7 | 12.73% |
| We test that users can still complete all the tasks, but we know that the user experience will be substantially different | 7 | 12.73% |
| We test without JavaScript, but we know that, if JavaScript does not load, it might make it harder for users to complete some tasks | 6 | 10.91% |
| We don't use any JavaScript on this project | 1 | 1.82% |
| I do not know | 10 | 18.18% |
| No Answer | 1 | 1.82% |
Answers are summarised
- Does not function without javascript
- Fallback for autocompletes means searching is harder
- Mostly the same
- Designed to work without JavaScript
- Aim for progressively enhance experience, but some parts of the interface are slow
- Let the user know when it is necessary to enable JS to complete a task
- Everything is server side generated
- Doesn't work well. It causes significantly more work for a tiny portion of people who disable js.
- Team isn't concerned, internal project so it doesn't matter
- All pages tested to work without JavaScript
Question 26: Can you explain how the user experience on your project will be substantially different if JavaScript does not load?
Answers are summarised
- Some features wouldn't work - word counts, client side validations, redirect after a download to sign out of service,
- Backlink will hide
- Service wouldn't work
- Users cannot complete the task
- Requests are initiated from forms and links in the fallback state, rather than immediately via buttons. Build extra pages to handle states that would normally be moved to the same page.
- Will not look as nice stylistically
- Users will struggle to navigate themselves around many/most websites in circulation.
Question 27: Can you explain what tasks on your project might be harder for users to complete if JavaScript does not load?
- We do an ajax lookup with an autocomplete to search for schools - a set of ~30k entries. For js this works very nicely and is quick. For non-js we revert to an input and results page to pick from.
- Sorting tables, filtering, general layout, authentication via Microsoft ADB2C
- Maps will be missing
- Search / Filter features will be harder. Transactional journeys that rely on endpoints will be impossible to use
- The application contains a lot of "tables" of cases for caseworkers with filters, and autocompleting fields on forms. Without JS this functionality is lost so it becomes more difficult to use the application.
- Uploading files, because that specific task requires client-side JavaScript to extract client-side metadata
Question 28: Are there any specific improvements you'd like to see in the frontend resources offered by GDS?
Answers are summarised
- more templating languages, Django, react, Angular
- better documentation
- more examples
- more components and patterns
- More complex components, e.g search, tables with sort/filter
- Patterns and components to help internal users manage large numbers of entities, e.g. interacting with tables of data and modifying multiple items at once.
- Support for non-public facing services
- Support single page application (SPA) - guidelines dedicated to the dynamic aspects and much richer set of components and concepts used in SPAs.
- better JavaScript
- a clear contribution model
- Class for hiding/showing depending on whether JS loads or not.
- Support for Welsh
- Utility classes and macros
- Mobile as the preferred method of government services
- More help and guidance
- Remove requirement for services to work with JS off
- Highlight accessibility or performance considerations
- guidance to build resilient SSR application
- Support CSS-in-JS
- Schema based form generation framework, so we can define a question schema, generate templates from it, record the answers in a schema and then later cross reference questions and answers in a structured way.
- accessibility acceptance criteria
- Raise a11y issues as bugs on repos
- Unbundled .js source
- Testing guidance
- provided non transpilled non-polyfilled JS modules for components via npm
- Continued improvement
- Docker auto-refresh
- Nothing else right now