Stack decisions are among the most expensive you’ll make on a web project, not because the choice itself is hard but because it’s hard to reverse. The wrong framework at the start becomes a migration 18 months later. Get the fundamentals right early and the rest of the build gets simpler.
Start with the shape of the problem
Before opening a framework comparison, answer four questions about your project:
-
How dynamic is the content? A marketing site with a weekly blog update has different requirements than a feed refreshing every ten seconds. Static or near-static content is cheaper to serve, easier to cache, and faster by default.
-
Who builds and maintains it? A team already fluent in Vue will ship a better product in Vue than in React, even if the React ecosystem is larger. Developer fit is a real variable that comparison posts routinely undercount.
-
What are the traffic and performance constraints? A site expecting millions of monthly visitors needs a different delivery model than an internal dashboard used by twenty people.
-
What’s the data model? If your content comes from a headless CMS with a REST API, your stack choices narrow quickly. If you’re querying a relational database with complex relationships, the choice between REST and GraphQL APIs starts mattering before you’ve written a line of UI code.
None of these questions name a technology. That’s intentional. Frameworks are solutions to specific problems; picking one before you understand the problem is how projects end up over-engineered or awkwardly patched six months in.
Rendering strategy shapes almost everything else
Before you pick a framework, pick a rendering strategy. The two decisions are coupled, and rendering strategy is the higher-order choice.
Your rendering strategy is a product decision, not an engineering preference. It determines who waits, and for how long, every time someone visits your site.
The options, briefly: static generation pre-builds HTML at deploy time and serves it from a CDN; server-side rendering generates HTML per request on a server; client-side rendering sends a minimal HTML shell and builds the page in the browser; and hybrid approaches mix these per route. Each carries trade-offs in build complexity, time-to-first-byte, personalization capability, and hosting cost. A full breakdown of those trade-offs is in our rendering strategies guide.
The short rule of thumb: default to static wherever you can. Static sites are fast, cheap to host, and simple to cache. Add server rendering where personalization or real-time data genuinely demands it, and be deliberate about where that boundary sits. Spreading client-side rendering across a site that could be mostly static is a common way to pay a performance tax you never needed to pay.
Frontend: where the trade-offs actually bite
Given a rendering strategy, the frontend framework choice becomes more constrained. A few practical observations.
React is the safe generalist pick. The ecosystem is large, the hiring pool is deep, and most third-party component libraries target it first. The downside is that React’s defaults push toward more JavaScript than many sites need, and hydration costs matter on slower mobile CPUs.
Vue has a gentler learning curve for teams coming from template-oriented backgrounds and ships slightly less JavaScript by default. Its ecosystem is smaller than React’s but mature, and the component model is clearer for developers who find JSX awkward.
Astro is the right choice for content-heavy sites where you want minimal JavaScript and maximum flexibility about which UI framework handles interactive pieces. Why we build marketing sites with Astro covers the reasoning in detail: Astro ships zero JavaScript by default, lets you drop in React or Vue or Svelte only where you need interactivity, and is designed for the partial hydration pattern that performance-sensitive projects need.
Svelte and SvelteKit compile away the framework at build time, resulting in small bundles and fast runtime behavior. Worth serious consideration for performance-sensitive applications where bundle size is a hard constraint.
A note on full-stack meta-frameworks (Next.js, Nuxt, SvelteKit, Astro with server adapters): they are useful, but they add opinions about routing, data fetching, and deployment that you’ll live with for years. Choose them consciously, not because they ranked highly in a recent survey.
The backend and data layer
For most marketing sites, product pages, and editorial content, a headless CMS feeding a static frontend is the right architecture. You get editorial flexibility, clean separation of concerns, and straightforward deployment. This is the Jamstack pattern, and it handles the majority of cases without a custom backend.
When you do need a custom backend, a few filters help cut through the noise.
Match the language to your team. A Node/TypeScript backend pairs naturally with a TypeScript frontend and shares types across the boundary. A Python backend may be right if your data processing already lives in Python.
Pick a query layer you trust. The backend framework matters less than the database access pattern. Prisma, Drizzle, SQLAlchemy: choose the one your team can read and debug under pressure, not the one with the most recent GitHub stars.
Size the infrastructure to the actual problem. A serverless function is the right unit for a contact form endpoint. It is not the right unit for a data pipeline processing gigabytes of records. Over-engineering the backend to prepare for scale you don’t yet have costs time and money that compound.
Authentication, search, email, and payment are also worth noting here: these are solved problems. Reaching for a third-party service beats building from scratch in almost every case, and the opportunity cost of building them yourself is high.
How Strynal approaches stack decisions
At Strynal, stack selection is a scoping conversation, not a preference. Before recommending any technology, we work through the four questions from the opening section, then map the rendering strategy against the project’s traffic, content velocity, and team constraints. That order matters.
For most of the websites and apps we build, the pattern is a statically generated or hybrid Astro frontend against a headless CMS or a lightweight API layer. That combination is fast by default, portable across hosting providers, and easy for content teams to operate without engineering support. Where a project genuinely needs server rendering, a custom backend, or a richer interaction model, we make that call explicitly and document the reason.
The goal is a stack that fits the project for the next three years, not one that looks impressive in a job posting. The team that recommends the architecture is the team that ships and supports it, which keeps the incentive structure honest.