Tecnologías más usadas en Javascript: “The state of Javascript 2016”

Hace unas semanas Sacha Greif creó una web con una encuesta online muy interesante. El objetivo era conocer el estado actual de Javascript preguntándole directamente a los desarrolladores.

Las preguntas trataban de averiguar cuáles son las herramientas, frameworks y nuevas tendencias en Javascript. Todo muy bien organizado por temáticas y con una usabilidad que hacía que rellenarla fuera un placer.

La encuesta rápidamente se extendió por las redes sociales, fue contestada por más de 9000 desarrolladores y ya se han publicado los resultados.

A continuación paso a comenatarlos.

JAVASCRIPT FLAVORS O “SABORES DE JAVASCRIPT”
A cada uno le gusta consumir Javacript de una manera, estos son los resultados entre los “ganadores” de la encuesta para esta sección:

JavaScript Flavors
JavaScript Flavors- Captura de pantalla de http://stateofjs.com/2016/flavors/

De aquí destacaría dos cosas:

  • 1. Los programadores ya han dado el salto a ES6, la nueva especificación de Javascript, a pesar de que no está totalmente soportado por los principales navegadores. Esto es posible gracias a transpiladores como Babel, que transforman ES6 a ES5.
  • 2. Muy por detrás de usar Javascript de forma nativa, Typescript es la forma favorita de “no usar” Javascript. Recordemos que Typescript es un superconjunto de Javacript que le añade definición de tipos.

 

FRONTEND FRAMEWORKS

Front-End Frameworks
Front-End Frameworks – Captura de pantalla de http://stateofjs.com/2016/frontend/

En este caso el ganador está claro: el framework desarrollado por Facebook React es el único que vence a utilizar simplemente Javascript sin frameworks. Aún así vemos que Angular1 tiene mucha fuerza en la comunidad de desarrolladores y Angular2 viene con fuerza y muchas expectativas siendo el Framework que más desarrolladores quieren aprender, recordemos que su primera versión oficial no tiene ni un mes de vida.

Lo que me sorpendió a mí y a muchos desarrolladores que también lo señalaron es que no se incluyera en la encuesta el framework aurelia.io. Creado por Rob Eisenberg, que estaba en el equipo de Angular2 y lo abandonó por discrepancias en su diseño.

 

STATE MANAGEMENT o “GESTIÓN DEL ESTADO DE LA APLICACIÓN”
Concepto de mucha actualidad. Nuestras aplicación (lo veamos o no :)) tiene siempre un estado. De estos estados surge la representación gráfica que vemos cada momento en pantalla. El problema está en que a pesar de que nuestro código sea excelente, si no hacemos una correcta gestión del estado, en aplicaciones asíncronas podemos acabar teniendo un time-travelling spaguetti (término acuñado por Eric Elliott). Esto es que según el orden en el que se carguen las llamadas asíncronas, nuestra aplicación se muestre de una forma u otra y nos cueste intuir cómo hemos llegado a ciertas situaciones o simplemente reproducir uno de esos estados. Incluso podemos llegar a sentir que nuestra aplicación no es determinista lo que provoca un gran desasosiego. Por eso es mejor prever que curar y ya hay librerías para ayudarnos en esta labor.

Aquí no hay color, la ganadora es Redux, empujada por React ya que suelen usarse juntas, aunque no tiene porqué.

State Management
State Management – Captura tomada de http://stateofjs.com/2016/statemanagement/

 

API LAYERS
Y así es como más accedemos al API del servidor:

apilayers
API – Captura tomada de http://stateofjs.com/2016/api/

Peticiones a un API REST es la forma más popular de consumir los servicios publicados por el servidor. En segundo lugar tenemos Firebase como  el segundo más usado y GraphQL es un lenguaje de consultas para pedirle al servidor la información que exactamente necesitamos, puede ser implementado en cualquier lenguaje e integrado en cualquier aplicación. Sin embargo, Firebase, aunque muy potente, es un servicio de Google que pretende sustituir todo o parte de nuestro backend, y por tanto su utilidad está limitada a ciertos casos.

 

FULL STACK FRAMEWORKS
En este apartado se analizan los conjuntos de tecnologías o frameworks que se pueden utilizar como solución en la que desarrollemos en Javascript tanto en frontend como backend para reutilizar la mayor cantidad de código posible.

Full Stack
Full Stack – Captura tomada de http://stateofjs.com/2016/fullstack/

Los ganadores son MEAN y Meteor. Si bien es cierto que se puede observar que Meteor tiene un porcentaje muy alto de desarrolladores que saben de su existencia y no lo usuarían. Esto se debe a que en Meteor  la lógica de cliente y de servidor puede convivir junta incluso en un mismo fichero, una decisión muy polémica pero que al fin y al cabo es una característica diferenciadora y de uso opcional. Por otro lado MEAN consiste en integrar un stack de tecnologías donde Javascript es protagonista: Angular para el cliente,  Node + Express.js para el servidor y MongoDB para la base de datos.

 

TEST FRAMEWORKS
Por supuesto en estos últimos años han surgido potentes herramientas de testing para Javascript, estos son los resultados de las más populares:

Full Stack - Captura tomada de http://stateofjs.com/2016/testing/
Testing – Captura tomada de http://stateofjs.com/2016/testing/

Vemos que hoy en día reinan Mocha y Jasmine. Los dos son frameworks de tests muy completos, que se pueden ejecutar en Node.js o desde el navegador web. En el tercer lugar aunque todavía no muy conocido encontramos Enzyme. En este caso no estamos hablando de un framework de tests, sino de un añadido que puede ser usado con cualquier framework y sirve para facilitar el testing de las salidas de los componentes de React.

A pesar de que no aparece en la lista os invito a probar Tape. Aquí un artículo del fantástico Eric Elliott explicando algunas de sus razones para usarlo: Why I use Tape Instead of Mocha & So Should Yo

 

CSS
De acuerdo, esto no es Javascript, pero si quremos desarrollar una aplicación de cliente en Javascript, casi siempre tendremos que utilizar CSS y HTML para las vistas.

css
CSS – Captura tomada de http://stateofjs.com/2016/css/

La preferencia es usar CSS a secas o SASS que le gana claramente la partida LESS. Tanto SASS como LESS son extensiones del lenguaje CSS con características muy deseables como son el poder definirnos variables, anidar reglas CSS o crear ficheros parciales que se puedan importar en otros con el fin de reutilizar código. Necesitan compilarse en CSS plano ya que los navegadores no interpretan directamente su sintaxis.

 

BUILD TOOLS
Cuando vamos a desplegar una aplicación Javascript, previamente debemos realizar una serie de tareas como son: unir todo el Javascript en un sólo fichero, minificar el código, ofuscar el código, compilar en Javascript plano todo el código que hayamos escrito en otros lenguajes, traducir nuestro Javascript de una versión superior a la que realmente implementan los navegadores, y así un largo etcétera que depende de las elecciones adoptadas para nuestra aplicación.

Por suerte existen muchas herramientas para automatizar este tipo de tareas y nos permiten abstraernos y despreocuparnos mientras desarrollamos:

buildtools
Build tools – Captura tomada de http://stateofjs.com/2016/buildtools/

Vemos que los protagonistas son Webpack y Gulp.

Webpack es un herramienta de bundling, es decir, sirve para interpretar nuestro código y juntar todos los fuentes en un único fichero. Muy interesante cuando en Javascript hay muchas formas de importar/cargar dependencias de unos ficheros a otras y no son soportadas por los navegadores. De las que aparecen en la gráfica la alternativa sería Browserify.

Gulp, a diferencia de Webpack, se trata de un lanzador de tareas de propósito general. Puede ser utilizado junto a Webpack para el bundling y a parte automatizar procesos como iniciar el servidor de desarrollo, ejecutar los tests de nuestra aplicación, etc. Gulp hace años que adelantó en popularidad a su alternativa: Grunt.

En esta pregunta de la encuesta eché en falta algo que los desarrolladores recordaron. NPM como gestor de tareas. Todo lo que se puede hacer con Gulp y Grunt se puede hacer con scripts de NPM, y ya que a día de hoy seguro que vamos a usar NPM como nuestro gestor de dependencias ¿por qué añadir dependencias innecesarias en nuestro proyecto? Os dejo un enlace a un artículo de Cory House al respecto: Why I Left Gulp and Grunt for npm Scripts

 

FRAMEWORKS PARA APLICACIONES MÓVILES

mobile

Aquí los resultados están muy repartidos. Mi interpretación de los resultados es:

Si lo preferimos y nuestros requerimientos encajan, podemos realizar una aplicación híbrida usando Cordova / PhoneGap (que son prácticamente lo mismo…).

Para aplicaciones nativas, lo más popular es salirnos de Javascript y usar los IDEs y herramientas suministradas por las distintas plataformas o apostar por React Native, que acaba de llegar y ya tiene una gran acogida.