Choosing Frameworks and Standards for 80 Sites

Two of my 2020 posts were really the same piece of work. At Elanco I was writing the web development standards for a global team responsible for around 80 active sites (Building a Web Platform for 80 Sites), and the blog was where I thought out loud: one post comparing Next.js and Gatsby, and one listing the React practices I wanted every site to follow.

Next.js vs Gatsby: the answer was “both”

My conclusion then was to use both, for different jobs. Gatsby generated every page at build time, so a content site could sit on cheap storage with no server, load fast and index well. Next.js rendered on the server (or statically, if you asked), which made it the better choice the moment a site needed dynamic content, client–server interaction, or so much content that full rebuilds became painful.

What I’d keep from that post:

• Start from the rendering model, not the brand. Static, server-rendered and client-rendered are different trade-offs in cost, freshness and complexity. Pick per page, not per framework.
• Don’t let a framework dictate your data layer. Gatsby wanted everything through GraphQL. That was lovely when a source plugin existed and a tax when it didn’t. Next.js let us call REST APIs directly, which mattered for the many platforms with no GraphQL API.
• Build times are a real cost. Rebuilding a large site on every content change was the pain I flagged, and it’s the reason incremental builds became table stakes.

What aged: Gatsby’s momentum faded, and Next.js absorbed static generation, incremental regeneration and server components. Today I’d frame the choice as Next.js (or similar) for applications and a content-first framework like Astro for sites that are mostly reading. That’s the choice I made for this garden (Resumability, and Why This Site Chose Astro).

The standards list

The React post was a dozen practices: small, single-purpose components; reuse before you create; don’t repeat yourself; comment only where needed; name components after what they do (Avatar, not AuthorAvatar); separate data loading from rendering; keep a component’s files in one folder; use Storybook; follow the linter.

Most of it still holds. A few things I’d change:

• “Separate stateful from stateless components” is now “keep data fetching in hooks or a server-state library”, and the folder-per-feature idea has grown into the structure I recommend in Bulletproof React.
• DRY has a limit. I’d now say “duplicate twice, abstract on the third time”. Premature abstraction made more components I later regretted than duplication ever did.
• Testing deserves more than one line. Today I’d point to behaviour-first tests and network-level mocks (React Testing Strategy).

The real lesson: standards ship as defaults

The most important thing I learned didn’t make it into either post. A standards document is easy to agree with and easy to ignore. What actually changed how 80 sites were built was turning the standards into a starting point: the Web Accelerator, a boilerplate with the decisions already made, provisioned through a self-service portal, with shared components in Storybook.

That’s the idea I now call a golden path, and it’s the most transferable thing I took from that job. If you want people to follow a standard, make it the easiest thing to do.

---

Originally written in 2020 → Nextjs vs Gatsby and React Web Standards