Technical decision: Selecting Astro for the new expressjs.com site

[bjohansebas]

In today’s meeting, during the discussion about the technology for the website redesign, the following key points were considered:

• The need for a simple authoring experience, preferably based on Markdown.
• Adequate support for i18n and handling of both existing and future languages.
• Efficient versioning of content without complicating long-term maintenance.
• Ease of contribution for new or less technical contributors.
• Ability to deploy the site as a static website, avoiding dependencies on external platforms.
• Minimizing long-term maintenance complexity.
• An easy way to switch technologies, with no dependency on the technology itself

Evaluation of tools:

• Docusaurus: very complete regarding i18n/versioning, but more complex and with a higher risk of breaking changes during updates.
• Astro: simpler, more flexible, Markdown-first, and more contribution-friendly.

---

Chosen option:
We decided during the meeting to move forward with Astro as the base technology for the new expressjs.com website.

Please comment on this issue or reach out privately to one of the website captains — if you object to this decision (within 1 week).

cc: @expressjs/docs-wg @expressjs/express-tc

[Borjagodoy]

Huge +1 on the move to Astro.

I wanted to highlight a core Astro feature that perfectly fits the "Ease of contribution" and "stability" requirements: Content Collections.

Since they enforce strict schemas (using Zod), they ensure that contributions follow the correct format automatically. This prevents "less technical contributors" from accidentally breaking the site due to missing or invalid frontmatter, which is a game-changer for maintenance in a large repo.

Also, regarding i18n and low maintenance, have you considered using Starlight as the foundation? It’s built on Astro but handles all the complex i18n routing and documentation UI out of the box, saving you from having to build and maintain those features manually.