En la creación de aplicaciones corporativas al más puro estilo ERP, la evolución de las distintas capas del framework utilizado deben mantenerse siempre actualizadas y consistentes (lease framework como conjunto de tecnologías y arquitectura empleada).
El problema principal es que las aplicaciones desarrolladas en este entorno tienen un ciclo de vida muy largo y deben permanecer lo más agnósticas posible a los cambios tecnológicos y la obsolescencia de muchas de las tecnologías actuales.
Cuando hablamos de desarrollo frontend, este propósito no es tan simple, ya que el ecosistema crece y cambia a una velocidad vertiginosa. Es por esto que la elección de una tecnología de frontend que resulte más o menos estable y que siga una evolución sana es fundamental. En mi opinión, si hacemos aplicaciones ricas siguiendo los principios de las Single Page Applications, la decisión a día de hoy no es para nada sencilla.
Quizá en el transcurso de estos últimos años hayas evaluado para estos entornos distintas soluciones con más o menos suerte, así que muchas de las opciones seguro te sonarán :)
El estado del arte
Para entender los motivantes a la hora de elegir, podemos valorar distintos escenarios (soy consciente de que en estos escenarios voy a nombrar sólo una parte muy pequeña de los frameworks que hay disponibles, así que no te ofendas si tu favorito no se encuentra entre ellos ya que simplemente enumero algunos para dar contexto):
HTML ligero. Basado principalmente en un maquetado HTML con o sin framework CSS responsive que nos ayude en el proceso (en esta parte hemos mejorado bastante gracias a flexbox y un principio de grid css). Como ventaja tenemos la simplicidad y la dependencia de estándares de facto y no de frameworks o implementaciones específicas. Por otra parte, en esta opción partimos de un binding bastante limitado con el DOM, ya que necesitamos alguna "capa" que nos abstraiga de este acceso, haciéndolo menos explícito y más declarativo. Para la integración con componentes ricos y casi para cualquier cosa, debemos utilizar librerías auxiliares.
Single Page Application "ligero". Muy en la linea de la primera opción, pero con una mejor integración con el DOM, del que ya no debemos preocuparnos. Perdemos el contacto directo con los estándares y pasamos a basarnos en algún tipo de framework. Un ejemplos de esta estructura podrían ser librerías especializadas en el manejo de la vista ("V" en MVC) como son React o Vue.js. En cualquier de estos estos casos, la integración con componentes ricos, el routing en la aplicación, la carga de de módulos y otras muchas funcionalidades quedan fuera de la ecuación.
Single Page Application "completo". Además de la integración con el DOM, en este escenario disponemos de otros aspectos necesarios en aplicaciones complejas como es el routing. Si hablamos de frameworks como Angular 1.X o 2.X, la parte de contar con componentes ricos también quedaría fuera del alcance del framework.
Single Page Application "completo" con componentes ricos. Recuerdo inicialmente opciones muy viejunas como qooxdoo, Dojo, SmartGWT o YUI. Ya a día de hoy, estaríamos hablando de opciones como Sencha ExtJS.
En su momento y analizando las opciones disponibles para nuestro entorno corporativo que estaba más orientado a datos que otra cosa, apostamos por ExtJS 3.X allá por el 2009. Este framework venía de la evolución de YUI y aunaba los componentes básicos que necesitábamos en nuestro entorno con una visión de uniformidad y soporte que hacía pensar en que su estabilidad y frecuencia de cambio iba a ser más sencilla de gestionar. Que crédulos éramos entonces ...
La realidad
Incluso eligiendo una solución muy enfocada al desarrollo de aplicaciones corporativas con todos los aspectos que esto conlleva respecto a estabilidad en el tiempo y demás, Sencha ExJS ha sufrido una evolución dramática en los últimos tiempos, motivando cambios de gran calado en el paso a su versión 4, 5 y ahora 6, cosa que no ha sido nada fácil de llevar ante multitud de aplicaciones desarrolladas en distintas versiones y mucho trabajo de actualización entre las mismas.
Esta experiencia nos ha llevado a seguir en la parte del frontend uno de los mantras que tenemos bien aprendidos en la parte del backend: Defendámonos de los frameworks!!!
¿Qué estrategias hemos venido siguiendo para conseguir defendernos de los cambios arbitrarios en los frameworks?
La primera de todas y en mi opinión la más importante, ha sido hacer que el desarrollo de nuestras aplicaciones sea más sencillo y productivo, desarrollando con el tiempo un set de componentes comunes que utilizar en los distintos proyectos. Cuanto más rico sea este set y menos usemos los componentes provistos por el framework de forma directa, más sencillo será añadir funcionalidad nueva y actualizar las aplicaciones ante cambios de versiones.
Esta práctica va un poco en la linea del principio de diseño que nos dice "reduce your API surface", y es que cuanto más nos protegemos de los cambios de una librería de terceros con abstracciones y/o wrappers, más estables son los aplicativos que desarrollamos sobre esta y más controlada está su evolución. Podéis ver una charla interesante sobre el tema aquí:
Después de la reutilización, la segunda linea de defensa debe pasar por intentar evitar que la propia arquitectura del framework fagocite tu aplicación. Si esto sucede, no podrás cambiar ya nunca ni evolucionar su diseño, estando siempre a expensas de las decisiones que se tomen en el contexto del framework de elección. Este caso es especialmente sangrante con ExtJS, el cual pasó de no tener nada de arquitectura, a implementar MVC en la versión 4 y luego posteriormente MVVM en la 5. Una locura en los evolutivos de los distintos aplicativos!!
Por último, conseguir mantenibilidad pasa por controlar el set de tecnologías y herramientas utilizadas por tu frameworks. Si son bastante estándares y el ecosistema evoluciona, no habrá problema, pero si como en el caso de ExtJS en lugar de usar NPM o Webpack o Grunt o Gulp se utiliza un builder propio basado en Apache Ant como es Sencha Cmd, entonces estás claramente en la senda del dolor.
Como veis, no siempre es posible preveer los derroteros por los que te llevará tu framework, así que siguiendo con el principio anterior, no dejes nada en sus manos y sigue siempre la linea de la reusabilidad y de la flexibilidad de cambio.
Siguientes pasos
En nuestra situación actual y siguiendo los principios expuestos, estamos evaluando como conseguir que ExtJS pueda ser utilizado únicamente como un toolkit de componentes ricos, sin necesidad de comprometer la arquitectura completa de nuestra aplicación.
Con la versión 6 y posteriores, ya contaremos con soporte para transpilado de ES6, diseño responsivo y separación de la parte de componentes ricos respecto al resto del framework. No os perdáis la SenchaCon de este año donde se anunció el proyecto Sencha Reactor que permite el uso de los componentes ricos de ExtJS en otros frameworks a través de un bridge especial (en este caso facilitando la integración con React):
De esta manera conseguimos separar los componentes del binding con el DOM, el routing en la aplicación o la propia definición de la arquitectura cliente en general. Esta solución ya comienza a ir un poco más en la linea deseada.
Conclusiones
No creo que nuestro escenario sea especialmente desafortunado, ya que por desgracia los cambios que rompen compatibilidad son más habituales de lo que nos gustaría viendos casos como el de Angular2. No es fácil. Lo que está claro es que estos frameworks de componentes deberían sufrir una transformación en el futuro después de la aparición disruptiva de los Web Components, de forma que la manera de definirlos, reutilizarlos, integrarlos y poder usarlos en distintos dispositivos fuese siempre predecible y estándar, independientemente de su aspecto final y funcionalidad.
Desgraciadamente aun nos queda mucho camino que andar hasta que los navegadores integren de base tecnologías como HTML imports o Shadow DOM, conformándonos mientras con sets de polyfills que nos sirven como punto de partida. Quizá en un futuro podamos ver una integración más clara en frameworks como Angular o ExtJS que trabajan con directivas y componentes, de forma que puedan abandonar sus sistemas de definición propietarios en pro de la estandarización.
Como siempre, el mundo frontend nos depara interesantes movimientos. Deberemos estar atentos y no perder nunca el control de nuestros desarrollos.
