Frontend simplificado: ¿Necesito un framework?

Desde el surgimiento de internet, y sobre todo desde la aparición de JavaScript, el desarrollo de páginas web y la orientación de sus funcionalidades ha variado enormemente.

Sin ir más lejos, las primeras páginas web en su origen no eran más que repositorios de información, en muchos casos carentes de estilo, y cuya funcionalidad estaba limitada generalmente a la navegación entre diferentes documentos HTML o una interacción básica con formularios, tendencia que podemos observar en la primera web existente, escrita por el propio creador de la web Tim Berners-Lee.

Pero a día de hoy, sin embargo, la web no es más que una plataforma más sobre la que difundir todo tipo de contenido interactivo, desde páginas más clásicas en cuanto a su orientación comunicativa, como la Wikipedia, a verdaderas aplicaciones web que incluso se llegan a portar tal cual al escritorio, como podría ser el conocido reproductor web de Spotify, cuya existencia debemos agradecer al inestimable poder de los frameworks.

Desarrollo web: Una aproximación clásica

Inicialmente en los albores de la web, esta se concebía como un repositorio de foros de opiniones, artículos, información general y formularios de contacto para particulares u organizaciones.

Esto se debía a que los primeros navegadores comerciales renderizaban únicamente texto e imágenes, y la velocidad de conexión estaba muy limitada en velocidad (Con los módems de 56Kbit/s), lo que hacía difícil enviar un volumen mayor de información que permitiera crear una mayor interactividad con el usuario, y se limitaba a comportamientos pre-programados como los formularios, enviados directamente al servidor mediante acciones sencillas.

Al introducirse el lenguaje JavaScript en el 95, la interactividad es todavía limitada, y se reduce a pequeñas manipulaciones del árbol DOM de la propia web y a pequeños trozos de código integrados en el HTML para realizar pequeños cambios en el comportamiento por defecto de los elementos del navegador. No será hasta la introducción de AJAX, ya en el 99, que comiencen los inicios serios de la interacción de datos, ya que en ese momento se hace posible poder actualizar los datos del navegador de forma programativa directamente desde peticiones a un servidor.

Fue en este momento en que la riqueza y el desarrollo en la web explota, se realizan múltiples implementaciones paralelas de características de JavaScript, no todas compatibles por navegador, y se hace repentinamente necesario una forma de gestionar todo este desbarajuste. Por ello en 2006 aparece Jquery, una librería de JavaScript que simplifica y compatibiliza entre navegadores diversos métodos altamente usados a la hora de manipular de forma efectiva el DOM.

Por lo tanto, y desde entonces, la complejidad de la lógica de las webs aumenta exponencialmente, y comienzan a crearse verdaderas aplicaciones de escritorio que son capaces de funcionar en un simple navegador, gracias también a las nuevas especificaciones de JavaScript, HTML y CSS y a la potencia mejorada de los procesadores de los nuevos ordenadores. Sin embargo, estas nuevas “web-apps”, tienen una serie de inconvenientes:

• Son excesivamente complejas - La cantidad necesaria de código para generar ciertas características de interacción es excesiva, y las transformaciones y las estructuras utilizadas en una aplicación no tienen por qué tener nada que ver con las utilizadas en otra distinta, ya que son fruto de una potente opinión del desarrollador que lo realizara.

• Tienden a ser caóticas - La forma de importar en JavaScript mediante tags <script>, sin espacio de nombres o importaciones concretas, simplemente mediante precedencia de archivos, hace que ante un gran volumen de archivos, si no se sigue una disciplina muy estricta, los scopes puedan pisarse y puedan ocurrir errores de difícil trazabilidad que empeoran a mayor magnitud del proyecto.

• Son poco modulares - La forma en la que la lógica de una aplicación clásica se enlaza entre las diferentes características no suele beneficiar la modularidad o componentización de sus diferentes partes, por lo que es difícil reusar código ya sea para otras partes de la misma aplicación o para crear aplicaciones con características comunes.

Esta serie de prolegómenos, bien conocidos por los desarrolladores, llevan a la creación de otras librerías que puedan mejorar todos estos problemas, por ejemplo handlebars que simplifica la renderización de nuevos elementos en el DOM. Sin embargo, sin una reestructuración de JavaScript o del funcionamiento general de la web y del DOM, esto parecían parches sobre parches y no una solución alternativa.

Desarrollo web: Una aproximación moderna

A medida que la web aumenta en complejidad, las herramientas usadas hasta el momento comienzan a ser deficientes a la hora de acometer complejas aplicaciones, dignas de escritorio, en el navegador.

Por lo tanto, surge una nueva corriente de librerías como Backbone.js o Knockout.js que comienzan a aunar diversas soluciones existentes en JavaScript para crear un entorno único, cerrado y con un flujo definido, es decir, un framework para desarrollo web propiamente dicho. Pero no es hasta octubre de 2010 que Google decide lanzar al mercado y de forma gratuita su framework Angular.js, y su popularidad crece rápidamente al poco de ser liberada.

Este framework con orientación mvc (Modelo-vista-controlador) introducía novedades y una serie de ventajas muy requeridas para aplicaciones de cierta complejidad como podían ser la inyección de dependencias, el routing, o la vinculación de datos en ambos sentidos. Sin embargo, al año Google decide rehacer de cero su librería, lo que lleva a la creación de Angular 2, que en su momento resultó un escándalo en la comunidad ya que rompió la compatibilidad con Angular.js (Que recordemos que únicamente tenía un año de vida) y no se proporcionó ninguna guía posible para una migración.

Más tarde en 2013 Facebook decide lanzar la librería que crearon para desarrollar Facebook: React.js. A pesar de no ser un framework como tal, React resulta ser una gran herramienta e introduce novedades muy interesantes orientado a un desarrollo moderno, como puede ser el DOM virtual, un objeto de JavaScript global que almacena los elementos activos paralelamente al DOM y que es usado en cada actualización para realizar comparaciones en los cambios ejecutados y aplicarlos, aumentando sensiblemente el rendimiento y evitando depender del DOM para la renderización o supervisión de los cambios del usuario.

A partir de este momento otros frameworks y librerías de apoyo surgen, como Vue.js, un framework con una filosofía parecida a Angular pero con DOM virtual y una supervisión inteligente del cambio de propiedades, o Redux, una librería y patrón de desarrollo que consiste en la tendencia contraria hasta el momento: Crear un almacén global cuya manipulación se deba a mutadores lanzados por acciones (funciones) y que puedan ser consumidos desde cualquier punto de la aplicación, evitando servicios o anidamientos innecesarios.

Sin embargo, y a pesar de estos aparentes e imparables avances, hay una serie de inconvenientes implícitos en el uso de cualquier framework o librería de renderización basada en JavaScript:

• Poseen complejos sistemas internos - Los sistemas que utilizan para, por ejemplo, la detección de cambios, la persistencia de datos, el routing u otros relacionados suelen ser sistemas de alta complejidad que en muchos casos suman un cómputo adicional y no controlable a cada proyecto que creemos y estén incluidas, aunque no las usemos de manera explícita. Esto además supone una pérdida de control sobre el funcionamiento interno de nuestra app, e intentar salirse de dichos mecanismos será en ciertas ocasiones complicado, y en ocasiones poco recomendable.

• No son amistosos con el SEO - Debido a que el routing se realiza de forma estática y por JavaScript, la única forma de editar las cabeceras meta es mediante su uso, esto sin embargo es un gran inconveniente ya que los bots encargados de la indexación de las webs en motores de búsqueda no son generalmente capaces de procesar JavaScript, y cuando lo hacen no son capaces de hacerlo para todos los casos, debido a que les es imposible determinar cuándo ha terminado la ejecución de un script. Esto impide que los meta puedan procesarse con éxito en todos los casos y puede ser un importante impacto en el posicionamiento de estas webs.

• El peso del bundle tiende a descontrolarse - Gracias al uso de NPM y webpack podemos disponer de todos estos frameworks en una versión CLI que nos permite añadir nuevas librerías y características con mucha facilidad. Sin embargo esto también tiene un lado negativo; El peso del transpilado final tiende a aumentar rápidamente, dado sobre todo que para nosotros es un proceso tan rápido y sencillo que podemos llegar a despreciar el impacto que esto supondrá en la velocidad de carga de la web generada.

Analizando nuestras necesidades

A la hora de realizar un nuevo proyecto puede surgirnos continuamente la duda sobre si estamos usando la plataforma adecuada: ¿Debería de usar un desarrollo tradicional y arriesgarme a crear una aplicación de inmanejable complejidad o bien usar un acercamiento más moderno basado en librerías y frameworks y arriesgarme a perder SEO o perder eficiencia debido al sobrecoste computacional que suponen ciertos sistemas opacos que utilicen? Para solucionar este dilema siempre tiendo a hacerme una serie de preguntas clave.

¿La cantidad de interacción es justificable?

En algunos casos esta respuesta es un flagrante “sí, por supuesto”, sobre todo cuando tenemos que hacer cualquier tipo de aplicación de alto nivel de interacción con el usuario o que dispone de una gran cantidad de partes que cambian dinámicamente. Sin embargo hay tipos de webs donde la cantidad de interacción es tan mínima que no está justificado el hecho de usar un framework.

Un ejemplo claro sería la denominada “web empresarial”, un tipo de web “escaparate” de diseño sencillo donde el objetivo principal es mostrar las virtudes de una web o servicio, y la interacción se suele reducir a un formulario simple o una galería con paso automático de fotos. En este caso el uso de un framework o librería de renderizado sería poco útil, ya que la programación necesaria para generarla sería ínfima, y la gestión del estado prácticamente inexistente.

El caso radicalmente opuesto sería, sin lugar a dudas, una aplicación web, es decir, una web cuyo objetivo es realizar un servicio al usuario similar al que realizaría una aplicación de escritorio. Estas aplicaciones se basan exclusivamente en responder a la interacción casi continua del usuario, generar contenido dinámico y realizar llamadas a APIs, por tanto, se beneficiarán enormemente de un framework que facilite el renderizado, gestione los cambios de estado y simplifique el desarrollo en equipo.

¿Cuál es la magnitud del proyecto?

En ocasiones el proyecto no es particularmente complejo, pero sin embargo, el número de elementos en pantalla o la cantidad de pantallas a mostrar se estima muy elevado. En estos casos, y particularmente si trabajamos en un equipo, es preferible utilizar un framework, y ello por una serie de motivos muy comprensibles para cualquiera habituado a trabajar en equipos grandes:

• Es más fácil definir un flujo de trabajo - Incluso en librerías como React.js, que dejan más libertad para crear una lógica, es más fácil definir un flujo de trabajo que en un desarrollo JavaScript clásico, ya que los scopes están más definidos, en el CLI es posible crear diversas carpetas y distribuir todas las piezas de nuestro proyecto y existen múltiples guías de uso para cada librería que sea agregada.
• Se potencia la reusabilidad y la tematización - Por la propia naturaleza de estas librerías es más fácil crear piezas o componentes reutilizables que puedan abstraerse al máximo posible de una lógica acoplada. De esta forma en proyectos grandes ahorraremos tiempo reutilizando diversos componentes creados para otras secciones. De la misma manera estos componentes son más fáciles de tematizar, ya que pueden recibir contexto o propiedades en cascada que permita cambiar rápidamente sus estilos, y no simplemente mediante un cambio de las hojas CSS.
• Es más sencillo realizar localizaciones - Trabajar con localizaciones a otros idiomas suele ser complicado, sin embargo, las librerías de localización para frameworks suelen incluir una forma sencilla de introducir las localizaciones en archivos separados por idioma, que luego pueden enviarse con mayor facilidad a los traductores. De la misma manera cambiar formatos de fecha puede realizarse con mayor eficiencia definiendo métodos internos mediante el flujo del framework que cambie el locale de librerías como moment.js o day.js en caliente.

¿Es el posicionamiento una prioridad?

Si la respuesta es sí, lo mejor es intentar prescindir de un framework. Como ya mencionamos anteriormente esto es un tema candente, ya que los frameworks JavaScript en el lado front-end no son muy amistosos con el posicionamiento SEO.

Sin embargo, en casos en los que la cantidad de interacción sea lo suficientemente justificable y ganemos un aumento obvio en la productividad final por componentizar y reutilizar, podemos empezar a plantearnos una opción cada vez más en boga: Renderización en el lado del servidor (SSR).

Este acercamiento nada novedoso, se basa en lo mismo que el desarrollo clásico, ciertas partes del documento enviado se renderizan por el servidor y otras partes mantienen interacción del lado de cliente. Sin embargo la novedad es que estos sistemas se integran con las librerías o frameworks existentes, ya sea de forma nativa por la librería o mediante el uso de librerías adicionales o frameworks basados en estos frameworks. Sin embargo, y al igual que en un acercamiento clásico mediante PHP, uno de los problemas más evidentes es que de esta forma el grueso del cómputo podrá caer sobre nuestro servidor, y no sobre el cliente, por lo que si la aplicación realiza cómputos especialmente pesados será necesario valorar concienzudamente la línea de separación cliente-servidor de nuestra aplicación

En conclusión

Hay muchos factores a favor y en contra de un acercamiento moderno o más clásico, sin embargo, y para proyectos pequeños o personales, si no existe ningún impedimento particular mi experiencia es que lo mejor es elegir aquel método con el que te sientas más cómodo, ya que el rendimiento en el desarrollo se basa en gran medida en un componente muy subjetivo ligado al desempeño del propio programador.