Here are a few key things to understand if you'd like to help with the Devographics surveys (State of JS, State of CSS, etc.)
Code
The surveys run on an entirely custom stack consisting of four main sub-apps that live inside a pnpm monorepo:
Config Files
In addition to that, there are a few other repos that hold config/content files:
Useful Ressources
Areas of Improvement
Here's some of the things I'd like to improve over the next months.
Onboarding
Because the apps all require various environment variables and need to connect to a database, cache, etc. running them locally isn't very straightforward. It would be nice to improve this via better docs, offline/local fallbacks, or other strategies.
Surveyform Migration
The surveyform app currently leverages a lot of Next.js advanced patterns such as SSR, partial rendering, RSCs, etc. but given that its content does not need to be indexed or shared it seems like it could function just as well as a client-side SPA.
Migrating to an SPA-first framework such as TanStack Start (or even staying with Next.js) could be a chance to simplify the codebase while also making the app easier to host on a standard server, without having to rely on Vercel's serverless or edge features.
Results Migration
The results app currently uses Gatsby, which is no longer under active development. It could be migrated to a more modern platform such as Astro or some other platform capable of rendering static React apps. Some considerations:
Note: Gatsby's ability to generate a static site that can also behave as an SPA once loaded (no loading in-between pages) is nice; not sure if Astro supports that as well?
Translation Infrastructure
There is no mechanism in place currently to notify volunteer translators when a string is added or changed and needs translation. It would be nice to have something that can batch those tasks and then publish them as GitHub issues in all the different locale repos.
TypeScript Maintenance
Some parts of the codebase are still written in JavaScript; others are in TypeScript but with many type errors. It would be nice to harmonize this a bit more.
Testing, CI, Monitoring
The codebase does not currently include tests. It would be good to test the API especially, as adding new ways of processing the data can often trigger regressions that break existing charts.
CI and monitoring would also help ensure new builds don't break the deployments, and that we're properly notified if (when) something does break.
Data Processing
Data processing relies on a mix of MongoDB aggregations and JavaScript functions. Some of this could probably be streamlined by someone familiar with the MongoDB aggregation API.
Here are a few key things to understand if you'd like to help with the Devographics surveys (State of JS, State of CSS, etc.)
Code
The surveys run on an entirely custom stack consisting of four main sub-apps that live inside a pnpm monorepo:
surveyform: a Next.js app that lets respondents complete a survey (e.g. https://survey.devographics.com/en-US/survey/state-of-html/2025/)surveyadmin: an internal Next.js dashboard app that I use to process/clean up the data.api: a Node.js app that powers a public GraphQL API that makes all the data available (https://graphiql.devographics.com/).results: a Gatsby app that creates the static results sites (https://2025.stateofhtml.com/)Config Files
In addition to that, there are a few other repos that hold config/content files:
Useful Ressources
Areas of Improvement
Here's some of the things I'd like to improve over the next months.
Onboarding
Because the apps all require various environment variables and need to connect to a database, cache, etc. running them locally isn't very straightforward. It would be nice to improve this via better docs, offline/local fallbacks, or other strategies.
Surveyform Migration
The surveyform app currently leverages a lot of Next.js advanced patterns such as SSR, partial rendering, RSCs, etc. but given that its content does not need to be indexed or shared it seems like it could function just as well as a client-side SPA.
Migrating to an SPA-first framework such as TanStack Start (or even staying with Next.js) could be a chance to simplify the codebase while also making the app easier to host on a standard server, without having to rely on Vercel's serverless or edge features.
Results Migration
The results app currently uses Gatsby, which is no longer under active development. It could be migrated to a more modern platform such as Astro or some other platform capable of rendering static React apps. Some considerations:
Note: Gatsby's ability to generate a static site that can also behave as an SPA once loaded (no loading in-between pages) is nice; not sure if Astro supports that as well?
Translation Infrastructure
There is no mechanism in place currently to notify volunteer translators when a string is added or changed and needs translation. It would be nice to have something that can batch those tasks and then publish them as GitHub issues in all the different locale repos.
TypeScript Maintenance
Some parts of the codebase are still written in JavaScript; others are in TypeScript but with many type errors. It would be nice to harmonize this a bit more.
Testing, CI, Monitoring
The codebase does not currently include tests. It would be good to test the API especially, as adding new ways of processing the data can often trigger regressions that break existing charts.
CI and monitoring would also help ensure new builds don't break the deployments, and that we're properly notified if (when) something does break.
Data Processing
Data processing relies on a mix of MongoDB aggregations and JavaScript functions. Some of this could probably be streamlined by someone familiar with the MongoDB aggregation API.