Un mes aprendiendo de EmberJS

global_436299939

Desde hace un mes más o menos, he empezado a usar EmberJs como framework JavaScript por motivos profesionales. Lógicamente, todavía no me considero ningún experto y pueda que muchas cosas de las que aquí comente sean erróneas debido al poco tiempo que llevo con ello. Sin embargo me gustaría exponeros la experiencia que ha supuesto para mi estos días y las cosas buenas y no tan buenas con las que me he ido encontrando.

Empecemos por el principio…

Como decía, mi andadura con EmberJs ha sido del todo casual ya que por motivos profesionales, he empezado a trabajar en un equipo encargado de desarrollar la parte Frontend de una WebApp de considerable tamaño. El proyecto se encuentra en una etapa de bastante madurez y puedo decir, sin miedo a equivocarme, que es uno de los mejores códigos que he visto en mi, todavía, corta carrera profesional.

EmberJs nos está ayudando a dar forma a nuestro código JavaScript y nos está permitiendo generar componentes de interfaz con comportamiento reutilizable. EmberJs es una de las tantas alternativas con las que contamos actualmente los JavaScripters como puedan ser AngularJs, ReactJs o BackboneJs.

Como todo en esta vida, hay cosas que nos gustan más y cosas que nos gustan menos. No existe el framework perfecto y cada uno de ellos tiene aquello que su creador ha visto que es importante implementar y cómo se tiene que hacer. Así que, a continuación os quería explicar qué cosas me gustan y cuales les no.

Esto es lo que no me gusta de ti

Como me pasa últimamente con casi todo este tipos de frameworks, una vez que decides usar no de ellos para implementar un proyecto, es muy difícil salirse un poco de las lineas marcadas. Con EmberJs no es una excepción. Y esto que puede suponer una ventaja en muchos aspectos (la rigidez de un framework hace que todos los desarrolladores, tengan la experiencia que tengan, sigan esas lineas maestras marcadas), para mi últimamente empiezan a ser un impedimento.

Si un proyecto es pequeño, moverse por una estructura tipo EmberJs, puede perjudicarnos y tener que dedicar tiempo a montar una arquitectura que para nosotros va a ser demasiado. Sin embargo, si estamos en un proyecto complejo, que se sale de lo común, esa rigidez también puede sernos perjudicial ya que nos va a ser más difícil salirse del camino trazado.

En realidad, estoy siendo un poco injusto con EmberJs ya que, como he dicho, esto es un mal que le veo a estos grandes frameworks que intentan abarcar más de la cuenta. Cada vez soy mas partidario que montando una buena arquitectura en nuestro aplicativo y juntando aquellas microlibrerias que nos sean indispensables, podemos cumplir en un alto porcentaje de proyectos.

Para el que espere encontrarse una librería liviana o que no sea compleja, EmberJs no es su framework. La curva de aprendizaje de EmberJs, me parece relativamente alta. Es cierto que una vez que se entienden los conceptos y que tomas la filosofía de trabajar de EmberJs como tuya, todo fluye e incluso se le coge mucho gusto a programar con él. Pero tengamos en cuenta esto: necesitaremos tiempo y muchas pruebas de conceptos antes de poder embarcarnos en un desarrollo a producción.

¿Por que viene este problema? EmberJs es un framework que funciona por medio de convenciones en detrimento de las configuraciones. Esto quiere decir que el nombre que le demos a nuestros elementos es importante a la de definir lo que necesitamos del framework. La convención en los frameworks no me parecen una mala idea. Me gusta porque aporta productividad y no tenemos los típicos ficheros enormes donde vamos configurando todos los elementos.

En MVC.NET ya he trabajado así y es un concepto que ayuda. El problema es que el concepto hace que podamos cometer errores más facilmente y que las cosas a simple vista sean menos intuitivas. Como dice un compañero, hay que desconfiar de las cosas que rezuman magia. Y en esto EmberJs nos hace todo un recital.

Aunque lo comentaremos en sus puntos fuertes, he de decir que el ciclo de vida de EmberJs me gusta mucho. Este ciclo de vida consta de una serie de elementos comunes como pueden ser los Routes, Controllers y Views. Cada uno tiene su cometido y se ejecutan en un orden establecido. Estos elementos cuentan con métodos que podemos usar y sobrescribir. Son los llamados hooks. Métodos que se ejecutan dentro de un ciclo de vida o ‘pipeline’ y que nos ayudan a realizar tareas.

El problema que veo es que cuando un elemento empieza a crecer un poco, es difícil saber qué es un hook de lo que no lo es. Cuando lees código Ember por primera vez, te choca bastante y es el desarrollador el encargado de hacer la separación entre métodos hooks y métodos propios del elemento. Esto hace que el aprendizaje sea complicado. No son muchos los hooks, es cierto y aprendérselos es fácil. El problema vuelve a ser la curva de aprendizaje y el intentar salir de esos patrones de ejecución que ha establecido EmberJs.

Todos estos elementos de los que hablamos pueden que hereden los unos de los otros o que se comuniquen entre si. Incluso se pueden crear módulos con funcionalidad transversal que se inyecten a lo largo de toda la aplicación. Este árbol jerárquico, me parece bueno e incluso útil. El problema que le veo es lo difícil de apreciar a simple vista con que funcionalidad contamos en cada uno de los elementos.

AngularJs me parece mucho más intuitivo en este aspecto. Simplemente tienes que mirar el principio de un fichero para saber que se está inyectando a un elemento y que funcionalidad podemos usar. Hecho en falta algo así o yo quizá no sepa cómo hacerlo todavía.

Y esto es lo que me encanta de ti

Pero el pipeline de EmberJs es una maravilla como ya dije. Una vez entendido el proceso y la herencia entre elementos, el desarrollador sabe que tiene que hacer en cada momento, que rol tiene se tienen que desarrollar en cada componente. Esto lo apreciaba bastante en BackboneJs (en muchas cosas me recuerda a un BackboneJs pero en potente) y aquí es de lo mejor que tenemos. En AngularJs, a la hora de desarrollar lógica de negocio, se da mucha libertad al desarrollador para que la implemente donde desee y esa libertad podía desembocar en verdaderos código espagueti y controladores enormemente grandes. Pero aquí no, todo fluye, todo está hecho para que la aplicación gire alrededor de los modelos. Los modelos como grandes protagonistas de una gran parte del framework.

Me gusta mucho que EmberJs use HandlebarJs. Eso si, un HandelbarJs vitaminado. Siempre me pareció una librería con una sintaxis increíble pero con una funcionalidad muy corta para un motor de vistas serio. Aquí EmberJs se encarga de utilizar el concepto de componente y a nuestros elementos tradicionales y nuestros helpers de HandlbarJs ahora se unen elementos de interfaz que pueden tener comportamiento.

Muchos frameworks están dando un giro a su forma de entender las WebApps y están entendiendo que uno de los núcleos tienen que ser el desarrollo de componentes de interfaz reutilizables. Google se ha dado cuenta y está cogiendo muchas cosas de EmberJs en este sentido para su Angular2 y ReactJs bebe de esta misma fuente, mejorando lo que ya había. (EmberJs prepara también su segunda versión del framework, asi que veremos con lo que nos sorprenden)

Otra cosa que me encanta es lo rápido que es. EmberJs es un framework que renderiza y realiza las acciones rápidamente. Es uno de los frameworks que han hecho que mis aplicaciones más se parezcan a aplicaciones nativas hasta el momento. Creo que ReactJs es la única que actualmente puede hacerle sombra en este sentido. El poder compilar las vistas en un único fichero con grunt, me parece una maravilla y lo que me da la mayor sensación de aplicación y no de web.

Conclusión

Todavía me queda mucho por aprender y seguro que con el tiempo esta opinión que tengo actualmente habrá cambiado completamente. EmberJs un framework muy maduro y curtido, con una curva de aprendizaje grande, pero que puede llegar a ser muy disfrutable.

Para mi sin duda, un gran descubrimiento, no me esperaba tener que trabajar con él y me he llevado una grata sorpresa. Espero que vosotros también os animéis a trabajar con él y mejore la comunidad en España que escasea.

A lo largo de estos meses y cuando haya podido aprender más, iré publicando entradas, explicando algunos conceptos o algunos trucos que mi equipo usa y que veo esenciales para entender y mejorar en EmberJs.

Nos leemos 🙂

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s