Ask HN: Si fueras a construir una aplicación web hoy, ¿qué stack tecnológico elegirías?
Elegir un stack tecnológico para una nueva aplicación web hoy suele depender de un equilibrio entre productividad del desarrollador, estabilidad a largo plazo y cuán interactiva necesita ser la aplicación. Muchos ingenieros prefieren stacks monolíticos “aburridos” y bien establecidos como Rails, Django, Laravel, Go o .NET con renderizado del lado del servidor, a menudo combinados con herramientas como HTMX o Hotwire y respaldados por Postgres o SQLite, citando la facilidad de despliegue y mantenimiento en un hosting VPS simple. Otros optan por ecosistemas modernos de JavaScript como Next.js, SvelteKit o stacks basados en React para experiencias de cliente más ricas, aunque advierten sobre la rotación de frameworks y enfatizan que la mejor elección suele ser aquello que ya conoces bien como para lanzar algo rápido.
Criterios generales de decisión
- El consejo más común: elige el stack con el que ya eres rápido y te sientes cómodo, especialmente para proyectos por pasión o trabajo en solitario.
- Preocupación secundaria: elige tecnología “aburrida”, estable y bien documentada, fácil de mantener y para la que sea sencillo contratar, en lugar de la última tendencia.
- Distinción entre objetivos:
- Entregar/terminar algo: usa frameworks monolíticos conocidos.
- Aprender: elige deliberadamente stacks nuevos (Rust, Go, HTMX, etc.).
- El tipo de aplicación importa:
- “Sitios web” simples: stacks renderizados en servidor con JS mínimo.
- “Apps” altamente interactivas: SPA o frameworks de cliente más ricos.
Backends y frameworks full-stack
- Fuerte concentración en:
- Ruby on Rails (+ Hotwire/Turbo), a menudo con Kamal o similar para el despliegue.
- Django / Flask / otros frameworks de Python, frecuentemente combinados con HTMX o plantillas clásicas.
- Laravel / stacks de PHP, a menudo elogiados por sus funciones SaaS integradas.
- Elixir + Phoenix + LiveView, valorados por su concurrencia y estilo funcional.
- Go con frameworks mínimos (Gin, stdlib, pequeños routers) por simplicidad y rendimiento.
- .NET (ASP.NET, Blazor) y Java/Spring/Quarkus/Jakarta EE como opciones tipadas “aburridas pero sólidas”.
- Backends Node/TypeScript (Express, Nest.js, Fastify, Deno, Bun, SST).
Frontends y modelos de interacción
- División entre:
- React (a menudo con Next.js, Remix o T3) como “estándar de la industria” o al menos dominante.
- Svelte/SvelteKit, Vue, Angular como alternativas populares.
- HTMX, Hotwire, LiveView, plantillas clásicas + JS ligero (Alpine, Stimulus, jQuery) para evitar SPAs pesadas.
- Algunos prefieren modelos basados en WASM o similares a escritorio (Blazor, Yew, Go+WASM, Pascal→WASM).
Bases de datos y persistencia
- PostgreSQL es el valor predeterminado más citado.
- SQLite se recomienda con frecuencia para etapas tempranas o incluso para cargas bastante pesadas con muchas lecturas.
- Otras: MySQL/MariaDB, Redis, DynamoDB, Typesense, Meilisearch, LMDB, libsql/Turso, TiDB/YugabyteDB, etc.
Infraestructura y despliegue
- Muchos prefieren VPS simples / bare metal con Docker o scripts básicos en lugar de configuraciones complejas en la nube.
- Opiniones mixtas sobre serverless:
- A favor: escalado sin esfuerzo, genial para bases de usuarios muy pequeñas al principio.
- En contra: los costes pueden dispararse a escala, y las migraciones de vuelta a monolitos/microservicios son dolorosas.
Sentimiento sobre el desarrollo web moderno
- Frustración significativa con la rotación del ecosistema JavaScript y las herramientas de build; se ve como “parchear el navegador/JS”.
- Contraargumento: las herramientas modernas (React, Svelte, Vite, TypeScript) sí mejoran la DX cuando se usan con criterio.
- Nostalgia por épocas más simples (LAMP, Drupal, VB6/Delphi) y deseo de soluciones integradas, monolíticas y de larga vida útil.
- Las herramientas de codificación con IA se perciben como algo que reduce la barrera para adoptar stacks desconocidos.