Results of the 2024 Wagtail headless survey
The results of the 2024 Wagtail headless survey are here! There are plenty of expected results plus a few surprises.
Late last year, we ran a survey of people who build headless sites with Wagtail, or are considering developing a headless site with Wagtail. It’s a follow-up to our 2022 Wagtail headless survey. We’ll use those survey results to inform Wagtail’s direction as part of RFC 100: Headless support improvements.
46 people responded (thank you!), compared to 29 in 2022 – here are the key results.
Survey results
How often developers work on headless Wagtail
There is a big jump between 2024 and 2022 results, with people reporting that “Most work is on headless” going from 24% to 46%. We expect this is a combination of headless architectures gaining popularity, and the survey being targeted more towards people who choose this type of stack.
Using Wagtail in headless mode is particularly popular for larger projects, where the CMS might only be one of many services providing content or data for the site or app’s pages.
Deployment of headless websites
There is a clear pattern here, with “Same as CMS” leading at 66%, followed by Other at 25%, Vercel at 18%, and Netlify at 7%. The overall breadth of platforms is likely as big as shown in our deployment survey.
Familiar front-end tools for Wagtail developers
React and Next.js are still the most commonly known tools. There is a small dip in Vue and Nuxt usage, though this could be down to the survey’s small sample size. Astro usage is taking off! Introduced in 2023, there are currently on the order of 30,000 websites built with the framework according to Wappalyzer.
Frameworks for future projects
Similar trends are reflected in what developers say they would consider using for future projects, here with Astro on par with more established options like Nuxt or Remix. For Wagtail, knowing what developers are interested in will help us decide what technologies to use in tutorials or demo sites.
Front-end rendering
While a lot of modern front-end frameworks make the line between static and dynamic rendering blurrier, it’s interesting to see the distribution in practice! We will want to consider how Wagtail could support each and every one of those use cases.
Integration method with the backend
REST is as popular as ever, whether with Wagtail’s built-in Django REST Framework support, or a custom integration to leverage OpenAPI schemas, or Django Ninja. The question wording of "When building headless sites, which method of integration would you consider?" makes it clear multiple answers are ok, so it’s interesting to see so many people considering both REST and GraphQL.
And for the one person using Elasticsearch for this – you’re not alone! Though they might not be in our survey respondents, there are a reasonable number of websites sharing Wagtail and Django solely via a search backend.
The future: priority areas to improve headless support in Wagtail
This list is a good overview of all the options for us to improve headless support – and the voting really helps making it clear what gaps Wagtail developers think are worth addressing. In addition to this quantitative data, we also got some great feedback in individual comments:
- Reduce the need for custom serializers
- Support generation of OpenAPI specifications for documentation, and to generate TypeScript type definitions
- Consider how to supprot Django Ninja
- The documentation needs more examples – say StreamField blocks in GraphQL.
- HTMX support – where does this get factored in.
- An official JS client API like wagtail-js?
As part of RFC 100: Headless support improvements, we hope to create a solid overview of all possible improvements, and make it clear which ones are ready for people to contribute to. And in the meantime, if you’re considering headless Wagtail – take a look at our headless developer docs, and our overview of headless Wagtail!