No necesitas React: creando una biblioteca UI mínima en JavaScript puro

Artículo original ↗ Discusión en Hacker News ↗

Una entrada de blog que propone una diminuta biblioteca UI en JavaScript puro como alternativa a React reaviva el debate sobre cuándo se justifican los frameworks pesados. Los comentaristas cuestionan el uso que hace el autor de “modo inmediato” sobre el DOM y señalan retos como la gestión del estado, el rendimiento del DOM y los casos límite que resuelven los frameworks completos, mientras otros elogian el experimento por ser educativo y destacan lo pequeña que es la biblioteca. En términos más generales, se debate si la mayoría de las aplicaciones web realmente necesitan herramientas al estilo React frente a HTML/CSS/JS más simples o alternativas más ligeras como Preact o Astro, especialmente en una era en la que la IA puede generar gran parte del código repetitivo.

Reacción general a la mini biblioteca UI

  • A algunos les parece que el proyecto es educativo y les gusta que muestre cuán poco JS puede impulsar un sitio completo.
  • Otros creen que el código de ejemplo (p. ej., tres en raya) demuestra por qué React o frameworks similares son valiosos.
  • Unos pocos lectores dicen explícitamente que les alegra ver experimentos y alternativas, aunque estén incompletos.

React frente a “no necesitas React”

  • Muchos sostienen que React se usa en exceso, especialmente para sitios simples, con mucho contenido o interactividad básica.
  • Otros responden que, si de todos modos vas a necesitar funciones tipo React más adelante, quizá convenga empezar con React (o Preact/Vue/Svelte/etc.).
  • Algunos ven los mini frameworks como algo que se queda corto frente a los principales problemas que React resuelve: gestión de estado, diffing, planificación y actualizaciones complejas del DOM.

Modo inmediato vs modo retenido

  • Varios comentaristas dicen que el artículo usa mal “modo inmediato”; el renderizado basado en DOM es inherentemente modo retenido.
  • Hay debate sobre si React es “modo inmediato sobre el DOM”, pero el consenso en el hilo se inclina por “no, es retenido”.
  • Algunos señalan que fingir que el DOM es de modo inmediato conduce a problemas como la pérdida del estado de entrada.

Rendimiento, tamaño y complejidad

  • Se elogia a la biblioteca por ser muy pequeña (~2–3 kB), con páginas completas de alrededor de ~60 kB de JS.
  • Contraargumento: Preact ya es diminuto, así que el tamaño por sí solo no justifica una biblioteca a medida.
  • Varios comentaristas subrayan que los enfoques triviales de pub/sub o de “volver a renderizar todo” no escalan; los frameworks modernos invierten mucho en reactividad de grano fino y planificación del DOM.

Casos de uso: sitios simples frente a aplicaciones complejas

  • Muchos sostienen que la mayoría de los sitios podrían ser HTML/CSS puros o renderizados en el servidor con poco JS; las SPA y React son excesivos para la típica CRUD o un blog.
  • Otros que trabajan en aplicaciones complejas y muy interactivas (p. ej., formularios enormes, modo offline, accesibilidad) dicen que frameworks como React mejoran materialmente el mantenimiento y la productividad del equipo.

IA/LLMs, DX y ecosistema

  • Algunos afirman que la elección del framework importa menos en la “era de la IA” porque los LLM pueden generar y refactorizar código, incluso migrarlo a otra plataforma más adelante.
  • Otros discrepan: el diseño del framework, el rendimiento y los ecosistemas de SDK (p. ej., CMS headless que favorecen React/Next) siguen influyendo mucho en las decisiones del mundo real.