A lo largo de estos años, he tenido la suerte de poder trabajar con diferentes frameworks JavaScript. Cada uno de ellos ha tenido, para mi, sus puntos fuertes y sus puntos débiles. Nunca he tenido un apego incondicional con ninguno de ellos y eso me ha hecho ver a los frameworks como lo que son: herramientas que pueden ayudarnos tanto como hacernos pasar un buen dolor de cabeza. Esto ha hecho que pueda valorar mucho qué funcionalidades son necesarias y qué argumentos tener en cuenta a la hora de decantarme por uno o por otro dependiendo del contexto en el que me he encontrado.
Viéndolo con perspectiva, en muy poco tiempo, hemos visto como estos frameworks han ido pasando por diferentes generaciones y como han ido madurando. Se podría decir que a día de hoy, en lo que yo suelo considerar la 3ª Generación, nos encontramos con frameworks bastante maduros que nos ayudan a realizar un gran número de tareas que pueden ser ejecutados en diferentes navegadores a la vez.
ReactJS, Angular y EmberJS son los frameworks que representan un mayor uso en el mercado y que han demostrado ser una garantía de robustez y escalabilidad. A esta terna, se ha unido hace una temporada VueJS. Un framework con el que llevo trabajando durante un buen tiempo y del que he intentado estudiar cada funcionalidad.
En este post, me gustaría exponer cinco razones que han hecho que VueJS se haya convertido en mi framework JavaScript favorito. Espero que estas razones os convenzan para que en vuestra próxima prueba de concepto o proyecto personal, le deis una oportunidad.
1. Un framework para aprender y usar de manera progresiva
VueJS se autodenomina como un framework progresivo. Cuando encaramos un desarrollo con VueJS, podemos indicar qué partes del framework queremos incluir. VueJS está modularizado en diferentes librerías separadas que permiten ir añadiendo funcionalidad en el momento que las vayamos necesitando.
La modularización en librerías de un framework no es algo nuevo en el desarrollo front. Tanto ReactJS como Angular cuentan con una organización parecida de su código base. Lo que diferencia a VueJS de otras alternativas es lo bien desacopladas que se encuentran estas partes, lo fácil que es extender la funcionalidad core y lo bien que trabajan todas sus partes una vez que se decide incluir más módulos.
El core principal de VueJS está formado por una librería encargada de renderizar vistas en el navegador. Su forma de organizar el código es por medio de pequeños componentes que contienen todo el HTML, CSS y JavaScript necesario para funcionar como pieza independiente. Estas piezas se van componiendo en un árbol jerárquico de componentes hasta formar nuestra aplicación. Usar esta librería es tan fácil como importar el script en nuestra página HTML.
Si lo único que necesitamos como desarrolladores es una mejor forma de organizar y renderizar nuestros pequeños componentes visuales, nos quedamos ahí y no incluiríamos nada más. En el momento que nuestra aplicación empezase a crecer, contamos con librerías para gestionar las rutas de nuestra aplicación como vue-router o con librerías para gestionar el estado global de la aplicacion como pueda ser vuex. Si nuestra aplicación tuviese que tener una gran optimización o tener buen SEO, podemos incluir y trabajar con vue-server-rendering.
Y así nos pasaría con muchas más funcionalidades. La cantidad de librerías con las que se cuentan (ya sean creadas por los desarrolladores oficiales o por la comunidad) es tan grande y cubre tal espectro de funcionalidades, que será difícil que nos encontremos desamparados y sin esa utilidad que nos es indispensable.
2. Funcionalidades intuitivas, modernas y fáciles de usar
VueJS no ha reinventado la rueda. Nuestro amigo verde fue creado como proyecto personal por Evan You, antiguo desarrollador de Google, en un intento de simplificar el funcionamiento de AngularJS. El framework empezó a ser tan fácil y simple de usar que, una vez que su creador decidió subirlo a los repositorios de Github, la comunidad fue usándolo en cada vez más proyectos.
Empresas como Xiaomi, Alibaba o Gitlab son algunos de sus grandes exponentes. Si miramos las estadísticas de las expectativas de uso en el año 2018 encontramos que muchas personas y empresas están interesadas en conocerlo y usarlo.
Pero ¿Por qué este hype? ¿Por qué la comunidad tiene tan buenas palabras de este framework?
Bajo mi punto de vista, se debe a lo bien que Evan You ha sabido trasladar todo lo bueno que tienen otros frameworks como Angular, ReactJS y EmberJS y desechar aquello que al desarrollador no le aportaba o le era complejo de usar.
Si tuviésemos que definir a VueJS por cuatro de sus aspectos conceptuales serían estos:
El dato como centro de todo: En VueJS, los componentes gestionan un modelo de datos interno. Estos componentes están diseñado bajo el patrón MVVM. Esto quiere decir que el desarrollador no tiene que preocuparse tanto por cómo o cuando renderiza un modelo en pantalla y sí más en cómo tiene que ser la lógica que gestiona ese modelo. El renderizado de HTML es delegado a la librería. Nosotros simplemente jugamos con datos, métodos y plantillas HTML donde indicamos cuando se tiene que pintar cada parte del modelo.
El sistema de componentes es reactivo: VueJS sabe comunicarse muy bien por medio de eventos asíncronos. Un componente hijo se puede comunicar con su componente padre por medio de eventos. Dos partes del sistema pueden comunicarse por medio de eventos. Los propios modelos de un componente son capaces de enviar eventos para indicar cuándo renderizarse. El sistema de componentes se convierte en un organismo vivo que reacciona muy bien al cambio y realiza acciones programadas por el desarrollador. Esto se debe a que el módelo de datos del componente es envuelto por getters y setters especiales encargados de gestionar estas reacciones.
Sin fricción con otras librerías o recursos: Cuando me enfrenté a ReactJS sufrí un poco con el concepto de que todo era JS. Tener JSX no me ayudó para su aprendizaje. Angular me medio obligó a incluir TypeScript para escribir componentes. Me gusta TypeScript, lo que no me gusta es que me impongan herramientas. VueJS es el más concienciado con esto: Usa lo que quieras, usa la herramienta con la que te encuentres cómodo, céntrate en escribir HTML, CSS y JavaScript. Si quieres añadir JSX o TypeScript hazlo. Si no lo quieres incluir ahora, hazlo más tarde. Esto hace que desarrollar en VueJS sea más intuitivo. Es casi como trabajar con JavaScript nativo. Particularmente, me parece un paso muy natural si vienes de trabajar con jQuery.
Todo está en el sitio que tiene que estar. Cuando empecé con VueJS, me di cuenta que miraba la documentación menos que en la de otras herramientas. Asimilaba la sintaxis antes. Incluso la propia intuición me permitía usar la librería sin tener que mirar la documentación previamente. Esto se debía a que el naming de la API de VueJS es bastante intuitiva. Con saber lo que significa props, data y methods y qué puedo incluir en estas partes, podía empezar a hacer mucho, con muy pocos conocimientos. De hecho, si no os explico de qué trata cada una de estas partes de la API, lo más seguro es que supieseis de qué estoy hablando. Es una de las virtudes de VueJS. Ser fácil, intuitivo y poco recargado. Cada parte está en el lugar que debería estar. Esto es algo dificil de entender hasta que no se está desarrollando algo en VueJS, pero creedme, que si le dáis una oportunidad, esto lo notareis.
3. Un ecosistema muy variado que cubre todo lo necesario
Cuando me decanto por una herramienta de trabajo u otra, busco que la experiencia de desarrollo sea lo más cómoda posible. VueJS tiene a su alrededor una serie de herramientas que ayudan a conseguir que el desarrollador sepa en todo momento qué está haciendo y cómo lo está haciendo. Hay tres herramientas que me ayudan mucho a la hora de trabajar con VueJS.
Una de ellas es la línea de comandos (CLI) especial que han creado sobre NodeJS. Esta herramienta permite empezar un proyecto con un boilerplate (o plantilla base) configurado a nuestro gusto de una manera fácil y sencilla. Simplemente descargando desde npm la herramienta vue-cli, podremos crear una estructura inicial con la que trabajar que cumple con la guía de estilo pactada por la comunidad. Bajo mi punto de vista, es la mejor manera de empezar a conocer la plataforma.
Además, una vez que estamos desarrollando, lo que más me ayuda a saber qué estoy haciendo y si lo estoy haciendo bien son los procesos de depuración. Es cierto que Firefox y Google Chrome ya cuentan con excepcionales herramientas para depurar código. Pero hay una serie de conceptos internos que VueJS gestiona como el estado, las propiedades o los eventos que las herramientas estándar no suelen conocer.
El equipo de desarrollo de VueJS mantiene una extensión de Chrome que nos permite ver cómo se renderiza nuestro árbol de componentes, cómo se están lanzando y registrando eventos, cómo se guarda el estado interno de cada componente o cómo se está comportando el estado global de la aplicación. Esta es una buena herramienta que nos ayudará mucho en nuestro día a día. Simplemente hay que ir al store de Chrome y descargarla.
Pero esto no queda aquí, y es que además de encontrar facilidades a la hora de empezar y de depurar un proyecto con VueJS, contamos con plugins para los IDEs más usados en la actualidad. Yo en mi caso, uso Visual Studio Code (VSC) para desarrollar aplicaciones front y me gusta mucho tener instalado un plugin para realizar diferentes acciones de VueJS llamado Vetur.
Este plugin, me permite tener intellisense de la sintaxis de Vue en VSC. Me permite escribir componentes más rápido gracias a los snippets por defecto que tiene, me permite tener pintado y estilizado mí codigo para que en todo momento sepa cuales son las palabras reservadas del framework. Por último, me permite usar herramientas como Prettier con solo usar un atajo de teclado. Cómo véis es una herramienta muy útil.
Lo bueno de estas herramientas es que se encuentran en constante evolución. Siempre que sale una nueva versión del framework, la comunidad y el equipo core se encarga de mantenerlas al día y siempre están añadiendo funcionalidad extra para hacer el trabajo a los desarrolladores un poco más fácil.
4. Una comunidad muy activa
Todo lo anterior puede estar muy bien, pero si no hay un buen grupo de personas que esté detrás de un proyecto tan importante como este, poco puede importar ¿Cuántas veces nos ha pasado, que hemos usado una librería y con el paso del tiempo, hemos tenido que ser nosotros quien la hemos tenido que mantener porque su creador no le ha dado soporte? En la época de esplendor de jQuery, me pasó más de lo que me hubiera gustado.
En ese sentido, simplemente tenemos que mirar este repositorio oficial de VueJS llamado ‘Awesome VueJS’. En este repositorio se incluyen todos aquellos recursos relevantes que la comunidad está creando sobre esta herramienta: Libros, charlas, librerías, posts, manuales… todo lo que se nos ocurra está aquí.
VueJS es un proyecto Open Source que cuenta con una comunidad muy viva. Además, es un proyecto Open Source ‘real’. ¿Qué quiero decir con ‘real’? Quiero decir que es un proyecto gestionado, desarrollado, evolucionado y planteado por y para la comunidad. Si miramos a sus competidores más directos, tanto Angular (creado por Google) como ReactJS (creado por Facebook) tienen un sistema Open Source más rígido y menos abierto de lo que nos gustaría.
El roadmap, el versionado, las decisiones, siempre o casi siempre, son tomadas desde los equipos formados por estas dos grandes empresas. En este caso, el modelo de VueJS se asemeja más con el de EmberJS. Proyectos financiados por la comunidad, creados por la comunidad, sin ningún gigante que se preocupe por ellos.
Esto, como en todo, puede ser un arma de doble filo. La esencia del software libre, el espíritu de compartir con la comunidad, está presente en VueJS. No existen intereses de terceros. No existen cambios repentinos por decisiones de negocio. Simplemente se intenta seguir un roadmap que pueda satisfacer a todo el mundo partiendo de unas bases conceptuales. Esto es bueno porque te da independencia y te da sensación de cercanía.
La comunidad en VueJS se siente escuchada. Muchas partes del framework se han quitado o mejorado por las issues que se han abierto en los repositorios del proyecto.
Planes como que VueJS renderice en Web Components nativos han sido gracias a la presión de la comunidad.
Sin embargo, VueJS sufre de un mal que si con el tiempo no se tiene en cuenta, puede ser el final del proyecto: VueJS todavía depende demasiado de su creador. Si se revisan los commits y estadísticas del proyecto, se puede observar que Evan You copa todavía muchos de los rankings de actividad. Empieza a haber gente importante en el proyecto (como Sarah Drasner o Guillaume Chau), pero parece que todavía todo gira alrededor del desarrollador oriental.
Esto, por muy mal que nos parezca su sistema de software libre, no va a pasar en otros frameworks más corporativos. Google, ReactJS van a seguir mantenidos porque se encuentran dentro de la estrategia de desarrollo de sus empresas. ¿Qué esto puede cambiar? Pues sí, tal vez, pero que sepamos que contamos con esto. VueJS tiene pinta de ser un proyecto que a medio-largo plazo va a seguir funcionando muy bien, pero es normal que se vigilen los movimientos de la comunidad.
5. Todo el código de un componente se encuentra en un único fichero
Vale, quizá tampoco sea nada novedoso. Habíamos comentado que en ReactJS todo se transformaba en JavaScript, por tanto, todo el código de un componente, ya sea HTML (JSX en este caso), CSS y JavaScript se va a encontrar en un único fichero con extensión .jsx. Y quizá estos sistemas no lo veas ni como una ventaja ¿Qué pasa con la separación de conceptos? ¿Ya no debemos separar el contenido, de su estilo y su lógica de negocio?
Bueno, pues sí, en VueJS, los componentes también guardan todo lo necesario en ficheros con extensión .vue. Estos ficheros contienen todo el HTML, el CSS y el JavaScript de un componente. Entonces ¿en qué se diferencia de ReactJS? Se diferencia en que en VueJS, los conceptos están juntos en un fichero, pero no revueltos.
Para verlo más claro, veamos el ejemplo de un componente en VueJS:
<template>
<form class="search-box" @submit.prevent="search">
<input type="text" placeholder="Ej. Cinema Paradiso" v-model="query" />
<button>Buscar</button>
<span>{{ queryLength }}</span>
</form>
</template>
<script>
export default {
name: 'search-box',
props: {
value: { type: String, default: '' }
},
data() {
return {
query: this.value
}
},
computed: {
queryLength: function () {
return this.query.length;
}
},
methods: {
search() {
this.$emit('search', this.query);
}
}
}
</script>
<style lang="scss" scoped>
@import '../assets/scss/_colors';
$color-light-darken: darken($color-light, 15%);
.search-box {
display: flex;
height: 3rem;
button,
input {
&:focus {
outline: none;
}
}
input {
width: 100%;
padding: 0 0.5rem;
border: 1px solid $color-basic-2;
border-right: 1px solid $color-light;
}
button {
padding: 0 2rem;
background: $color-light-darken;
color: $color-basic;
font-weight: bold;
border: 1px solid $color-light-darken;
&:hover {
cursor: pointer;
background: $color-light;
border: 1px solid $color-light;
}
}
span {
display: block;
font-size: 1.5rem;
padding: 0.5rem 1rem;
}
}
</style>
En esta ocasión, observamos un componente que representa un típico buscador. Es el componente SearchBox.vue. Este componente se encarga de renderizar un formulario con un elemento <input /> y un elemento <button />. Lo que hace es guardar lo que el usuario inserta en la variable query y emitir un evento al componente padre con esta información cuando el usuario pulsa en el botón.
¿Véis lo que os digo? Todo el HTML, CSS y JS está junto, pero no revuelto. Gracias a las etiquetas template, script y style, tengo los conceptos separados, pero juntos, de esta forma es más fácil reutilizar ficheros en más de un proyecto. Todo el contenido queda más claro. Si el desarrollador está trabajando en un componente en particular, tiene todo a la vista.
Lo bueno de esto, es que cuando construya mi aplicación, vue-loader, una pieza creada por el equipo de VueJS para hacer que mis ficheros .vue funcionen con Webpack, todo mi código JavaScript será empaquetado en un fichero app.min.js y todo el CSS que se encuentre en los componentes, será empaquetado en un fichero app.min.css. Auténtica magia que nos hace la vida más fácil a todos y todas.
Lo bueno de nuevo de VueJS, es que si esto de los Single File Components no te convence, puede seguir guardando los conceptos de cada fichero por separado.
Conclusión
Creo que es bastante importante saber la razón por la cuál se elige una herramienta. Dependiendo del contexto, desarrollar con uno u otro framework puede ayudarnos a trabajar mejor en equipo.
No es lo mismo trabajar solo en un proyecto personal que trabajar con un equipo de veinte desarrolladores. No es lo mismo trabajar en un proyecto grande y complejo que en uno pequeño y con un ámbito bien acotado. No es lo mismo trabajar con compañeras y compañeros que tienen un bagaje en front que con un equipo con perfiles más multidisciplinares.
Estos puntos que yo aquí he expuesto son mis razones. Son las razones por las cuales VueJS me ha convencido para mi contexto y mi marco de trabajo. Puede que a ti, un framework con una comunidad abundante no sea importante. Puede que las funcionalidades que te he dicho y que más valor me aportan a mi, a ti no te aporten nada o que no te aporten lo suficiente como para hacer un cambio drástico a VueJS.
Por tanto, no te dejes llevar por mis palabras y, como se debería hacer, ten cuidado, no te fíes de nadie. Prueba por ti mismo las cosas en un desarrollo lo más acotado posible, o por el contrario, lleva el framework a sus límites si necesitas un contexto muy exigente.
Puede que, como me pasó a mi, cuando hagas esas pruebas, su API te convezca más, su workflow te enganche, que te sientas cómodo en su filosofía, en sus conceptos, que te encuentres tan bien desarrollando con VueJS que quizá ya no solo encuentres válidas (o erróneas) mis razones, si no que encuentres tus propias razones para usar VueJS.
Más información | Vue.js
Ver todos los comentarios en https://www.genbeta.com
VER 0 Comentario