Por qué migré de React CRA a Next.js (y no me arrepiento)

Create React App tuvo su momento. Fue la forma más fácil de arrancar un proyecto React durante años. Pero en 2024, la realidad es clara: CRA está abandonado, lleno de vulnerabilidades, y el ecosistema ha evolucionado enormemente.

Esta es la historia de por qué migré este mismo blog de CRA a Next.js 14, y qué aprendí en el proceso.

El problema con CRA

Cuando revisé el proyecto original, npm audit reportaba más de 60 vulnerabilidades. Algunas críticas. La última versión estable de CRA lleva sin actualizarse desde 2022.

Pero las vulnerabilidades son solo la punta del iceberg. Los problemas reales eran:

• Sin SSR/SSG: Todo se renderizaba en el cliente. SEO horrible.
• Bundle size descontrolado: Sin code splitting automático.
• Sin optimización de imágenes: Cada imagen se servía tal cual.
• Routing manual: React Router añadía complejidad sin necesidad.

Por qué Next.js 14 con App Router

Consideré varias alternativas: Vite, Remix, Astro. Cada una tiene sus ventajas. Elegí Next.js por tres razones:

1. App Router es el futuro de React

El App Router de Next.js 13+ no es solo una mejora de routing. Es una implementación de React Server Components — el modelo mental que el equipo de React lleva años construyendo. Aprender App Router es aprender el futuro de React.

2. Zero-config pero sin límites

Configuré SSR, optimización de imágenes, fuentes web con zero-layout-shift y generación estática de páginas en menos de una tarde. Sin plugins, sin configuración de webpack.

3. Vercel como target de deploy

Si el destino final es Vercel (spoiler: lo es), Next.js es la combinación obvia. Edge functions, analytics, previews automáticos por PR.

El proceso de migración

La migración no fue un big bang. La hice por fases:

Fase 1: Setup + SSR de styled-components
Fase 2: Navbar, Sidebar, Footer
Fase 3: Landing page (6 secciones)
Fase 4: Páginas individuales (About, Contact, Blog)

Lo más difícil: styled-components en SSR

Styled-components necesita un registry especial para funcionar con Server Components. Sin él, hay un flash of unstyled content (FOUC) en cada carga.

La solución es un StyledComponentsRegistry que inyecta los estilos críticos en el HTML del servidor:

'use client'
import { useServerInsertedHTML } from 'next/navigation'
import { ServerStyleSheet, StyleSheetManager } from 'styled-components'
 
export default function StyledComponentsRegistry({ children }) {
  const [styledComponentsStyleSheet] = useState(() => new ServerStyleSheet())
 
  useServerInsertedHTML(() => {
    const styles = styledComponentsStyleSheet.getStyleElement()
    styledComponentsStyleSheet.instance.clearTag()
    return styles
  })
 
  return (
    <StyleSheetManager sheet={styledComponentsStyleSheet.instance}>
      {children}
    </StyleSheetManager>
  )
}

Lo más fácil: las fuentes

next/font es magia. Descarga las fuentes en build time, las sirve desde tu propio dominio, y elimina el layout shift. Cero configuración de Google Fonts, cero tracking externo.

Resultados

La diferencia en Lighthouse fue notable:

• Performance: 54 → 94
• SEO: 67 → 100
• Accessibility: 81 → 95

El bundle inicial bajó un 40% gracias al code splitting automático y a eliminar dependencias de CRA.

Lo que cambiaría

Si empezara de cero hoy, consideraría Tailwind CSS en lugar de styled-components. No porque styled-components sea malo — es excelente — sino porque Tailwind tiene mejor soporte para Server Components y zero runtime CSS.

Pero dado que el proyecto ya existía con styled-components, migrar habría sido un refactor enorme por un beneficio marginal. A veces la pragmática gana a la pureza técnica.

Conclusión

Si tienes un proyecto en CRA, migra. No mañana, ahora. El coste técnico de no hacerlo crece cada mes. Next.js 14 con App Router no es solo una mejora — es un cambio de paradigma que vale la pena entender.