Frameworks
TypeScript framework selection should be intentional. The goal is to choose the simplest framework that fits the product, team, and deployment model without introducing unnecessary runtime or architectural complexity.
Our primary TypeScript frameworks are Astro, Next.js, and SvelteKit.
Default Standard
Section titled “Default Standard”Astro is the default choice for content-heavy websites, documentation sites, landing pages, and other experiences where most pages are static and only selected components need client-side interactivity.
Next.js is the default choice for React-based application development when a project needs authenticated user flows, dynamic data loading, server rendering, or full-stack web application patterns.
SvelteKit is appropriate when a project benefits from Svelte’s simpler component model, small client payloads, and highly interactive user interfaces, and the team is comfortable supporting that stack.
Choosing an alternate framework should be a deliberate decision based on product requirements and team familiarity.
When to Use Astro
Section titled “When to Use Astro”Prefer Astro when a project needs:
- Mostly static pages with limited islands of interactivity
- Strong content authoring workflows with Markdown or MDX
- Fast page loads with minimal client-side JavaScript
- Straightforward deployment for documentation, content, or marketing sites
Astro is usually the best fit when content structure, performance, and maintainability matter more than rich client-side application state.
When to Use Next.js
Section titled “When to Use Next.js”Prefer Next.js when a project needs:
- A React-based frontend with shared React component patterns
- Server-rendered or hybrid-rendered routes
- Authenticated dashboards, internal tools, or transactional web applications
- API endpoints, server actions, or other full-stack application features
- Broad ecosystem support for React libraries and tooling
Next.js is typically the better fit for complex web applications where React is already the team standard or where server and client concerns need to live in the same application.
When to Use SvelteKit
Section titled “When to Use SvelteKit”Prefer SvelteKit when a project needs:
- A lightweight framework for interactive user interfaces
- Smaller bundles and a reduced client-side runtime footprint
- A simpler state and component model than a comparable React application
- A full-stack framework built around the Svelte component system
SvelteKit can be an excellent fit for focused applications and polished frontend experiences, but it should be chosen intentionally because it narrows the hiring, package, and long-term maintenance pool compared with React-based projects.
Selection Criteria
Section titled “Selection Criteria”Before choosing a framework, evaluate:
- Whether the site is primarily content-driven or application-driven
- How much client-side interactivity and state management the product actually needs
- Whether the team is already invested in React or Svelte ecosystem tools
- Hosting and deployment requirements, including static export, server rendering, and edge or Node runtimes
- The expected long-term maintenance burden for the chosen framework and ecosystem
If multiple frameworks can satisfy the requirements, choose the one with fewer moving parts and the clearest operational model.
What to Avoid
Section titled “What to Avoid”Avoid these common mistakes:
- Choosing a full-stack application framework for a mostly static site
- Adding client-side complexity where server-rendered or static content is sufficient
- Selecting a framework based on novelty instead of team supportability
- Mixing multiple frontend frameworks in one product without a strong architectural reason
Framework choice should reduce complexity for the team and the product, not create another system to manage.