El camino hacia una web más sostenible y controlada

De la reactividad a las raíces. Mi viaje de Svelte a PHP nativo para recuperar el control.

En el vertiginoso mundo del desarrollo web, la elección de tecnologías es un desafío constante. Constantemente aparecen nuevas herramientas y frameworks, cada uno con promesas de eficiencia y modernidad que, naturalmente, atraen la atención de cualquier desarrollador. Mi propio viaje técnico, al decidir construir myhappyplace.dev – un sitio con blog para dar visibilidad a la Ingeniera de Software Gemma Lara – comenzó precisamente así: apostando por Svelte 4, un framework conocido por su innovador enfoque de compilación y su potencial de rendimiento. Sin embargo, lo que no sabía entonces era que este camino me llevaría por una ruta inesperada, culminando en un regreso a las raíces: PHP nativo y JavaScript vanilla.

En este artículo, quiero compartir contigo los pormenores de esa evolución sorprendente. Exploraré mi experiencia inicial con Svelte 4, los retos que surgieron (especialmente al considerar la migración a Svelte 5), y las razones de fondo que me impulsaron a buscar una vía más sostenible y con mayor control a largo plazo a través de PHP 8 y JavaScript para este proyecto específico. Mi objetivo es que esta reflexión, cargada de lecciones aprendidas, sea valiosa tanto si eres un cliente interesado en la solidez de las decisiones tecnológicas, como si eres un colega desarrollador navegando en el complejo panorama actual.

El comienzo con Svelte 4: una nueva herramienta

Decidí construir un sitio web utilizando un framework moderno, optando por Svelte 4, que apuntaba muy bien por sus peculiaridades. La idea de compilar los componentes en JavaScript eficientemente y crear componentes aislando el código (script, markup, css) me atrajo. Utilizar SvelteKit prometía, además, un rendimiento excelente. La experiencia de desarrollo inicial me encantó; la sintaxis elegante y la reactividad funcionaba casi mágicamente con poco código boilerplate.

Construir el blog con Svelte 4 fue, en muchos aspectos, una buena experiencia. Creé componentes reutilizables para elementos de la UI, gestioné el estado de la aplicación (aunque simple para un sitio web tipo blog) y aproveché su sistema de routing. Parecía ideal utilizar una herramienta moderna y eficiente para el proyecto.

En Svelte, los componentes son la unidad fundamental. Se definen en archivos .svelte y pueden incluir hasta tres bloques opcionales: <script> (lógica), la sección de markup (HTML) y <style> (estilos). Son reutilizables.

El desafío de la evolución: migrar a Svelte 5

El cambio de Svelte de la versión 4 a la 5 me llevó a considerar seriamente una posible migración. Como desarrolladora, mantengo un interés constante en la evolución de las herramientas que utilizo y en las tendencias del ecosistema web. El dinamismo del desarrollo de Svelte, sumado a las prometedoras mejoras de la versión 5 —como por ejemplo las runas (runes: $state, $derived y $effect) para una reactividad más explícita, gestionar el estado y sus dependencias dentro de los componentes—, me impulsó a considerar seriamente probarla con el objetivo de asegurar la longevidad y el rendimiento futuro de mi proyecto web.

Ejemplo de uso de un estado y un valor derivado en Svelte 4 vs. Svelte 5 con runes

Supongamos algo muy sencillo como que tengo un contador simple y quiero mostrar si el número es par o impar.

En Svelte 4 (reactividad implícita con y declaraciones reactivas):

En Svelte 5 (reactividad explícita con $state y $derived):

¿Cómo ilustra esto la "reactividad más explícita"?

En Svelte 4, se usa una sintaxis estándar de JavaScript (let,=) y una sintaxis especial de Svelte ($:) para indicar reactividad después de haber declarado las variables. Una asignación a una variable let podría ser reactiva dependiendo del contexto, y $: crea dependencias reactivas.

En Svelte 5 con runes, usamos $state() y $derived() en el momento de la declaración para definir qué tipo de variable es en términos de reactividad: ¿es una pieza de estado que puede cambiar ($state())? ¿Es un valor que se calcula a partir de otro ($derived())? La intención reactiva de la variable es clara desde la primera línea donde la vemos declarada. Esto reduce la "magia" y hace el flujo de datos y dependencias más visible y fácil de entender, especialmente en componentes más complejos.

Sin embargo, la migración de Svelte 4 a Svelte 5 resultó ser un desafío mayor de lo esperado para un proyecto relativamente simple. Si bien Svelte proporciona guías, adoptar plenamente el nuevo modelo de reactividad con runes implicó refactorizar gran parte del código existente. No fue un simple cambio de versión, requirió tiempo para entender los nuevos patrones y adaptar mis componentes.

Este proceso, aunque educativo y emocionante, me hizo reflexionar. Para un proyecto de sitio web ¿realmente justificaba la inversión de tiempo y esfuerzo que implicaba seguir el ritmo de las actualizaciones de un framework?

El punto de inflexión: ¿necesito realmente un framework para crear un sitio web?

Fue en este punto, tras invertir tiempo en la migración a Svelte 5, cuando me detuve a evaluar las necesidades de mi proyecto web y el costo de mi elección tecnológica.

Un framework como Svelte (o React, Vue, Angular, etc.), aunque excelente para construir Single Page Applications (SPAs) ricas en interactividad, parecía un exceso. Las posibles incompatibilidades futuras y la gestión del build process empezaron a sentirse como una carga innecesaria para la simplicidad que buscaba.

Necesitaba tener un mayor control. Quería entender exactamente cómo se generaba cada byte de la página, sin capas de abstracción significativas, ni dependencias de terceros que no pudiera justificar plenamente. Quería reducir las dependencias externas al mínimo posible para simplificar el mantenimiento a largo plazo y reducir la superficie de posibles problemas de compatibilidad o seguridad ligados a librerías de terceros.

Volviendo a las raíces: PHP 8 nativo y JavaScript vanilla

La decisión estaba tomada, era hora de volver a lo básico. Opté por reconstruir el sitio web utilizando PHP 8 nativo en el lado del servidor y JavaScript vanilla (puro) para cualquier interactividad necesaria en el frontend.

Para entender las reflexiones que me llevaron a buscar una web más sostenible y controlada, es crucial recordar cómo funciona PHP:

• PHP se ejecuta en el servidor remoto donde está alojado el sitio web, no en el dispositivo del visitante.
• Esta ejecución ocurre antes de que el navegador reciba el documento HTML.
• El código PHP en el servidor no es accesible ni modificable por los visitantes de la web.

PHP 8 ha evolucionado enormemente. Con características como el JIT (Just-In-Time Compilation), atributos, match expressions y mejoras en el tipado, es un lenguaje robusto y eficiente para la lógica de servidor. Para cualquier sitio web, PHP es ideal para gestionar las publicaciones, interactuar con la base de datos (si la hay), manejar formularios y, crucialmente, renderizar el HTML directamente en el servidor. Esto no solo simplifica la arquitectura, sino que es intrínsecamente bueno para el SEO y la velocidad de carga inicial.

Para el frontend, decidí usar JavaScript vanilla. ¿Necesito manipular el DOM? Lo hago directamente. ¿Necesito hacer una llamada AJAX? Uso fetch. ¿Necesito una pequeña animación o validar un formulario? JavaScript puro es más que suficiente. No hay un framework que inicializar, ni un Virtual DOM que gestionar, ni un proceso de bundling complejo para el JavaScript del frontend (más allá de lo que un servidor web ya maneja).

Las ventajas de la simplicidad y el control

Este cambio a PHP nativo y JavaScript vanilla, aunque implicó reescribir código, me devolvió un control total y simplificó varios aspectos del proyecto.

1. Control total: Ahora entiendo cada parte del proceso, desde cómo se recibe una petición en el servidor PHP hasta cómo se actualiza un pequeño elemento con JavaScript. No hay "magia" del framework que no pueda desentrañar fácilmente.

2. Coste/Simplicidad de despliegue y hosting: Poner la web "en vivo" con Svelte (y SvelteKit) requería un proceso de build previo complejo y, a menudo, un hosting que soportara Node.js, que suele tener un coste más elevado. En contraste, con PHP nativo, el proceso es directo: subir archivos a un servidor web estándar (como Apache) con PHP. El hosting es más simple y económico, un punto clave para mí y relevante para cualquier cliente.

3. Mantenimiento del contenido (Workflow Editorial): Dado que el proyecto es un blog, la gestión y edición de los posts se realiza de forma muy sencilla utilizando archivos Markdown enriquecidos. Edito archivos de texto plano directamente, un workflow simple y directo. Comparado con un enfoque basado en frameworks que podría implicar un Headless CMS o una gestión de archivos similar pero con la capa adicional del proceso de build, el enfoque PHP nativo me resultó más directo.

4. SEO y Rendimiento Percibido: Es bien sabido que el Server-Side Rendering (SSR), como el que ofrece PHP, es beneficioso para el SEO. Al comparar la implementación con PHP nativo frente a la versión en Svelte (que también usaba SSR vía SvelteKit), no observé diferencias significativas en la indexación por parte de los motores de búsqueda ni en la velocidad de carga percibida por los usuarios. La carga inicial rápida, ventaja clave del SSR, se mantuvo similar. Las métricas de rendimiento, como los Lighthouse scores, fueron casi idénticas, confirmando un rendimiento comparable en este caso.

5. Manejo de formas: Los blogs suelen tener formularios (comentarios, contacto). Con PHP nativo y JavaScript vanilla, el manejo de estos formularios se aborda de forma estándar: el HTML del formulario, el envío de datos al servidor vía PHP para procesamiento y validación, y JavaScript vanilla para validación básica en el cliente o interacciones asíncronas si son necesarias (usando fetch). Esto es un enfoque robusto y bien entendido, sin depender de abstracciones de frameworks para la comunicación con el backend.

6. La "Complejidad escondida" del framework: Desde mi experiencia, los frameworks, si bien ofrecen simplificaciones en ciertas áreas, a menudo introducen su propia capa de complejidad. Esto se manifiesta en el proceso de build para producción, técnicas de optimización como el tree-shaking (eliminar código no utilizado), la configuración de bundlers (Webpack, Vite) y la integración de librerías externas. Esta "complejidad de herramientas" es un factor a considerar. Al trabajar con PHP nativo y JavaScript vanilla, esta capa de abstracción y las herramientas asociadas al build simplemente no existen, lo que me da un control más directo y una curva de aprendizaje centrada en los lenguajes fundamentales.

7. Alternativas no elegidas: Si bien el foco principal es Svelte vs PHP/Vanilla, consideré brevemente otras opciones como React (utilizando Next.js). Inicialmente, Svelte fue mi preferido sobre React, en parte por la practicidad de su estructura de componentes que integra script, template y css de forma cohesiva. Sin embargo, al considerar los meta-frameworks como SvelteKit o Next.js para obtener funcionalidades como el SSR, encontré que presentaban problemas similares a los que quería evitar: una capa de abstracción adicional, la necesidad de un proceso de build complejo, la gestión de dependencias y una menor sensación de control total. Esto reforzó mi conclusión de que, para un proyecto web simple como un blog, el tipo de herramienta (un framework SPA o meta-framework) no se ajustaba a mis necesidades, independientemente de la marca.

Para clientes y desarrolladores: ¿qué nos enseña esta experiencia?

Para clientes: Esta historia ilustra que la tecnología "más moderna" no siempre es la mejor o la más rentable a largo plazo para su proyecto específico. Una web corporativa con poca interactividad, una tienda online... a menudo pueden beneficiarse enormemente de enfoques más tradicionales pero robustos que ofrecen mayor estabilidad y menores costos de mantenimiento a largo plazo al reducir la complejidad y la dependencia de ecosistemas que evolucionan rápidamente. Pregunten siempre por qué se elige una tecnología y qué implica su mantenimiento futuro.

Para colegas desarrolladores: Los frameworks son herramientas poderosas y absolutamente necesarias para ciertos tipos de proyectos (SPAs complejas, aplicaciones con mucha lógica en el cliente). Sin embargo, caemos fácilmente en la trampa de usarlos por defecto, incluso para proyectos donde sus beneficios no superan los costos de complejidad y mantenimiento. Mi experiencia me recordó la importancia de:

• Entender las necesidades reales del proyecto: No sobredimensionar la solución tecnológica.
• Valorar el control y la simplicidad: Aumenta la robustez y es más fácil de mantener a largo plazo.
• Dominar los fundamentos: Un conocimiento sólido de PHP y JavaScript puro nos da la libertad de elegir la herramienta adecuada sin estar atados a un solo ecosistema de framework.

Conclusión

Ken Robinson, el renombrado educador y ferviente defensor de la creatividad, a menudo destacaba cómo el temor al error puede paralizar nuestro potencial creativo. Creo firmemente que los errores son intrínsecos y cruciales en muchas disciplinas creativas (arte, diseño, escritura, programación, etc.) y son una piedra angular en el proceso de aprendizaje iterativo y continuo que es vital para cualquier desarrollador.

Mi viaje de Svelte 4 a Svelte 5, y finalmente a PHP 8 nativo y JavaScript vanilla para el sitio web que desarrollé, no fue un rechazo a Svelte o a los frameworks en general. Fue una reevaluación pragmática de lo que mi proyecto realmente necesitaba. Aprendí que el control sobre el código y la simplicidad en las dependencias son activos valiosos, especialmente para proyectos que priorizan el contenido y la estabilidad a largo plazo sobre una interactividad frontend compleja.

Hoy, la web myhappyplace.dev funciona sobre una base sólida y predecible. Me hace sentir mejor sabiendo que no me espera una gran tarea de refactorización cada vez que sale una nueva versión principal de un framework o de alguna de las dependencias usadas. La "vuelta a lo básico" me dio, paradójicamente, una mayor sensación de libertad y control sobre mi proyecto web.

No me arrepiento de haber utilizado frameworks para el proyecto web; al contrario, me dio una visión más amplia. Espero que mi experiencia les inspire a cuestionar las decisiones tecnológicas y a elegir siempre la herramienta que mejor se adapte a las necesidades reales del proyecto.