Ask HN: Se você fosse construir um app web hoje, qual stack de tecnologia escolheria?

Discussão no Hacker News ↗

Escolher uma stack de tecnologia para um novo app web hoje geralmente se resume a um tradeoff entre produtividade do desenvolvedor, estabilidade de longo prazo e o quão interativo o app precisa ser. Muitos engenheiros preferem stacks monolíticas “chatas” e bem estabelecidas como Rails, Django, Laravel, Go ou .NET com renderização no servidor, muitas vezes combinadas com ferramentas como HTMX ou Hotwire e apoiadas por Postgres ou SQLite, citando facilidade de deployment e manutenção em hospedagem VPS simples. Outros optam por ecossistemas modernos de JavaScript, como Next.js, SvelteKit ou stacks baseadas em React, para experiências mais ricas no cliente, ao mesmo tempo em que alertam sobre a rotatividade de frameworks e enfatizam que a melhor escolha geralmente é aquela que você já conhece bem o suficiente para entregar rápido.

Critérios gerais de decisão

  • O conselho mais comum: escolha a stack com a qual você já é rápido e confortável, especialmente para projetos pessoais ou trabalho solo.
  • Preocupação secundária: escolha tecnologia “chata”, estável e bem documentada, fácil de manter e para a qual seja fácil contratar, em vez da última tendência.
  • Distinção entre objetivos:
    • Entregar/concluir algo: use frameworks monolíticos familiares.
    • Aprender: escolha deliberadamente stacks novas (Rust, Go, HTMX, etc.).
  • O tipo de app importa:
    • “Sites” simples: stacks renderizadas no servidor com JS mínimo.
    • “Apps” altamente interativos: SPA ou frameworks de cliente mais ricos.

Backends e frameworks full-stack

  • Forte concentração em:
    • Ruby on Rails (+ Hotwire/Turbo), muitas vezes com Kamal ou algo similar para deployment.
    • Django / Flask / outros frameworks Python, frequentemente combinados com HTMX ou templates clássicos.
    • Stacks Laravel / PHP, frequentemente elogiadas por recursos SaaS “batteries included”.
    • Elixir + Phoenix + LiveView, valorizados por concorrência e estilo funcional.
    • Go com frameworks mínimos (Gin, stdlib, pequenos routers) por simplicidade e desempenho.
    • .NET (ASP.NET, Blazor) e Java/Spring/Quarkus/Jakarta EE como opções tipadas “chatas, mas sólidas”.
    • Backends Node/TypeScript (Express, Nest.js, Fastify, Deno, Bun, SST).

Frontends e modelos de interação

  • Divisão entre:
    • React (muitas vezes com Next.js, Remix ou T3) como “padrão da indústria” ou pelo menos dominante.
    • Svelte/SvelteKit, Vue, Angular como alternativas populares.
    • HTMX, Hotwire, LiveView, templates clássicos + JS leve (Alpine, Stimulus, jQuery) para evitar SPAs pesadas.
  • Alguns preferem modelos baseados em WASM ou com aparência de desktop (Blazor, Yew, Go+WASM, Pascal→WASM).

Bancos de dados e persistência

  • PostgreSQL é o padrão mais citado.
  • SQLite é frequentemente recomendado para fases iniciais ou até para cargas razoavelmente pesadas com leitura predominante.
  • Outros: MySQL/MariaDB, Redis, DynamoDB, Typesense, Meilisearch, LMDB, libsql/Turso, TiDB/YugabyteDB, etc.

Infraestrutura e deployment

  • Muitos preferem VPS simples / bare metal com Docker ou scripts básicos em vez de configurações complexas de cloud.
  • Opiniões mistas sobre serverless:
    • Prós: escalabilidade sem esforço, ótimo para bases iniciais bem pequenas.
    • Contras: os custos podem explodir em escala, e migrações de volta para monólitos/microserviços são dolorosas.

Sentimento sobre o desenvolvimento web moderno

  • Frustração significativa com a rotatividade do ecossistema JavaScript e com ferramentas de build; visto como “remendar o navegador/JS”.
  • Contraponto: ferramentas modernas (React, Svelte, Vite, TypeScript) realmente melhoram a DX quando usadas com discernimento.
  • Nostalgia por épocas mais simples (LAMP, Drupal, VB6/Delphi) e desejo por soluções monolíticas, integradas e de longa duração.
  • Ferramentas de codificação com IA são vistas como reduzindo a barreira para adotar stacks desconhecidas.