La fatiga del frontend: cómo elegir stack sin volverte loco

Intro con gancho

Son las 11:48 pm. Ya cerraste la laptop dos veces, pero Slack no perdona: “¿sí llegamos al release?”. Abres el repo y ahí está la escena del crimen: React con un router a medio migrar, Tailwind con overrides que nadie entiende, dos formas de hacer fetch, y un README que jura “simple setup” (mentira piadosa).

Y de pilón: tu compa te manda un hilo en X de “SvelteKit es el futuro”, tu lead te pide “Next sí o sí”, y el cliente nomás quiere que la landing cargue rápido porque acá la banda navega con datos medidos y Wi‑Fi caprichoso.

Esa sensación de que el ecosistema frontend nunca se detiene y tú solo quieres construir sin perder la cordura tiene nombre: fatiga del frontend. No se quita consumiendo más hype. Se baja tomando decisiones con colmillo.

Qué te vas a llevar

• Cómo separar dolor real (performance, DX, mantenibilidad) de ansiedad por moda.
• Un método simple para elegir stack con criterios que sí pegan en la chamba.
• Cuándo conviene React/Next, Vue/Nuxt, Svelte/SvelteKit o “vanilla + Vite” (sí, a veces gana).
• Cómo armar un mini‑POC de 2–4 horas para decidir sin junta eterna.
• Errores típicos que te dejan con un stack Frankenstein (y cómo no morir en production).

Por qué el frontend cansa más de lo normal

La bronca no es “aprender frameworks”. La bronca es la cantidad de decisiones que van pegadas entre sí:

• Demasiadas piezas acopladas: framework, router, state, data fetching, forms, styling, testing, build, deploy. Mueves una y tiemblan tres.
• Timeline de producto vs timeline de tecnología: el negocio quiere features esta semana; el stack nuevo quiere onboarding, patrones y disciplina.
• La vida real del equipo: entra un junior, el freelance rota, el founder técnico trae prisa, soporte pide hotfix. El stack tiene que aguantar ese ritmo.
• Infra y presupuesto aterrizados: deploy en Vercel está nice… hasta que crece el tráfico o el CFO pregunta “¿por qué subió la factura?”. Y sí, todavía hay lugares con server compartido y un sysadmin que odia Node porque le tocó mantenerlo mal.

La salida no es “elige el mejor framework”. Es: elige el stack que te baja fricción en TU contexto.

Guía práctica para elegir stack sin volverte loco

Paso 0: define el juego (la pregunta correcta)

Antes de React vs Vue, define esto en una sola frase:

“Necesitamos un stack para construir X, con Y equipo, en Z plazo, corriendo en W infraestructura, optimizando para Q.”

Ejemplos que sí pasan:

• “Dashboard interno con 20 pantallas, equipo de 3 (1 junior), entrega incremental, deploy en AWS, optimizar para mantenibilidad.”
• “Marketing site + blog con SEO fuerte, soy yo solo, deadline de 2 semanas, deploy simple, optimizar para performance y contenido.”
• “App B2C con login y pagos, equipo de 5, optimizar para velocidad de iteración y estabilidad en production.”

Si no haces esto, terminas eligiendo por TikTok técnico y luego viene el rollback emocional.

Paso 1: arma una matriz de decisión (en corto, pero con números)

Ponle score. No para “ganar” la discusión, sino para aterrizarla.

Haz una tabla con pesos (0–5) según tu realidad:

• Time to first feature (¿cuánto tardas en sacar la primera pantalla real?)
• Onboarding (¿qué tan rápido se integra alguien nuevo?)
• Mantenibilidad (convenciones, estructura, refactors)
• Ecosistema (librerías, comunidad, hiring)
• Performance (Web Vitals, bundle size, SSR/SSG)
• Testing (unit/e2e, facilidad de mock)
• Deploy & costos (hosting, caching, edge, observabilidad)
• Riesgo (madurez, breaking changes, bus factor)

Tip de guerra: no metas más de 8 criterios. Si metes 20, ya estás justificando una decisión emocional.

Paso 2: define tus “no negociables”

Tres a cinco cosas que sí o sí deben existir. Ejemplos:

• “SSR/SSG por SEO y performance”
• “TypeScript obligatorio”
• “Forms complejas con validación decente”
• “E2E con Playwright/Cypress desde el día 1”
• “Auth sin depender de un plugin random”

Esto recorta opciones rápido y baja ansiedad.

Paso 3: clasifica el tipo de producto (esto decide más de lo que parece)

A) Sitio de contenido / marketing (SEO y performance)

• Prioridad: SSR/SSG, imágenes, routing simple, contenido, analítica.
• Opciones típicas:
  • Next.js (si ya traes React y quieres SSR/SSG con ecosistema enorme)
  • Nuxt (si el equipo fluye con Vue)
  • Astro (si es contenido-first y quieres mandar menos JS)

B) App interna / dashboard

• Prioridad: velocidad de desarrollo, forms, tablas, permisos, mantenibilidad.
• Opciones típicas:
  • React + Vite (simple, flexible)
  • Vue + Vite (DX muy agradable)
  • Meta-framework (Next/Nuxt) solo si neta necesitas SSR o conventions por rutas.

C) Producto B2C (auth, pagos, edge cases, “production de verdad”)

• Prioridad: observabilidad, patterns, performance, escalabilidad del equipo.
• Opciones típicas:
  • Next.js (App Router o Pages según madurez del equipo)
  • Remix (si te late lo web-native y el flujo de forms/actions)
  • Nuxt (si Vue es tu base)

Paso 4: elige el “centro” del stack (y no lo cambies cada sprint)

La fatiga sube cuando el equipo no tiene columna vertebral.

Tu centro casi siempre es:

• Framework + router (Next/Nuxt/SvelteKit o Vite + router)
• Estrategia de datos (REST/GraphQL; TanStack Query; server actions; tRPC)
• Estilos (Tailwind vs CSS Modules vs UI library)

Decisión útil: menos piezas, mejor integradas.

Ejemplo honesto:

• Si tienes equipo mixto (junior + gente que viene de jQuery/WordPress), un stack con demasiada magia te va a cobrar con bugs raros y PRs eternos.
• Si tu equipo ya domina React, cambiar “porque se ve cool” cuesta onboarding, nuevos errores, y meses de “¿por qué aquí se hace así?”.

Paso 5: haz un mini‑POC que simule tu dolor real

No hagas “Hello World”. Haz 3 cosas que te van a explotar en production cuando el jefe pida “un cambio rápido” a las 6:30 pm.

POC de 2–4 horas (checklist):

1. Una pantalla con lista + filtro + paginación (o infinite scroll)
2. Un form con validación y estados (loading, error, success)
3. Un flujo de auth fake (o mínimo guard + redirect)
4. Deploy a un entorno real (preview) y mide:
   • tamaño del bundle
   • LCP/CLS (aunque sea con Lighthouse)
   • complejidad percibida del código

Luego contesta en frío:

• ¿Cuántas líneas fueron “de framework” vs líneas de negocio?
• ¿Qué tan legible queda para alguien nuevo?
• ¿Dónde te atoraste? (docs confusas, tooling, TS, routing)

La mejor elección de stack suele salir de aquí, no del debate.

Paso 6: guía rápida de decisión (sin humo)

No hay “ganador absoluto”. Hay ganadores por contexto.

Si tu equipo ya es React y necesitas SSR/SEO: Next.js

• Pros: ecosistema, hiring, SSR/SSG, buena integración con Vercel.
• Contras: cambios de paradigma (App Router), decisiones internas que cambian, riesgo de complejidad si mezclas patterns.
• Consejo de batalla: define convenciones desde el inicio (carpetas, fetching, caching). Si no, el repo se vuelve multiverso.

Si quieres DX suave y Vue ya es familiar: Nuxt

• Pros: convenciones claras, DX cómoda, SSR listo.
• Contras: si tu mercado local es React-heavy, puede doler el hiring (depende de ciudad y industria).

Si quieres menos JS y un sitio rápido: Astro

• Pros: performance, contenido-first, puedes hidratar solo donde hace falta.
• Contras: para dashboard grande, no siempre es el camino más directo.

Si tu app es más “web clásica” (forms, actions): Remix

• Pros: enfoque web-native, forms y server logic muy claros.
• Contras: menos mainstream que Next; el equipo tiene que comprar la filosofía.

Si quieres simplicidad para app interna: Vite + framework + router

• Pros: control, menos magia, setup rápido.
• Contras: tú pones las reglas; si el equipo no es disciplinado, termina en “cada quien su estilo”.

Stacks recomendados (para decidir más rápido)

Opción 1: “Equipo React pragmático” (producto o dashboard)

• React + Vite
• TypeScript
• React Router (si no necesitas SSR)
• TanStack Query para server state
• Zod + React Hook Form
• Tailwind o CSS Modules
• Vitest + Testing Library; Playwright para e2e

Opción 2: “SEO serio + app moderna”

• Next.js + TypeScript
• App Router (solo si el equipo ya lo entiende; si no, Pages sigue siendo opción válida en muchos casos)
• Zod para validación
• Playwright para e2e
• Observabilidad: Sentry + logs decentes

Opción 3: “Vue bien hecho”

• Nuxt + TypeScript
• Pinia (si necesitas state global)
• VueUse para utilidades
• Playwright/Cypress

Opción 4: “Contenido-first y performance”

• Astro
• Componentes aislados (React/Vue solo donde haga falta)
• MDX o content collections

Screenshots sugeridos

• Captura de una matriz de decisión (Notion/Google Sheets) con pesos y scores.
• Comparación de Lighthouse (mobile) entre dos POCs (mismo contenido, distinto stack).
• Ejemplo de estructura de carpetas con “convención mínima” del stack elegido.
• Pull request con checklist de “definición de listo” (tests, lint, types).

Errores comunes (y cómo salir del hoyo)

Error 1: elegir stack por “lo que se ve cool”

Síntoma: arrancas motivado y a la semana estás peleándote con tooling, docs y setups frágiles… en una laptop vieja que ya suena como avión.

Arreglo: regresa a la frase del Paso 0. Si el stack no reduce fricción del producto, es deuda (y te va a cobrar con intereses).

Error 2: mezclar paradigmas sin querer

Clásico: SSR + client fetching duplicado + cache inconsistente. El bug aparece, desaparece, y nadie sabe por qué.

Arreglo: define una regla base:

• “Server-first” (SSR/loader/actions) o
• “Client-first” (SPA con Query)

Se puede mezclar, pero con intención y límites claros. Si no, el bugfix se vuelve lotería.

Error 3: subestimar el costo de onboarding

Acá es común: alguien se va por mejor oferta, entra alguien con otro background, o el freelance se desaparece porque lo cotizaste barato y ya agarró otro jale.

Arreglo: documenta 5 cosas (sin poema):

1. cómo correr el proyecto
2. cómo hacer deploy
3. cómo se estructura el código
4. cómo se hacen tests
5. cómo se decide una librería nueva

Error 4: “Sí usamos TypeScript”… pero a medias

Síntoma: any por todos lados, tipos copiados, y el runtime te cobra la factura en production.

Arreglo: reglas simples:

• noImplicitAny on
• Zod (o equivalente) para validar input externo
• tipa tus boundaries: API, forms, props principales

Error 5: ignorar costos de deploy y caching

Ese preview environment infinito se siente gratis… hasta que llega la factura o te pega un rate limit el día que más prisa tienes.

Arreglo: define desde el inicio:

• dónde cacheas
• qué corre en server
• qué corre en edge
• qué se pre-renderiza

Checklist final (decide y sigue con tu vida)

• Tengo una frase clara de “qué estamos construyendo y para quién”.
• Tengo 3–5 no negociables (SSR, TS, testing, etc.).
• Hice una matriz con máximo 8 criterios y pesos reales.
• Corrí un mini‑POC con lista+filtro, form, auth/guard y deploy.
• Definí el centro del stack (framework+router, data, styles).
• Acordamos convenciones mínimas de estructura y code review.
• Quedó documentado el onboarding básico.
• Tenemos plan de observabilidad (errores, logs) para production.

FAQ

1) ¿Cómo sé si es fatiga del frontend o solo me falta practicar?

Si cambias de stack cada que te pega la inseguridad, es fatiga. Practicar ayuda, pero la señal es la parálisis por opciones y el “todo se siente mal”. La cura: limitar opciones y ejecutar un POC.

2) ¿React ya murió? ¿Me muevo a Svelte/Vue sí o sí?

No. React sigue siendo súper viable, sobre todo por ecosistema y hiring. Cambiar vale la pena cuando tu contexto lo justifica (performance, DX, equipo, tipo de producto), no por el timeline de memes.

3) ¿Next.js es obligatorio para jalar de frontend?

No, pero sí es común en el mercado. Aprenderlo abre puertas. Eso no significa que sea la mejor opción para cualquier proyecto. Para dashboard interno, muchas veces Vite + SPA es más simple y estable.

4) ¿Qué hago si mi equipo no se pone de acuerdo?

Definan criterios y pesos antes de mencionar frameworks. Luego POC corto con 2 finalistas. Si siguen empatados, decide por ecosistema/hiring o por lo que el equipo ya domina. El costo de indecisión es real (y se paga con deadlines).

5) ¿Cómo evito que el stack crezca sin control?

Pon una regla de entrada: “Nueva librería = problema concreto + alternativa descartada + plan de mantenimiento”. Y mantén un README vivo con decisiones (mini ADRs). Eso baja el Frankenstein.

Siguiente episodio

Ya con el stack elegido, toca el verdadero boss fight: convenciones y arquitectura para que el repo no se vuelva un multiverso.

Vamos a armar una guía mínima de estructura, patrones y límites para escalar sin perder velocidad.