Week 4 · Lesson 16

Comparing full stacks: Next.js+Vercel, Remix, Astro, SvelteKit

You already know the individual pieces — meta-frameworks, rendering strategies, hosting platforms, databases. This lesson zooms out: how do four common "pick this and go" stacks actually compare when you have to choose one for a real project?

Contents

What "a stack" actually bundles together
The four stacks, side by side
Dimension 1: rendering model
Dimension 2: learning curve and mental model
Dimension 3: hosting story
Dimension 4: ecosystem and hiring
Worked example: picking a stack for a generic project
The actual takeaway

1. What "a stack" actually bundles together

So far this track has covered meta-frameworks (Next.js), rendering strategies (SSR/SSG/ISR), and hosting platforms (Vercel, Netlify) as separate pieces you assemble yourself. In practice, though, most teams don't assemble from scratch — they pick a named combination that already has default answers for routing, rendering, data fetching, and deployment baked in. That combination is what "a stack" means here: a meta-framework plus its idiomatic hosting target plus the conventions the community around it has settled on.

Picking a stack is really picking a starting set of defaults you'll live with for the life of the project. Every one of the four below can technically do almost anything the others can — the differences that matter are in what's easy by default versus what requires fighting the framework.

2. The four stacks, side by side

Stack	UI library	Default rendering	Natural home
Next.js + Vercel	React	Mixed: SSR, SSG, ISR, and Server Components, chosen per route/component	Vercel (same company builds both)
Remix (now the framework mode of React Router)	React	SSR by default, built around HTTP fundamentals (loaders, actions, forms)	Any Node host — no single "home" platform
Astro	Any (React, Vue, Svelte, or none) via "islands"	Static by default, zero JS shipped unless a component opts into hydration	Any static host, plus adapters for SSR on Vercel/Netlify/Node
SvelteKit	Svelte (compiles away, no virtual DOM)	SSR by default, SSG available per-route	Any host via adapters (Vercel, Netlify, Node, static)

Notice the pattern: only Next.js has a single platform it's "from" — Vercel builds the framework and the hosting platform together, so the integration is deepest there. Remix, Astro, and SvelteKit were all designed to be host-agnostic from day one, which is a real trade-off, not just a footnote (more on that in the hosting section).

3. Dimension 1: rendering model

This is the dimension that most affects how a page actually behaves for a user, and it's the one worth understanding before anything else.

Next.js gives you the most granular control: a Server Component that never ships JS, a Client Component that hydrates, static generation at build time, or on-demand regeneration (ISR) — all mixable in the same app, even the same page. That flexibility is powerful but means more decisions to make per route.
Remix is deliberately simpler here: everything server-renders on every request by default, and you opt into caching at the infrastructure layer (CDN headers) rather than the framework offering multiple built-in strategies. Less to configure, less nuance to reason about.
Astro flips the default entirely: pages ship zero JavaScript unless you explicitly mark a component as interactive ("island"). This is the best default for content-heavy sites where most of the page is static text and images.
SvelteKit server-renders by default like Remix, but because Svelte compiles components into vanilla JS at build time (no framework runtime shipped to the browser), the resulting bundles tend to be smaller even for interactive pages.

4. Dimension 2: learning curve and mental model

Stack	Mental model	Curve
Next.js	React's component model, plus the Server/Client Component split, plus the App Router's file conventions	Steepest of the four — most concepts to internalize, but most tutorials/examples exist
Remix	Web fundamentals first: a route is a loader (GET) and an action (POST), forms submit like it's 2005 but with modern DX	Gentle if you already know HTTP; unusual if your only mental model is client-side state
Astro	Write components like a static site generator, "eject" into interactivity only where needed	Gentle — often the easiest of the four to get a first page live
SvelteKit	Svelte's own reactive syntax (no `useState`-style hooks, closer to plain JS with reactive variables)	Gentle to learn from scratch, mildly unusual if you're coming from years of React habits

5. Dimension 3: hosting story

This is where the "single home platform" difference from section 2 actually shows up in day-to-day work.

Next.js on Vercel gets first-class support for every rendering mode the framework offers, often before other hosts catch up — new Next.js features and new Vercel platform features tend to ship in lockstep, since one company owns both.
Remix, Astro, and SvelteKit all ship via "adapters" — a small package that translates the framework's output into whatever a given host expects (a Vercel function, a Netlify function, a plain Node server, static files). This means you can move host without touching your app code, at the cost of occasionally waiting for an adapter to catch up with a brand-new framework feature.

The trade-off in one sentence: Next.js + Vercel optimizes for "deepest integration, less portability"; Remix/Astro/SvelteKit optimize for "host-agnostic, slightly more moving parts to configure."

6. Dimension 4: ecosystem and hiring

This dimension rarely gets discussed in technical comparisons, but it's often the deciding factor for a real team.

Next.js has by far the largest ecosystem: the most Stack Overflow answers, the most third-party libraries with first-class Next.js examples, the easiest pool of developers to hire from because React skills are the most common on the market.
Remix inherits React's hiring pool but a much smaller pattern-specific community — you'll find fewer tutorials for edge cases, and you'll rely more on reading the source/docs directly.
Astro has a fast-growing but content-site-specific community — deep expertise in blogs/docs/marketing sites, thinner if you're building a highly interactive dashboard.
SvelteKit has the smallest hiring pool of the four, though the developers who do know Svelte tend to be enthusiastic about it — a real consideration if you're building a team, not just a side project.

7. Worked example: picking a stack for a generic project

Say you're starting a project with logins, a dashboard, and some dynamic per-user data — a fairly typical SaaS shape. Here's how the decision actually plays out:

Decision walkthrough

Does your team already know React? If yes, you're choosing between Next.js and Remix, not considering Astro or SvelteKit at all — don't introduce a new UI library just for this project unless there's a specific reason to.
Do you want maximum control over rendering per page, and don't mind Vercel-specific conventions? Next.js. This is the safer default for most teams today precisely because of the ecosystem size from section 6.
Do you want something closer to plain HTTP, simpler mental model, and host flexibility from day one? Remix.
Is the project actually more content than app (a blog, docs site, marketing page with a login gate bolted on)? Astro, regardless of what your team knows — the zero-JS-by-default model is wasted if you don't have a content-heavy site.
Is smallest possible bundle size the top priority, and is the team open to learning Svelte? SvelteKit — but be honest about the hiring/community trade-off from section 6 before committing a whole team to it.

8. The actual takeaway

None of these four stacks is objectively better — they optimize for different things, and three of the four dimensions above (learning curve, hosting, ecosystem) matter more in practice than raw technical capability, because all four can eventually do what you need. The question that actually predicts a good outcome isn't "which stack is best" — it's "which stack's defaults match what this specific project and this specific team actually need," which is exactly the walkthrough in section 7.

Newsletter

Learn what AI is creating for you. Don't get lost.

Get notified when a new deep dive or lesson goes up. No spam, just new posts.

Semana 4 · Lição 16

Comparando stacks completas: Next.js+Vercel, Remix, Astro, SvelteKit

Você já conhece as peças individuais — meta-frameworks, estratégias de renderização, plataformas de hospedagem, bancos de dados. Esta lição dá um passo atrás: como quatro stacks comuns de "escolha e comece" se comparam de verdade na hora de decidir por um projeto real?

Sumário

O que "uma stack" agrupa de fato
As quatro stacks, lado a lado
Dimensão 1: modelo de renderização
Dimensão 2: curva de aprendizado e modelo mental
Dimensão 3: história de hospedagem
Dimensão 4: ecossistema e contratação
Exemplo prático: escolhendo uma stack pra um projeto genérico
A conclusão de verdade

1. O que "uma stack" agrupa de fato

Até aqui esta trilha cobriu meta-frameworks (Next.js), estratégias de renderização (SSR/SSG/ISR) e plataformas de hospedagem (Vercel, Netlify) como peças separadas que você monta sozinho. Na prática, porém, a maioria dos times não monta do zero — eles escolhem uma combinação já nomeada que já tem respostas padrão pra roteamento, renderização, busca de dados e deploy. Essa combinação é o que "uma stack" significa aqui: um meta-framework mais seu alvo de hospedagem idiomático mais as convenções que a comunidade em volta dele já consolidou.

Escolher uma stack é, na verdade, escolher um conjunto inicial de padrões com o qual você vai conviver pela vida útil do projeto. Cada uma das quatro abaixo consegue, tecnicamente, fazer quase tudo que as outras fazem — as diferenças que importam estão no que é fácil por padrão versus o que exige lutar contra o framework.

2. As quatro stacks, lado a lado

Stack	Biblioteca de UI	Renderização padrão	Casa natural
Next.js + Vercel	React	Mista: SSR, SSG, ISR e Server Components, escolhidos por rota/componente	Vercel (a mesma empresa constrói os dois)
Remix (hoje o modo framework do React Router)	React	SSR por padrão, construído em volta de fundamentos HTTP (loaders, actions, forms)	Qualquer host Node — sem uma única "casa"
Astro	Qualquer uma (React, Vue, Svelte, ou nenhuma) via "ilhas"	Estático por padrão, zero JS enviado a menos que um componente opte por hidratação	Qualquer host estático, mais adaptadores pra SSR na Vercel/Netlify/Node
SvelteKit	Svelte (compila pra fora, sem DOM virtual)	SSR por padrão, SSG disponível por rota	Qualquer host via adaptadores (Vercel, Netlify, Node, estático)

Repare no padrão: só o Next.js tem uma única plataforma da qual ele "é" — a Vercel constrói o framework e a plataforma de hospedagem juntos, então a integração é mais profunda ali. Remix, Astro e SvelteKit foram todos projetados pra serem agnósticos de host desde o primeiro dia, o que é um trade-off real, não só uma nota de rodapé (mais na seção de hosting).

3. Dimensão 1: modelo de renderização

Essa é a dimensão que mais afeta como uma página de fato se comporta pro usuário, e é a que vale entender antes de qualquer outra.

Next.js dá o controle mais granular: um Server Component que nunca manda JS, um Client Component que hidrata, geração estática em tempo de build, ou regeneração sob demanda (ISR) — tudo misturável no mesmo app, até na mesma página. Essa flexibilidade é poderosa mas significa mais decisões por rota.
Remix é deliberadamente mais simples aqui: tudo renderiza no servidor a cada requisição por padrão, e você opta por cache na camada de infraestrutura (headers de CDN) em vez do framework oferecer múltiplas estratégias embutidas. Menos pra configurar, menos nuance pra raciocinar.
Astro inverte o padrão inteiramente: páginas mandam zero JavaScript a menos que você marque explicitamente um componente como interativo ("ilha"). Esse é o melhor padrão pra sites com muito conteúdo, onde a maior parte da página é texto e imagem estática.
SvelteKit renderiza no servidor por padrão como o Remix, mas como o Svelte compila componentes pra JS puro em tempo de build (sem runtime de framework enviado ao navegador), os bundles resultantes tendem a ser menores mesmo em páginas interativas.

4. Dimensão 2: curva de aprendizado e modelo mental

Stack	Modelo mental	Curva
Next.js	O modelo de componentes do React, mais a divisão Server/Client Component, mais as convenções de arquivo do App Router	A mais íngreme das quatro — mais conceitos pra internalizar, mas mais tutoriais/exemplos existem
Remix	Fundamentos web primeiro: uma rota é um loader (GET) e uma action (POST), formulários submetem como em 2005 mas com DX moderna	Suave se você já conhece HTTP; incomum se seu único modelo mental é state no client
Astro	Escreva componentes como um gerador de site estático, "ejete" pra interatividade só onde precisar	Suave — muitas vezes a mais fácil das quatro pra colocar uma primeira página no ar
SvelteKit	Sintaxe reativa própria do Svelte (sem hooks estilo `useState`, mais perto de JS puro com variáveis reativas)	Suave pra aprender do zero, levemente incomum se você vem de anos de hábitos React

5. Dimensão 3: história de hospedagem

É aqui que a diferença de "única casa" da seção 2 aparece de fato no dia a dia.

Next.js na Vercel ganha suporte de primeira classe pra todo modo de renderização que o framework oferece, muitas vezes antes de outros hosts alcançarem — features novas do Next.js e da plataforma Vercel tendem a sair em sincronia, já que uma empresa é dona dos dois.
Remix, Astro e SvelteKit todos publicam via "adaptadores" — um pacotinho que traduz a saída do framework pro que quer que um host específico espere (uma function da Vercel, uma function da Netlify, um servidor Node puro, arquivos estáticos). Isso significa que você pode trocar de host sem tocar no código do app, ao custo de eventualmente esperar um adaptador alcançar uma feature novíssima do framework.

O trade-off em uma frase: Next.js + Vercel otimiza pra "integração mais profunda, menos portabilidade"; Remix/Astro/SvelteKit otimizam pra "agnóstico de host, um pouco mais de peças pra configurar."

6. Dimensão 4: ecossistema e contratação

Essa dimensão raramente é discutida em comparações técnicas, mas costuma ser o fator decisivo pra um time real.

Next.js tem de longe o maior ecossistema: mais respostas no Stack Overflow, mais bibliotecas de terceiros com exemplos de primeira classe pra Next.js, a piscina mais fácil de desenvolvedores pra contratar porque habilidades em React são as mais comuns no mercado.
Remix herda a piscina de contratação do React mas uma comunidade específica do padrão muito menor — você encontra menos tutoriais pra casos de borda, e depende mais de ler a documentação/código-fonte direto.
Astro tem uma comunidade em crescimento rápido mas específica de site de conteúdo — expertise profunda em blogs/docs/sites institucionais, mais rasa se você está construindo um dashboard bem interativo.
SvelteKit tem a menor piscina de contratação das quatro, embora os desenvolvedores que conhecem Svelte costumem ser bem entusiasmados com ele — uma consideração real se você está formando um time, não só um projeto pessoal.

7. Exemplo prático: escolhendo uma stack pra um projeto genérico

Digamos que você está começando um projeto com login, um dashboard, e alguns dados dinâmicos por usuário — um formato bem típico de SaaS. Veja como a decisão se desenrola de fato:

Passo a passo da decisão

Seu time já conhece React? Se sim, você está escolhendo entre Next.js e Remix, nem considerando Astro ou SvelteKit — não introduza uma biblioteca de UI nova só pra esse projeto a menos que haja uma razão específica.
Você quer controle máximo sobre renderização por página, e não se importa com convenções específicas da Vercel? Next.js. Esse é o padrão mais seguro pra maioria dos times hoje precisamente por causa do tamanho do ecossistema da seção 6.
Você quer algo mais perto de HTTP puro, modelo mental mais simples, e flexibilidade de host desde o primeiro dia? Remix.
O projeto é na verdade mais conteúdo que app (um blog, site de documentação, página institucional com um login parafusado)? Astro, independente do que seu time conhece — o modelo de zero-JS-por-padrão é desperdiçado se você não tem um site denso em conteúdo.
Tamanho de bundle mínimo é a prioridade número um, e o time está aberto a aprender Svelte? SvelteKit — mas seja honesto sobre o trade-off de contratação/comunidade da seção 6 antes de comprometer um time inteiro com ele.

8. A conclusão de verdade

Nenhuma dessas quatro stacks é objetivamente melhor — elas otimizam pra coisas diferentes, e três das quatro dimensões acima (curva de aprendizado, hosting, ecossistema) importam mais na prática do que capacidade técnica bruta, porque todas as quatro conseguem eventualmente fazer o que você precisa. A pergunta que realmente prevê um bom resultado não é "qual stack é melhor" — é "quais padrões de stack combinam com o que esse projeto específico e esse time específico realmente precisam", que é exatamente o passo a passo da seção 7.

Newsletter

Saiba o que a IA está criando pra você. Não fique por fora.

Seja avisado quando eu postar uma imersão ou lição nova. Sem spam, só posts novos.