Triggered by the giant "Application Preset" dropdown on Vercel's import screen — Angular, Astro, Django, Vite, Vue and 60+ more. Grouped by what each one actually solves, not alphabetically.
That dropdown mixes tools that solve completely different problems, which is exactly why it looks overwhelming. Almost everything in it falls into one of four buckets:
Meta-frameworks — sit on top of a UI library (React, Vue, Svelte...) and add routing, rendering strategy (SSR/SSG), and a build pipeline. Example: Next.js on top of React.
Plain build tools / SPA scaffolds — just bundle a client-side app, no server rendering or file-based routing built in. Example: Vite, Create React App.
Static site / content generators — turn markdown/content files into static HTML at build time, aimed at blogs, docs, and marketing sites, not app-like interactivity. Example: Hugo, Astro, Docusaurus.
Backend / API frameworks — run entirely on the server, no bundled front-end story. Example: Django, Express, FastAPI.
Once you know which bucket a name belongs to, you already know 80% of what it's for — the rest is just details.
2. Full-stack meta-frameworks — React family
Name
What it is
When it fits
Next.js
The dominant React meta-framework. File-based routing, Server/Client Components, SSR/SSG/ISR, made by Vercel — deepest integration with Vercel itself.
Default choice for React apps that need SEO, mixed rendering, or just want the most support/ecosystem/tutorials available.
Remix / React Router (v7)
React meta-framework focused on web fundamentals (forms, HTTP, nested routing) over heavy build-time optimization. React Router absorbed Remix's framework mode.
Teams that want SSR with less "magic" and more direct control over data loading per route.
Gatsby
React framework focused on static generation at build time, historically GraphQL-centric for pulling data from any source into static pages.
Content-heavy sites where nearly everything can be pre-built — lost ground to Next.js/Astro in recent years.
RedwoodJS
Opinionated full-stack framework bundling React + GraphQL + Prisma (database ORM) in one project structure.
Teams that want a "Rails-like" all-in-one full-stack answer specifically for React + GraphQL.
Blitz.js (Legacy)
Was a "Next.js + batteries" full-stack framework (rpc-style data layer instead of REST/GraphQL). Marked legacy — community has largely moved on.
Mostly maintaining existing projects; not a starting point for new ones today.
TanStack Start
Newer full-stack React framework built around TanStack Router/Query, type-safety-first philosophy.
Teams already deep in the TanStack ecosystem (Query, Table, Router) wanting one cohesive stack.
File-based routing, SSR/SSG, auto-imports. The default choice if your team already knows Vue.
SvelteKit (and legacy Sapper)
Next.js, for Svelte
Svelte compiles away a lot of runtime JS, so apps tend to ship less client-side code than the React/Vue equivalents.
SolidStart (v0/v1)
Next.js, for SolidJS
SolidJS keeps a React-like syntax but with a fundamentally different (compiled, no virtual DOM) reactivity model — SolidStart is its official meta-framework.
Hydrogen (v1)
Next.js, but Shopify-specific
React meta-framework purpose-built for Shopify storefronts — not a general-purpose choice.
Pattern to notice: almost every UI library eventually grows its own "Next.js equivalent" once it becomes popular enough that people want SSR/routing solved for them. Whichever UI library your team knows best, there's very likely already a meta-framework for it.
4. Plain SPA build tools (no meta-framework)
Name
What it is
Vite
The modern default. Fast dev server (native ES modules, no bundling in dev), Rollup-based production build. Framework-agnostic — works with React, Vue, Svelte, plain JS.
Create React App
The historical default for bootstrapping a plain React SPA. Effectively unmaintained/deprecated by the React team in favor of Vite or a meta-framework.
Parcel
Zero-config bundler, another Webpack alternative, less common than Vite today but still used in some projects valuing near-zero setup.
Brunch
An older, less-configuration build tool from before Webpack/Vite dominance — rarely a first choice today, shows up mostly in legacy projects.
UmiJS
A React application framework popular in the Chinese dev ecosystem (built by Ant Design's team) bundling routing + build tooling.
The thing all of these share: no server rendering, no file-based routing baked in — you get a client-side app and choose your own libraries for the rest (this is exactly the layer discussed in Module 1's Vite/Webpack/Next.js build-tool deep dive).
5. Component frameworks without a bundled meta-layer
Name
Category
Notes
Angular
Full front-end framework (not just a library like React)
Batteries-included: routing, forms, HTTP client, dependency injection all built in, opinionated structure. Common in large enterprise teams that value convention and TypeScript-first design.
Vue.js
UI library (like React), Nuxt is its meta-framework
Template-based syntax (closer to plain HTML than JSX), often considered an easier on-ramp than React for beginners.
Svelte
UI library/compiler, SvelteKit is its meta-framework
Compiles components into vanilla JS at build time instead of shipping a runtime library — smaller bundles.
Preact
Lightweight React-API-compatible alternative
Same API surface as React at a fraction of the bundle size — used when every kilobyte matters (embeds, low-end devices).
Ember.js
Full front-end framework, older generation
Convention-heavy, was very popular pre-React; still maintained, niche today outside of existing large Ember codebases.
Stencil
Compiler for Web Components
Generates framework-agnostic custom elements — useful for shipping a component library usable from React, Vue, Angular, or plain HTML alike.
Polymer, Dojo
Older Web Components / MVC frameworks
Mostly historical relevance today; you'll encounter them maintaining legacy projects, not starting new ones.
6. Static site / content generators
These are aimed at content that doesn't change per-user — blogs, docs, marketing sites — where the whole page can be built once and served as static files.
Name
Language/stack
Best known for
Astro
JS/TS, any UI library as "islands"
Ships zero JS by default, only hydrates the specific interactive components you mark — very popular for content sites that need a little bit of interactivity.
Hugo
Go
Extremely fast builds even on huge sites; a common choice for large documentation/blog sites.
Jekyll
Ruby
The original "static site generator", still the engine behind GitHub Pages' default setup.
Eleventy (11ty)
JS
Minimal, unopinionated — you bring your own templating language.
Docusaurus (v1/v2+)
React
Purpose-built for documentation sites (versioning, search, sidebars out of the box) — made by Meta, used by many open source docs.
VuePress / VitePress
Vue
Same idea as Docusaurus, for the Vue ecosystem; VitePress is the newer, Vite-powered successor.
Gridsome, Saber, Scully
Vue / React / Angular
Framework-specific static generators (Gridsome = Vue, Saber = React, Scully = Angular) — smaller communities than the leaders above.
Hexo, Middleman, Zola
JS / Ruby / Rust
Blog-oriented static generators, popular in specific niches/communities more than mainstream product sites.
7. Backend / API frameworks
These run only on a server — no bundled front-end. Some ship HTML themselves (Django, Flask), others exist purely as JSON APIs consumed by a separate front-end (Express, FastAPI, NestJS).
Name
Language
Notes
Django
Python
Covered in depth in Module 1's extra material — full-stack, batteries-included, admin panel auto-generated from models.
Flask
Python
Minimal, unopinionated Python framework — you assemble the pieces yourself, opposite philosophy from Django.
FastAPI
Python
Modern, async-first, automatic OpenAPI/docs generation from type hints — has become the default for Python-based JSON APIs, especially ML/AI-adjacent services.
FastHTML
Python
Newer approach: write server-rendered HTML directly from Python without a separate templating language or front-end framework.
Express
Node.js/JS
The long-standing minimal default for Node APIs — small core, huge middleware ecosystem.
NestJS
Node.js/TS
Opinionated, Angular-inspired structure (modules, decorators, dependency injection) on top of Express/Fastify — popular for larger Node backend teams.
Fastify
Node.js/JS
Performance-focused Express alternative, schema-based validation built in.
Koa
Node.js/JS
From the original Express team, smaller core relying more on middleware composition (async/await-first design).
Hono, Elysia, H3, Nitro
JS/TS (edge-first)
Newer, lightweight frameworks designed to run well on edge runtimes (Vercel Edge, Cloudflare Workers) — smaller footprint than Express/Nest.
Go, Node, Python (generic)
—
These generic entries mean "just run this raw runtime", for projects not using a named framework at all.
8. Everything else: niche, legacy, and generic
A handful of entries don't fit the categories above cleanly:
Ionic Angular / Ionic React — hybrid mobile app frameworks (build once, run as an app via a WebView wrapper), using Angular or React as the UI layer.
Storybook — not a website framework at all, it's a tool for developing and documenting UI components in isolation. Appears here because it can also be deployed as a static site (the component catalog itself).
Sanity (v2/v3) — a headless CMS with its own studio/admin app that can be deployed like a front-end project.
Mastra, xmcp — newer frameworks for building AI agents / MCP servers, not traditional websites — included because Vercel now hosts these workloads too.
Services, Container, Other — generic presets for anything Vercel can't auto-detect a specific framework for (a Dockerfile-based project, a background service, etc).
9. How to actually choose, in practice
If you're building an interactive product/app (dashboard, SaaS, anything with logins and dynamic data): pick a meta-framework matching the UI library your team knows — Next.js for React (the safest default today), Nuxt for Vue, SvelteKit for Svelte.
If you're building a content site (blog, docs, marketing/landing page with little interactivity): reach for a static site generator instead of a full meta-framework — Astro if you want some interactive components mixed in, Hugo/Eleventy if you want it as fast and minimal as possible.
If you're building a pure API consumed by a separate front-end: match the language your team/data science stack already uses — FastAPI or Django if Python, Express/Fastify/NestJS if Node, and consider the edge-first options (Hono, Elysia) only if latency at the edge is an explicit requirement.
The trap to avoid: picking a framework because it's unfamiliar and "looks interesting" in a dropdown. Almost every name in that list is solving a problem some other name on the same list already solves for your specific stack — the real decision is usually just "which UI library / language does my team already know", and the rest follows from that.
Share:
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.
Imersão · Frameworks e presets de deploy
Frameworks e presets de deploy, mapeados
Motivado pelo dropdown gigante de "Application Preset" na tela de import do Vercel — Angular, Astro, Django, Vite, Vue e mais de 60 outros. Agrupado pelo que cada um resolve de fato, não em ordem alfabética.
1. O panorama geral: 4 tipos de ferramenta nessa lista
Esse dropdown mistura ferramentas que resolvem problemas completamente diferentes, e é exatamente por isso que parece opressor. Quase tudo ali cai em uma de quatro categorias:
Meta-frameworks — ficam em cima de uma biblioteca de UI (React, Vue, Svelte...) e adicionam roteamento, estratégia de renderização (SSR/SSG) e um pipeline de build. Exemplo: Next.js em cima do React.
Ferramentas de build puras / scaffolds de SPA — só empacotam uma aplicação client-side, sem renderização no servidor ou roteamento baseado em arquivos embutido. Exemplo: Vite, Create React App.
Geradores de site estático / conteúdo — transformam arquivos markdown/conteúdo em HTML estático no momento do build, voltados a blogs, documentação e sites institucionais, não a interatividade de aplicativo. Exemplo: Hugo, Astro, Docusaurus.
Frameworks de backend / API — rodam inteiramente no servidor, sem história de front-end embutida. Exemplo: Django, Express, FastAPI.
Uma vez que você sabe em qual categoria um nome se encaixa, você já sabe 80% pra que ele serve — o resto é só detalhe.
2. Meta-frameworks fullstack — família React
Nome
O que é
Quando se encaixa
Next.js
O meta-framework dominante do React. Roteamento baseado em arquivos, Server/Client Components, SSR/SSG/ISR, feito pela Vercel — integração mais profunda com a própria Vercel.
Escolha padrão pra apps React que precisam de SEO, renderização mista, ou simplesmente querem o maior suporte/ecossistema/tutoriais disponíveis.
Remix / React Router (v7)
Meta-framework React focado em fundamentos da web (formulários, HTTP, roteamento aninhado) em vez de otimização pesada em tempo de build. O React Router absorveu o modo framework do Remix.
Times que querem SSR com menos "mágica" e mais controle direto sobre o carregamento de dados por rota.
Gatsby
Framework React focado em geração estática no momento do build, historicamente centrado em GraphQL pra puxar dados de qualquer fonte pra páginas estáticas.
Sites com muito conteúdo onde quase tudo pode ser pré-construído — perdeu espaço pro Next.js/Astro nos últimos anos.
RedwoodJS
Framework fullstack opinativo que junta React + GraphQL + Prisma (ORM de banco) numa estrutura de projeto só.
Times que querem uma resposta "tipo Rails" tudo-em-um, especificamente pra React + GraphQL.
Blitz.js (Legacy)
Era um framework fullstack "Next.js + baterias" (camada de dados estilo rpc em vez de REST/GraphQL). Marcado como legado — a comunidade migrou em boa parte.
Majoritariamente manutenção de projetos existentes; não é ponto de partida pra projetos novos hoje.
TanStack Start
Framework fullstack React mais recente, construído em volta do TanStack Router/Query, com filosofia type-safety em primeiro lugar.
Times já profundos no ecossistema TanStack (Query, Table, Router) que querem um stack coeso.
3. Meta-frameworks fullstack — Vue, Svelte, Solid e outros
Nome
Equivalente a
Observações
Nuxt
Next.js, pro Vue
Roteamento baseado em arquivos, SSR/SSG, auto-imports. Escolha padrão se o time já conhece Vue.
SvelteKit (e o legado Sapper)
Next.js, pro Svelte
Svelte compila boa parte do JS de runtime pra fora, então apps tendem a mandar menos código client-side que os equivalentes React/Vue.
SolidStart (v0/v1)
Next.js, pro SolidJS
SolidJS mantém sintaxe parecida com React mas com modelo de reatividade fundamentalmente diferente (compilado, sem DOM virtual) — SolidStart é seu meta-framework oficial.
Hydrogen (v1)
Next.js, mas específico da Shopify
Meta-framework React feito sob medida pra lojas Shopify — não é escolha de propósito geral.
Padrão pra notar: quase toda biblioteca de UI acaba criando seu próprio "equivalente ao Next.js" assim que fica popular o suficiente pra as pessoas quererem SSR/roteamento resolvido pra elas. Qualquer que seja a biblioteca de UI que seu time já conhece melhor, muito provavelmente já existe um meta-framework pra ela.
4. Ferramentas de build de SPA puro (sem meta-framework)
Nome
O que é
Vite
O padrão moderno. Servidor de dev rápido (módulos ES nativos, sem empacotar em dev), build de produção baseado em Rollup. Agnóstico de framework — funciona com React, Vue, Svelte, JS puro.
Create React App
O padrão histórico pra iniciar uma SPA React pura. Efetivamente sem manutenção/descontinuado pelo time do React, em favor do Vite ou de um meta-framework.
Parcel
Bundler zero-config, outra alternativa ao Webpack, menos comum que o Vite hoje mas ainda usado em projetos que valorizam configuração quase nula.
Brunch
Ferramenta de build mais antiga, com menos configuração, de antes da dominância do Webpack/Vite — raramente uma primeira escolha hoje, aparece mais em projetos legados.
UmiJS
Framework de aplicação React popular no ecossistema chinês de desenvolvimento (feito pelo time do Ant Design) juntando roteamento + ferramental de build.
O que todos esses compartilham: sem renderização no servidor, sem roteamento baseado em arquivos embutido — você recebe uma aplicação client-side e escolhe suas próprias bibliotecas pro resto (essa é exatamente a camada discutida no aprofundamento de Vite/Webpack/build do Next.js do Módulo 1).
5. Frameworks de componente sem camada de meta-framework embutida
Nome
Categoria
Observações
Angular
Framework de front-end completo (não só uma biblioteca como o React)
Com baterias incluídas: roteamento, formulários, cliente HTTP, injeção de dependência, tudo embutido, estrutura opinativa. Comum em times grandes/corporativos que valorizam convenção e design TypeScript-first.
Vue.js
Biblioteca de UI (como o React), Nuxt é seu meta-framework
Sintaxe baseada em templates (mais parecida com HTML puro que JSX), frequentemente considerada uma entrada mais fácil que o React pra iniciantes.
Svelte
Biblioteca/compilador de UI, SvelteKit é seu meta-framework
Compila componentes pra JS puro no momento do build em vez de mandar uma biblioteca de runtime — bundles menores.
Preact
Alternativa leve compatível com a API do React
Mesma superfície de API do React numa fração do tamanho do bundle — usado quando cada kilobyte importa (embeds, dispositivos limitados).
Ember.js
Framework de front-end completo, geração mais antiga
Muito baseado em convenção, era muito popular antes do React; ainda mantido, hoje é nicho fora de bases de código Ember grandes já existentes.
Stencil
Compilador de Web Components
Gera custom elements agnósticos de framework — útil pra distribuir uma biblioteca de componentes usável a partir de React, Vue, Angular ou HTML puro.
Polymer, Dojo
Frameworks mais antigos de Web Components / MVC
Relevância majoritariamente histórica hoje; você encontra eles mantendo projetos legados, não começando projetos novos.
6. Geradores de site estático / conteúdo
Esses são voltados a conteúdo que não muda por usuário — blogs, documentação, sites institucionais — onde a página inteira pode ser construída uma vez e servida como arquivos estáticos.
Nome
Linguagem/stack
Mais conhecido por
Astro
JS/TS, qualquer biblioteca de UI como "ilhas"
Não manda JS por padrão, só hidrata os componentes interativos específicos que você marcar — muito popular pra sites de conteúdo que precisam de um pouco de interatividade.
Hugo
Go
Builds extremamente rápidos mesmo em sites enormes; escolha comum pra sites grandes de documentação/blog.
Jekyll
Ruby
O "gerador de site estático" original, ainda é o motor por trás da configuração padrão do GitHub Pages.
Eleventy (11ty)
JS
Minimalista, sem opinião forte — você traz sua própria linguagem de template.
Docusaurus (v1/v2+)
React
Feito sob medida pra sites de documentação (versionamento, busca, sidebars prontos) — feito pela Meta, usado por muita documentação open source.
VuePress / VitePress
Vue
Mesma ideia do Docusaurus, pro ecossistema Vue; VitePress é o sucessor mais novo, movido a Vite.
Gridsome, Saber, Scully
Vue / React / Angular
Geradores estáticos específicos de framework (Gridsome = Vue, Saber = React, Scully = Angular) — comunidades menores que os líderes acima.
Hexo, Middleman, Zola
JS / Ruby / Rust
Geradores estáticos voltados a blog, populares em nichos/comunidades específicas mais que em sites de produto mainstream.
7. Frameworks de backend / API
Esses rodam só no servidor — sem front-end embutido. Alguns entregam HTML eles mesmos (Django, Flask), outros existem puramente como APIs JSON consumidas por um front-end separado (Express, FastAPI, NestJS).
Nome
Linguagem
Observações
Django
Python
Coberto em profundidade no material complementar do Módulo 1 — fullstack, com baterias incluídas, painel admin gerado automaticamente a partir dos modelos.
Flask
Python
Framework Python minimalista, sem opinião forte — você monta as peças você mesmo, filosofia oposta ao Django.
FastAPI
Python
Moderno, async por padrão, geração automática de OpenAPI/docs a partir de type hints — virou o padrão pra APIs JSON em Python, especialmente serviços adjacentes a ML/IA.
FastHTML
Python
Abordagem mais nova: escrever HTML renderizado no servidor direto do Python, sem uma linguagem de template separada nem framework de front-end.
Express
Node.js/JS
O padrão minimalista de longa data pra APIs Node — núcleo pequeno, ecossistema de middleware enorme.
NestJS
Node.js/TS
Estrutura opinativa, inspirada no Angular (módulos, decorators, injeção de dependência) em cima do Express/Fastify — popular em times de backend Node maiores.
Fastify
Node.js/JS
Alternativa ao Express focada em performance, com validação baseada em schema embutida.
Koa
Node.js/JS
Do time original do Express, núcleo menor dependendo mais de composição de middleware (design async/await desde o início).
Hono, Elysia, H3, Nitro
JS/TS (edge-first)
Frameworks mais novos e leves, desenhados pra rodar bem em runtimes de edge (Vercel Edge, Cloudflare Workers) — pegada menor que Express/Nest.
Go, Node, Python (genérico)
—
Essas entradas genéricas significam "só rode esse runtime cru", pra projetos que não usam nenhum framework nomeado.
8. Todo o resto: nicho, legado e genérico
Um punhado de entradas não se encaixa direito nas categorias acima:
Ionic Angular / Ionic React — frameworks de app mobile híbrido (constrói uma vez, roda como app via um wrapper WebView), usando Angular ou React como camada de UI.
Storybook — não é framework de site nenhum, é uma ferramenta pra desenvolver e documentar componentes de UI isoladamente. Aparece aqui porque também pode ser publicado como um site estático (o próprio catálogo de componentes).
Sanity (v2/v3) — um CMS headless com seu próprio app de studio/admin que pode ser publicado como um projeto de front-end.
Mastra, xmcp — frameworks mais novos pra construir agentes de IA / servidores MCP, não sites tradicionais — incluídos porque a Vercel agora hospeda esse tipo de carga também.
Services, Container, Other — presets genéricos pra qualquer coisa que a Vercel não consiga detectar automaticamente um framework específico (um projeto baseado em Dockerfile, um serviço de background, etc).
9. Como escolher de verdade, na prática
Se você está construindo um produto/app interativo (dashboard, SaaS, qualquer coisa com login e dados dinâmicos): escolha um meta-framework que combine com a biblioteca de UI que seu time conhece — Next.js pro React (a escolha padrão mais segura hoje), Nuxt pro Vue, SvelteKit pro Svelte.
Se você está construindo um site de conteúdo (blog, documentação, página institucional/landing com pouca interatividade): use um gerador de site estático em vez de um meta-framework completo — Astro se quiser misturar alguns componentes interativos, Hugo/Eleventy se quiser o mais rápido e minimalista possível.
Se você está construindo uma API pura consumida por um front-end separado: combine com a linguagem que seu time/stack de dados já usa — FastAPI ou Django se for Python, Express/Fastify/NestJS se for Node, e considere as opções edge-first (Hono, Elysia) só se latência na borda for um requisito explícito.
A armadilha pra evitar: escolher um framework porque é desconhecido e "parece interessante" num dropdown. Quase todo nome nessa lista resolve um problema que algum outro nome da mesma lista já resolve pro seu stack específico — a decisão real geralmente é só "qual biblioteca de UI / linguagem meu time já conhece", e o resto decorre disso.
Compartilhar:
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.