Why Multiple Frameworks?

The Monolith Assumption

Most web projects start with a single framework choice: “We’re a React shop” or “We use Vue.” This makes sense for small teams building a single product. But as applications grow, the monolith assumption starts showing cracks.

A billing dashboard with complex form state is a different problem than a real-time chat interface. A static blog is a different problem than an authentication flow. Using one framework for all of these means optimizing for the average case rather than the specific case.

What If You Didn’t Have To Choose?

Astro’s architecture makes multi-framework applications practical. Each “island” of interactivity can use whatever framework best fits its requirements, while sharing a common design system and deployment infrastructure.

In Multron, we chose frameworks based on the problem at hand:

React for Complex State

The conversations page is a React SPA. React’s ecosystem — React Query for data fetching, React Hook Form for validation, a rich component library ecosystem — makes it the right choice for data-heavy, stateful UIs.

// React's ecosystem shines for complex state management
import { useQuery } from '@tanstack/react-query'
import { useForm } from 'react-hook-form'

function ConversationView() {
  const { data } = useQuery({ queryKey: ['messages'], queryFn: fetchMessages })
  const { register, handleSubmit } = useForm()
  // ...
}

SolidJS for Lightweight Interactivity

The sign-in page is a SolidJS SPA. SolidJS’s fine-grained reactivity and tiny runtime (~7 KB) make it ideal for forms and simple interactive components where React’s overhead isn’t justified.

// SolidJS: fine-grained reactivity without virtual DOM
import { createSignal } from 'solid-js'

function SignInForm() {
  const [email, setEmail] = createSignal('')
  const [password, setPassword] = createSignal('')
  // Direct DOM updates, no diffing
}

Astro for Static Content

The blog you’re reading right now uses no JavaScript framework at all. It’s pure Astro — Markdown content rendered to static HTML at request time. The result is instant page loads and zero client-side overhead.

The Cost of Multi-Framework

There are real trade-offs:

• Learning curve — developers need familiarity with multiple frameworks
• Bundle management — each framework runtime adds to the total JavaScript
• Debugging complexity — stack traces cross framework boundaries

But Astro mitigates these costs:

1. Islands load independently — React’s runtime only loads on pages that use React
2. Directory-based separation — components live in react/ or solid/ directories, never mixed
3. Shared design tokens — the ax-* CSS system works identically across all frameworks

When Multi-Framework Makes Sense

Multi-framework isn’t for every project. It makes sense when:

• Different parts of your app have fundamentally different needs — a content site with an embedded SPA, a dashboard with a simple auth form
• You want to migrate incrementally — adopt a new framework one page at a time without rewriting everything
• Performance matters at the page level — some pages need zero JS, others need full interactivity
• Your team has diverse expertise — leverage what people already know

The Multron Approach

Multron demonstrates that multi-framework development isn’t theoretical — it works today with Astro 5.x. The key principles:

1. Choose frameworks per feature, not per project
2. Use CSS custom properties for framework-agnostic styling
3. Keep framework boundaries at the directory level
4. Default to zero JavaScript; add interactivity where needed

Read more about the technical details in mixing React and SolidJS and the island architecture.