Introducción a Vue.js

El camino hacia los frameworks JavaScript no fue fácil debido a los problemas de compatibilidad existentes entre navegadores. Tenías que realizar un esfuerzo extra para asegurarte de que tu código se ejecutara bien en todos los navegadores a los que dieras soporte.

Una de las primeras librerías que vino al rescate fue jQuery, lanzada en agosto de 2006. A medida que pasaba el tiempo, se veía que a jQuery le faltaban utilidades para manejar datos de forma consistente entre vistas compartidas. Vinieron Backbone, Knockout y Ember, entre otros. AngularJS llegó en 2010 de la mano de Google, convirtiéndose rápidamente en el framework JavaScript más popular: el mágico two-way data binding ✨, inyección de dependencias, routing, etc. Se fue haciendo más complejo hasta que su equipo decidió rediseñarlo entero trayendo Angular 2. Era incompatible con su versión anterior y perdió muchos usuarios. En 2013 llegó React de la mano de Facebook: one-way data-binding, virtual DOM, patrón Flux, etc.

Vue.js, un framework JavaScript progresivo, fue lanzado en febrero de 2014, por Evan You, quien previamente había trabajado en Google y Meteor. A diferencia de React, que es muy flexible, o Angular que está muy opinionado, Vue trata de encontrar el equilibrio. ⚖️

Sobre Evan You

Evan You venía de un background no técnico (artes) cuando conoció JavaScript. En un momento dado, descubrió Google Experiments, un proyecto que le gustó tanto que sintió la necesidad de ampliar sus conocimientos en tecnologías web. Así que, con el tiempo, fue involucrándose en la programación más en serio. Su primer trabajo fue en Google Creative Labs en 2013.

Vue empezó como un proyecto paralelo en 2013 al que Evan se dedica a tiempo completo desde 2016. Ha trabajado con varios frameworks, lo que le ha permitido obtener diferentes perspectivas acerca de por qué los desarrolladores de frameworks toman ciertas decisiones basándose en diseños internos y compromisos a la hora de construir un framework. Se preguntaba qué haría él si tuviera que construir el suyo propio. Porque, vale, es posible crear una aplicación en vanilla JavaScript, aunque pueda llevar un poco más de tiempo. Pero, ¿y si empieza a ser más compleja? Entonces, ¿nos vendría bien usar un framework? Muchos artículos de Internet comparan frameworks según las estrellas que tienen en Github, las descargas de NPM o las preguntas relacionadas con ellos en StackOverflow. Sin embargo, cuando nos encontramos ante una decisión técnica, ¿importa verdaderamente esto? No mucho, son datos irrelevantes.

Para entender dónde encaja Vue en el panorama actual, imaginemos que vamos a desarrollar nuestro propio framework frontend ¿Qué aspectos deberíamos tener en cuenta?

• Alcance: qué cosas puede hacer un framework por ti

A la hora de desarrollar una aplicación, tenemos librerías (colecciones de funciones con propósitos específicos) y frameworks (como esqueleto donde nosotros definimos las funcionalidades de la misma).

🔵 React cae en la parte de librerías. Sea cual sea la complejidad de tu aplicación final, React te proporciona unos elementos básicos (componentes) con los que construir tu UI y que puedes combinar de forma elaborada para formar sistemas complejos. Esta flexibilidad unida a la creatividad de la comunidad son la causa de que React tenga un ecosistema tan activo y tan variado con multitud de “plugins” diferentes entre los que elegir. Al tener un código core pequeño, necesitas entender menos conceptos para empezar a usar la librería. A su vez, el equipo de React tiene menos tarea de mantenimiento, ya que recibe mucha aportación de la comunidad y se puede centrar en explorar nuevas ideas para la librería. Hacer cambios base es menos costoso ya que es más fácil controlar cómo funciona todo el sistema en su totalidad y comprobar que no se rompe su funcionamiento.

Sin embargo, para construir una aplicación muy compleja solo usando componentes básicos y ser eficiente en el camino, es recomendable construir abstracciones. Por esta razón, surgen los patrones, como Flux. Pero algunos de estos patrones muchas veces no están documentados. Si vas a la web de React, no te dice la manera en la que tienes que usar tus HTML’s y tus JS’s, tienes que investigar por tu cuenta y aprenderlo. Además, si el ecosistema se mueve demasiado rápido, puede provocar su fragmentación por el miedo de los usuarios de la librería a perderse la siguiente versión mejorada que salga de cualquier cosa. El alcance es intencionadamente pequeño.

🔴 Angular cae en la parte de frameworks. Los problemas a los que los usuarios finales de nuestra aplicación se pueden enfrentar se tuvieron en cuenta durante el diseño del framework: validación de formularios, animaciones, internacionalización, etc. Para construir algo así tenemos que pensar en cómo funciona y encaja todo junto desde el principio. El alcance aquí sería intencionalmente grande porque el objetivo de un diseño así es que cuando uses el framework y te encuentres con un problema, puedas encontrar la solución dentro del framework, no tienes que analizar NPM de arriba a abajo en busca de diferentes soluciones, simplemente mira qué solución te ofrece el framework.

Sin embargo, el inicio de la curva de aprendizaje es más acentuado para gente que comienza o que tiene poca experiencia con lenguajes back-end. Por ejemplo, si nunca has usado lenguajes como Java o C#. Encuentras inflexibilidad si la solución que te ofrece el framework no se ajusta a tu caso de uso. Además, el equipo de Angular tiene más código que mantener, lo que hace más costosa la introducción de nuevas ideas. Hay tantas piezas que necesitan funcionar juntas de forma consistente, que cuando tratas de cambiar una idea base, cada componente de tu sistema se ve afectado. Hacer cambios base es más difícil.

➡️ Aquí es donde Vue entra en juego 👏👏👏.

No se trata de decir ahora que Vue es el mejor en todo esto. No siempre la solución de en medio es la mejor. Cada una encaja en un tipo de caso. No hay ninguna que encaje en todos.

Framework progresivo

La manera en que Vue afronta el problema del alcance es de manera “progresiva”, que quiere decir que podemos usarlo para algo muy básico como algo que se pudiera hacer en la época de jQuery o para algo más complejo como una SPA. Si no necesitas routing, si no necesitas gestión del estado, si no necesitas animaciones, puedes usar Vue sin nada de eso. Se elimina aquello que podría ser un obstáculo en nuestro primer minuto de aprendizaje.

La curva de aprendizaje inicial es suave. Uno de los objetivos de Vue es permitir a la mayor cantidad de personas acceder al desarrollo web, aprender y concentrarse en construir cosas en vez de aprender una montaña de conceptos que a lo mejor no son necesarios para su caso de uso actual. 👌

Hay soluciones documentadas para problemas comunes. A medida que tu aplicación se va haciendo más compleja y te das cuenta de que necesita un router, entonces dices «vale, necesito un router». Vas a la documentación y ves que hay un router para Vue que puedes usar. Pero a la vez el router no es una pieza obligatoria.

Sin embargo, no es perfecto. Estar en medio implica compartir las ventajas de los dos lados pero también los inconvenientes. Aunque el equipo de Vue solo proporciona unas cuantas funciones integradas, tiene que mantenerlas y cada vez que hace un cambio base en el framework, tiene que asegurarse de que funciona bien. Por esto, su ecosistema no va a ser tan diverso como el de React, por ejemplo.

Aquí es donde está la diferencia fundamental entre React, Vue y Angular, en su forma de afrontar el alcance. Diferentes desarrolladores necesitan diferentes soluciones y tener frameworks principales cubriendo el espectro entero asegura que todo el mundo obtiene lo que quiere.

• Mecanismo de renderizado: la forma en que un framework te permite expresar la estructura de tu UI y cómo renderiza las cosas

Es una decisión compleja e influyen varias aspectos al elegir este mecanismo. Piensa en la diferencia entre usar JSX y templates. Igual que antes con el alcance, ahora tenemos por un lado a React y similares, que usan algún tipo de virtual DOM, en el otro lado, tenemos las plantillas (templates), como Angular.

Con JSX no estás confinado a la sintaxis específica de la plantilla. Al contrario, tienes el lenguaje JavaScript a tu disposición para implementar cualquier tipo de lógica en tus componentes, lo cual es muy potente y da mucha libertad. Pero lo que ganas en expresividad lo pierdes en coste, ya que hay que recorrer todo el virtual DOM de forma recursiva para encontrar aquellos nodos que han cambiado y hay que actualizar. Da igual si tienes diez o diez mil nodos y solo cambia uno. Esto es así debido a la naturaleza dinámica de las funciones de renderizado. La optimización es difícil porque el compilador no puede conocer todas las formas en las que el desarrollador puede decidir que va a “dibujar” algo en el DOM.

Con templates usas un lenguaje restrictivo. Sólo puedes escribir templates de una determinada manera. Por eso, el compilador puede hacer suposiciones sobre las intenciones del desarrollador y optimizar el código. Sin embargo, estás limitado por la sintaxis de la template y pierdes la expresividad de JavaScript. Cuando intentas construir un componente muy complejo, piensas «ojalá pudiera hacer esto en la template», pero el compilador no lo soporta.

➡️ De nuevo, Vue está en el medio.

En Vue, puedes usar tanto funciones de renderizado con Javascript como templates. Esto nos aporta:

• Rendimiento: de hecho, Vue compila las templates en virtual DOMs por debajo. De alguna manera, coge lo mejor de los dos mundos. La fase de compilación produce funciones de renderizado especialmente optimizadas. Como ha dicho Evan You recientemente, en la versión 3 de Vue se está trabajando en esta optimización.

• Expresividad: puedes no escribir templates y optar por JavaScript y su flexibilidad. Te da una bocanada de aire si te sientes limitado por las templates.

No hay una bala de plata

En este post hemos podido ver que Vue coge lo mejor (y algunos inconvenientes) de sus frameworks compañeros. Me gusta la idea de que sea un framework progresivo y la filosofía de Evan (probablemente a partir de su propia experiencia) de querer llegar al mayor número de desarrolladores posible, tengas los conocimientos o experiencia que tengas. Eso se nota en una documentación que no da nada por sabido, lo cual, cuando estás empezando, se agradece.

Para resumir, ¿dónde está el punto medio? La respuesta seguramente sea: ¿existe un punto medio perfecto? Hay muchas opciones para elegir. Se puede aprender cómo funciona un framework, ver si encaja con tu forma de trabajo y, si te gusta, elegirlo. También es cierto que mientras más experiencia tienes con un framework, puedes ver similitudes con otros y ver en qué mejora y en qué tiene carencia. Depende de tus requisitos como desarrollador y de tu proyecto.

Esta entrada ha sido más bien teórica, para situar Vue en nuestro mapa mental y entender mejor qué aporta al panorama actual de librerías y frameworks. En próximas entradas nos aproximaremos a él de forma práctica, aprovechando su progresividad y veremos, ya en detalle, las similitudes y diferencias con otras librerías y frameworks.