Estudio: Horalis Crecimiento sin framework

Todas las fichas de investigación

• App: Horalis Crecimiento (projects/wealth-lens/) · Fecha: 15 de octubre de 2026 · Fase: E1 del plan Horalis
• Estado: solo estudio. No cambia código, métodos ni supuestos. Recoge hechos medidos y opciones. La decisión es de Marek.

Pregunta

¿Debería Horalis Crecimiento dejar Next.js y React y hacerse como las otras herramientas (Coste de vida, Inflación): páginas estáticas que Node genera desde TypeScript, con seed-kit y sin framework? ¿Qué ganaría, qué costaría y qué se arriesga?

El criterio es el de docs/direction.md: herramientas que funcionan años sin tocarlas, ligeras y privadas, con dependencias mínimas. La prueba de diez años (docs/prueba-diez-anos.md, fase E2) da la medida.

Hechos medidos (15 de octubre de 2026, sobre la fase D2)

Cómo se midió lo nuevo:

• wc -l sobre los archivos;
• grep -l '"use client"' y grep -lE '\buse(State|Effect|Reducer|SyncExternalStore|Memo|Callback|Ref|Id|Context)\b' en src/components;
• los paquetes, contados en package-lock.json: todos, y los que no son dev (de producción) y entre ellos los no optional;
• un script que comprime con gzip -9 el HTML de out/index.html, out/es.html y out/how-it-works.html, y cada /_next/static/… que nombran.

Las dos cifras de peso no miden lo mismo: la del README es la de su propio test. Ninguna de las dos es un dato de uso real.

Lo que ya no depende del framework

• Todo el cálculo (src/lib): la fórmula del crecimiento, la tasa de retiro, las metas, los «¿Y si…?», la década mala y el chequeo. Es TypeScript puro y se puede llevar tal cual.
• Los datos y las fuentes: vienen de seed-kit (official/, asset-history.ts, cost-of-living.ts).
• Sin conexión y la descarga (B4): el service worker es de seed-kit (writeOffline). El .zip ya trata Next como un caso aparte (nextAppOnDisk).

Lo que sí depende de React y Next

• El estado de la página: el plan, las metas y las preguntas, en hooks y en app-store.ts (useSyncExternalStore). Sin framework haría falta un estado propio y redibujar a mano, como hace app.ts en las otras herramientas, pero con muchas más piezas.
• Los gráficos: growth-chart.tsx, futures-view.tsx y history-charts.tsx dibujan SVG con JSX. Inflación dibuja su línea de tiempo como texto SVG en view.ts: se puede hacer igual.
• La carga diferida (next/dynamic, 5 archivos): partes que no se bajan hasta que se usan. Sin framework, import(), como el código de compartir desde D2 (seed-kit browser.ts, módulos lazy).
• Las páginas por idioma (app/(en), app/[lang]) y los metadatos de Next: los haría el build de seed-kit, como en las otras herramientas.
• Tailwind: las clases están en el JSX. Habría que pasarlas a CSS propio o a las clases de seed-kit.
• Los iconos (lucide-react, 14 usos): SVG en línea, como en el hub.

Opciones

1. Seguir con Next y React (lo de hoy).
   • A favor: no hay que reescribir nada, y funciona y está probado.
   • En contra:
     • 55 paquetes de producción que cambian de versión mayor cada año o dos (Next 13, octubre de 2022 → Next 16, octubre de 2025);
     • una primera visita 4–9 veces más pesada que las otras herramientas;
     • la herramienta no se puede construir con el molde de Forja.
2. Reescribir la interfaz sin framework, con seed-kit, como las otras herramientas.
   • A favor:
     • cero dependencias en ejecución;
     • una sola forma de hacer herramientas;
     • previsiblemente una primera visita cercana a las otras (estimación: 40–80 KB; sin medir hasta que exista);
     • el build en Node 22 sin nada más (los tests de navegador seguirían necesitando Playwright y npm).
   • En contra:
     • reescribir unas 5500–6000 líneas de interfaz (componentes, hooks, la parte de React de seed-kit) y su estado;
     • rehacer lo que hoy da Next: metadatos, canónicas, hreflang y las páginas por idioma, también la neerlandesa, oculta;
     • cambiar cómo se prepara para la descarga (hub/scripts/release.ts, nextAppOnDisk);
     • portar 43 tests de navegador;
     • riesgo de romper la accesibilidad conseguida en C1;
     • semanas de trabajo, no días.
3. Un framework pequeño (Preact, Lit…) en vez de React.
   • A favor: menos peso y reescritura parcial.
   • En contra: sigue habiendo una dependencia en ejecución, y otra forma de hacer herramientas.
4. React sin Next (Vite y una SPA estática).
   • A favor: quita Next.
   • En contra:
     • React sigue, y Vite entra como dependencia de desarrollo;
     • se pierde el HTML ya construido de cada página (hoy lo da Next);
     • se gana poco.
5. Guardar lo necesario para construirla, sin reescribir nada.
   • Guardar junto al .zip los paquetes exactos de package-lock.json (npm pack o una caché local de npm) y el Node con el que se construye. O tratar out/, ya construido, como lo que perdura.
   • A favor: casi sin trabajo; responde al riesgo de no poder construir dentro de diez años.
   • En contra: no quita el peso ni la forma distinta de hacer esta herramienta. Mantener esa copia es una tarea más, y un cambio en la herramienta sigue necesitando ese Next.

Lo discutible

• El coste de no hacer nada. Next y React no dejan de funcionar de un día para otro. Pero «años sin tocarlo» pide poder construir la herramienta dentro de diez años con lo que haya:
  • un paquete abandonado o un npm install que falla rompe el build;
  • un build de Node con TypeScript nativo, en cambio, depende solo de Node (prueba de diez años, E2).
• El riesgo de reescribir. El cálculo está separado y tiene 670 tests, así que el riesgo está en la interfaz, no en las cifras. Pero la interfaz es lo que se auditó en C1 (WCAG 2.2) y lo que la gente usa.
• El peso. 200–280 KB está muy por debajo del límite de 350 KB de los principios. La ganancia de peso es real, pero no es el motivo principal: el motivo es depender de menos.

Si se decide reescribir: un orden posible

1. Congelar la interfaz actual: capturas de pantalla de cada vista y lista de comportamientos (los 43 tests de navegador ya lo son).
2. Construir con seed-kit las páginas sin interacción: Cómo funciona, Acerca de, Tus datos y Condiciones. Comparar el HTML.
3. Pasar la portada a plantillas de seed-kit con el mismo src/lib. El estado vive en un módulo propio, sin React. Los gráficos se dibujan como SVG en texto.
4. Portar los 43 tests de navegador y la auditoría de accesibilidad; los tests de src/lib no cambian.
5. Publicar las dos versiones en paralelo y cambiar cuando la nueva pase todo. Las elecciones guardadas por la gente (importar y exportar sus datos) deben seguir abriéndose.

Cada paso tiene su PR y su revisión, como el resto del plan.

Pendiente de comprobar a mano (Marek)

• Si la prioridad de «años sin tocarlo» justifica semanas de reescritura ahora, o después de lanzar.
• Si el estado guardado de la gente (archivo de datos de «Descargar mis datos») debe seguir siendo compatible, y por cuánto tiempo.

Historial

• 15 de octubre de 2026: estudio inicial (fase E1). Sin cambios de código.