Algunos apuntes para elegir framework JS en una app

Cuando se comienza un desarrollo y decide uno hacerlo bajo un framework, elegirlo es una cuestión muy peliaguda. Es facil dejarse llevar por la moda, o porque tal o cual empresa lo utilizan, pero la verdad es que habría que analizar las preferencias en la manera de trabajar de cada uno, su coveniencia para el proyecto concreto, tiempos de desarrollo y muchos otros factores. No es un tema menor, la arquitectura de nuestra aplicación puede quedar fuertemente atada al framework y por tanto la evolución y escalado de la misma.

Como no quiero escribir un post gigante, porque el tema da para mucho, voy a explicar sólo algunos aspectos y respecto a algunos frameworks en JS del lado del cliente. Enlazando con el post que ya publiqué explicando en qué consiste Apache Cordova, comentaré un par de puntos que me parecen importantes a la hora de decidir en el mundo de las apps en JS.

¿Necesitas sólo JS?

Puede parecer una pregunta extraña, pero si por tiempo o requerimientos necesitas una solución que también gestione la interfaz gráfica y te de una base sólida respecto a los estilos, eso condiciona tu decisión. Existen opciones como Ionic u Onsen UI, que se encargan de ambas cosas pero en su caso están atadas al uso de Angular JS, por lo que si decides utilizar una de estas opciones tendrás que tragar con el Framework que incorporan. No tiene que ser un problema, sólo tienes que tenerlo claro.

Personalmente no recomiendo opciones como jQuery Mobile. Creo que son pesadas y sinceramente me parece que su aspecto visual se ha quedado bastante atrás para lo que son las necesidades reales de una aplicación a día de hoy.

En cualquier caso, teniendo un sistema de routing que gestione el enrutamiento, las transiciones entre vistas y el aspecto general de la app, si se prefiere, se puede perfectamente crear a medida. Depende por supuesto de las necesidades y tiempos del proyecto.

Suponiendo que quieras elegir específicamente un Framework por otras cuestiones, veamos otro par de puntos.

¿Qué necesitas del framework?

Tomando como base Angular, Backbone y React, hay que aclarar que no son lo mismo. En el caso de React, del que probablemente hayas oido hablar, se trata sólo de manejar la interfaz de usuario. No incorpora modelos ni controladores. La gente de React lo define como la parte de la Vista en un Modelo/Vista/Controlador.

Si hablamos de Angular y Backbone, aunque con muchas diferencias y en algunos casos otros nombres, si que ambos incorporan un sistema de routing, modelos y el concepto de controladores y gestión de plantillas.

Modularidad vs Todo incluido

Angular se ha hecho extremadamente popular. Lo cierto es que proporciona métodos para realizar operaciones complejas de una manera realmente rápida. Si uno se ajusta a la manera de hacer del propio framework y una vez superada la curva de aprendizaje, se puede prototipar y desarrollar proyectos bastante rápido porque el framework provee de recursos para gestionar muchas necesidades como el binding de datos o la capacidad de trabajar sobre esos datos directamente en las plantillas marcando directrices en el HTML. Esto, evidentemente permite ahorrar la escritura de mucho código JS.

Pero como contra se podría decir que Angular obliga si o si a hacer las cosas a su manera y se corre el riesgo de aprender a implemetar las cosas en Angular y no a solucionar realmente los problemas en JS. Angular hace mucha mágia, pero como tal, toca muchas veces hacer casi un acto de fe y sobre todo pasar por el aro. Mención aparte merece el tema de algunos conceptos complejos que Angular introduce como su propio concepto de “scope”.

Backbone, por contra, incluye menos herramientas montadas por defecto, lo que hace que a veces sea necesario escribir más código. Por contra se podría decir que trabaja más en Javascript “puro” y sobre todo de una manera más modular. La curva de aprendizaje no es tan alta pero como digo, el tiempo de desarrollo es posible que se amplie un poco. Si se opta por la filosofía de Backbone, recomiendo echar un vistazo a Marionette, que construye sobre él y soluciona muchas de las habituales cosas que se le suelen reclamar a Backbone a nivel de arquitectura.

En cuanto a dependencias, Angular lleva todo incorporado, mientras que Backbone depende de Undersore para algunas de sus operaciones y jQuery para la manipulación del DOM.

Comunidad y no hype

Es importante cuando se toman estas decisiones, leer acerca de lo que comenta la comunidad al respecto. Y cuando digo comunidad no hablo de la última discusión en Hacker News o que ayer un desarrollador conocido dió una charla sobre el tema, sino a leer posts o soluciones elaboradas sobres los pros y contras de uno y otro. Así como echar una ojeada al desarrollo de componentes y plugins alrededor y sobre todo y muy importante, la calidad y claridad del código interno de la librería.

Otras opciones

Existen otros muchos frameworks JS interantísimos y potentes como Ember o se puede optar por unir piezas como KnockoutJS para el MVVM como patrón de diseño y utilizar elementos como pagerjs para gestionar el routing que no incluye si uno es de la filosofía de usar componentes pequeños intercambiables en lugar de grandes librerías.

Por últmo, micro frameworks.

Si se quiere optar por la opción de un micro framework que sólo proporcione algunas opciones algunas funcionalidades concretas, un buen comienzo es la web de microjs.com,  donde podemos especificar lo que necesitamos y obtener una lista de sugerencias.

Pablo Bernardo
Pablo Bernardo

Hola, soy Pablo. Soy programador frontend, padre, estudiante de zen y otras cosas. Para saber más, lee algunas entradas.