¿Por qué elegimos Hyvä?
Y cómo nos ha ayudado a dar un salto cualitativo en el desarrollo de tiendas online sobre Magento - Adobe Commerce
En esta serie de tres publicaciones hablamos de las razones que nos llevaron a apostar en Ebolution por una nueva plantilla para Magento, y cómo esperamos que ello repercuta positivamente en nuestros procesos, coadyuvando en muchos aspectos del desarrollo, desde lo puramente técnico, hasta influir incluso en el estado anímico de equipos formados por personas, de cara a realizar un mejor trabajo cuanto más a gusto se encuentre con las herramientas de las que dispone.
Introduzco aquí un matiz. Arriba usaba deliberadamente la palabra plantilla puesto que es la más común, de ahora en adelante, en pro de mantener rigurosidad conceptual, me referiré al mismo concepto como tema. Entendiendo por ambas el conjunto de elementos personalizables que conforman la parte visual de una tienda en línea.
Antes de comenzar: qué es Hyvä.
Hyvä es un tema para Magento que, mediante la combinación de una serie de tecnologías web de última generación, está pensado para ofrecer máxima flexibilidad en la implementación de los componentes gráficos de experiencia de usuario que conforman una tienda en línea, desde el punto de vista de los equipos de desarrollo a cargo de dicha tarea.
Eso de “los equipos de desarrollo” puede sonar raro, aunque la salvedad lo sugiera, en ningún momento es mi intención plantear una dicotomía Negocio vs. Desarrollo, por lo que más adelante ahondaremos en por qué en Ebolution pensamos que este enfoque es beneficioso para todos los implicados.
En informática existe una máxima que reza algo así como: “reiniciar (casi) siempre es la solución”. En este caso, con Hyvä, eso es más o menos lo que ha ocurrido. Pero para saber como llegamos a este punto, primero repasemos brevemente de donde venimos, porque no se puede entender la dimensión de Hyvä sin la perspectiva de los caminos que ya hemos recorrido.
Así comenzó todo
La plataforma Magento 2 se lanzó a finales del año 2015, marcando un cambio de paradigma significativo con respecto a su versión anterior, la tan exitosa Magento 1. Además de una muy marcada evolución en todos los niveles ingeniería, dentro de lo que nos atañe en el contexto de este análisis, uno de los cambios más drásticos lo marcó el hecho de que los temas de Magento 1 ya no eran compatibles con la nueva versión. Un ecosistema de temas y módulos desarrollados por terceros, muy prolífico hasta la fecha, se veía obligado a comenzar de nuevo casi desde la casilla de salida.
Un año más tarde, en 2016, Magento lanza el tema Luma. De esta forma dotaba a la plataforma de las herramientas sobre las cuales construir la nueva generación de tiendas en línea. O por lo menos eso esperábamos. Marcaba la visión y las líneas a seguir en las próximas etapas del proyecto.
Luma se basaba en el estado del arte de la tecnología web del momento. Conceptos como componentes reutilizables, preprocesadores de CSS, tecnología JavaScript reactiva y cargada en el navegador en función de su uso, entre otras, eran la respuesta de una plataforma líder de su sector para los retos que se planteaban a mediano plazo.
Aquí comenzó lo que con mucho cuidado llamaré “el problema”. En la teoría, todas las piezas encajan, pero en la práctica no es tan sencillo. Terminamos con un conglomerado de herramientas sueltas que conforman un todo hipercomplejo, a lo cual hay que añadirle el aderezo de los módulos de terceros, tan necesarios para dotar de funcionalidades que adecúan a Magento allí donde no llega de forma nativa, cuando de cumplir con los requisitos de negocio específicos de cada tienda se trata.
El ecosistema de temas de terceros nunca volvió a ser igual. Salvo un par de ellos con cierto renombre, la realidad es que la decisión final de muchos equipos de desarrollo a la hora de afrontar un nuevo proyecto pasaba por implementar el diseño de la tienda desde cero sobre un “tema hijo” del propio Luma. En Ebolution esa ha sido también nuestra línea principal.
Un par de años más tarde, dentro de este panorama, y con una adquisición de Magento por parte de Adobe de por medio, parecía sensato pensar que Luma, o una evolución del tema tendría sentido. No obstante, la apuesta principal, también sensata sin duda, se fue por una línea completamente distinta, las Progressive Web Applications, o PWA para los amigos. La punta de lanza de esta apuesta es un tema llamado Venia, y con él todo un conglomerado de esfuerzos apuntando en la nueva dirección.
Muy brevemente, con PWA, el desarrollo del frontal de la tienda ya no estaría incorporado dentro del código del propio Magento, sino que pasa a ser un componente independiente que se conecta con este, usando como interfaz su API Rest, o mejor aún la nueva y reluciente joya del mundillo para ese momento, GraphQL.
No entremos a valorar las PWA, sólo un par de afirmaciones:
Se justifica en la premisa de marcar una línea divisoria clara entre el frontend y el backend, ofreciendo flexibilidad e independencia, especialmente para el frontend desde el punto de vista del desarrollo, puesto que hace opcional la utilización del lenguaje de programación PHP en el que se basa Magento, ofreciendo la libertad de elegir cualquier tecnología web, y poniendo como única condición la de conectarse al backend (Magento) a través de la interfaz seleccionada (API Rest o GraphQL).
Diversificar esfuerzos, depende de en qué condiciones, puede no ser la bala de plata que mejor contribuya en todos los casos. Puede incluso añadir al proyecto una capa adicional de complejidad técnica y organizativa muy pesada, traducida principalmente en costes, haciendo que su viabilidad en el pequeño o incluso mediano comercio sea menos factible.
El problema
Aquí es donde está el meollo del asunto, el problema principal es que la apuesta de Magento (y ahora Adobe) por PWA parece haber dejado completamente de lado a Luma, puesto que prácticamente sólo recibe actualizaciones de seguridad y nuevos desarrollos para soportar contadas funcionalidades que se han ido añadiendo a lo largo de los últimos años.
No existe, ni parece que vaya a existir, una propuesta de gran envergadura para su evolución. El camino natural parece ser dejarle morir, pero, ¿qué pasa si no queremos o podemos ir a PWA?
La primera respuesta que se me ocurre es sencilla, tenemos dos opciones:
Lidiar con un stack tecnológico desactualizado.
Escoger una solución de terceros.
Como el propio titulo de la publicación lo sugiere, en este momento me inclino más por el punto 2, pero antes veamos cual es el problema con el punto 1.
Para poder enumerar las carencias que percibo como más significativas, necesitamos poner algunos nombres propios.
KnockoutJS
Es un framework de JavaScript. Sin duda uno de los precursores del modelo de facto en el desarrollo frontend actual, el MVVM. Seleccionarlo como tecnología principal en el año 2013 o 2014, cuando correspondiera tomar un decisión de este calado, estaba, a mi juicio, completamente justificado.
La cuestión es que, con el tiempo, KnockoutJS se quedó como eso, como un precursor, siendo su evolución prácticamente nula en comparación con otros jugadores que han salido a competir en un campo especialmente movido como lo es el de los frameworks de JavaScript. Las comparaciones son odiosas, pero en este punto es necesario al menos mencionar a Angular, React o VueJS. Es muy probable, amable lector que si has escuchado algún nombre de frameworks JavaScript, lo más seguro es que recuerdes alguno de los últimos 3, y el primero te suene poco o nada.
El caso es que la adquisición de KnockoutJS nunca fue suficientemente fuerte como para generar la consecuente base de conocimiento, que a la postre se tradujera en recursos de formación para la comunidad encargada a su vez de liderar, con nuevos proyectos, funcionalidades y necesidades, el impulso necesario para que un ecosistema basado en esta tecnología floreciera.
La última versión major de KnockoutJS se liberó en Febrero del 2019, centurias en años informáticos, y milenios en el universo de frameworks de JavaScript.
RequireJS
Como dicen por ahí, la historia no se repite, pero rima.
Veremos justo en el siguiente punto que diseñar un frontend basado en componentes independientes era una de las premisas fundamentales de Magento 2. No obstante, por la forma como se diseñó su estructura, cada componente necesitaría al menos de un script JavaScript para funcionar. En un escenario donde HTTP2 aún no era aún una realidad, orquestar la carga de tal vez cientos de ficheros necesarios para el funcionamiento de una página podía llegar a ser un problema.
Aquí aparece RequireJS, básicamente un orquestador de carga de ficheros y módulos JavaScript. Es decir, al momento de comenzar el renderizado de la página, en lugar de incluir dentro del <HEAD> todos los scripts que se van a necesitar, se incluye únicamente RequireJS, y este se encarga de ir paulatinamente cargando los ficheros JavaScript en el navegador según los componentes que conforman dicha página los van necesitando.
La idea suena fantástica, pero a día de hoy ya no es necesaria, o por lo menos no con el enfoque con el que lo hace RequireJS. No obstante, por limitación de la propia librería, acabamos atados a la necesidad de que absolutamente todo el código JavaScript que incluimos en nuestras páginas, por simple que sea, deba tener una forma de estructurarse muy concreta.
Por hacer el mismo ejercicio de la sección anterior, la última versión major de RequireJS se liberó en 2016, y la última vez que salió alguna actualización oficial fue en 2018. El tiempo no debe ser un problema en si mismo, de hecho, puede que simplemente una librería no necesite nuevas actualizaciones, se me hace un poco extraño la verdad, pero es una posibilidad.
Aún así, pensemos únicamente en el hecho de que nuestro frontend estaría completamente atado, de forma innecesaria, a una mecánica de uso del código JavaScript muy particular, dependiendo de un proyecto que a día de hoy no da señales de vida.
UI Components
Incluyo este punto por una razón muy concreta, y estrechamente relacionada con lo que comentaba al principio acerca de la motivación, y en general, el buen hacer de un equipo de programación cuanto más a gusto se encuentra con las herramientas que utiliza.
Los UI Components son la propuesta de Magento para el diseño de una web modular. Bajo este concepto, la combinación de piezas independientes, pero interoperables, permitiría que cada página, tanto de la parte frontal de la tienda (front-office), como su sección de administración (back-office), funcionara como una composición de todos los elementos.
Dicho así la idea es cuanto menos estupenda. Pensar en que en el header del front-office pueden actuar distintos componentes, por ejemplo: un menú, un enlace al panel de cliente con mensaje de bienvenida personalizado y un enlace al buscador, y que cada uno de esos elementos es independiente, es beneficioso desde muchos puntos de vista.
Ni hablar de las páginas habitualmente más complejas de los Ecommerce, como el carrito, o el checkout, donde hay varias cosas sucediendo al mismo tiempo: listado de productos, precios, descuentos, gastos y opciones de envío, métodos de pago disponibles, etc.
La cuestión es, y voy a intentar decir esto con mucho cuidado, dentro de la comunidad de desarrollo de Magento hay consenso en torno a la idea de que la forma de implementar estos componentes es extremadamente compleja, hasta el punto incluso de no compensar el esfuerzo que requiere para el beneficio que aporta.
Este escenario tiende a generar fricciones, puesto que algunos de los efectos inmediatos de una curva de aprendizaje extremádamente pronunciada tienden a ser de desánimo, e incluso rechazo, de manera que a la larga termina convirtiéndose en un problema para la gestión del propio proyecto.
No se trata de huir de la complejidad porque si, se trata de evitarla al máximo siempre que sea factible. De hecho, para muestra un botón, lo esperable sería que una hipotética evolución de Luma contemplara un uso mucho más extendido de los UI Components, pero eso no sucedió, simplemente es una pieza del puzzle sobre la cual Magento basó su sección más importante (el checkout), y que luego parece no haber tenído justificación real en el resto del tema, salvo contadas excepciones aquí y allá.
¿Y ahora qué?
En este punto cualquiera podría juzgar mi opinión de sesgada, o decir que me he dedicado a destacar tres piezas separadas como justificación de un movimiento en una dirección concreta. No ha sido mi intención, son sólo ejemplos de como, a mi entender, el desarrollo de frontend en Magento necesitaba un camino alternativo al que ofrece Luma, sin ir necesariamente hacia PWA.
En Ebolution contamos con muchos años de experiencia acumulada en el desarrollo de tiendas sobre la plataforma Magento, casi siempre de una forma que no tiene un término concreto acuñado para definirla. Básicamente el frontend está dentro del propio proyecto Magento y funciona como un todo.
Algunos llaman a esto directamente “Monolith”, otros han pasado a llamarlo “Composable”, pero aún sin disponer de un término específico, entendemos que es ese opuesto al “Headless” sobre el que funciona PWA donde tenemos un mayor valor acumulado que podemos seguir aprovechando para aportar a nuestros clientes, no desde el punto de vista de cerrarnos a la evolución, sino desde el espíritu de evolucionar con un sentido y estrategias bien definidas.
Aquí es donde entra Hyvä, pero como adelantaba al principio, dejemos esta primera parte como una exposición de motivos, la cual hilaremos en la siguiente entrega con los detalles de cómo Hyvä afronta esta problemática y ofrece soluciones técnicas de vanguardia detrás del lema:
“eCommerce made happy”
Qué buena explicación, compañero, a algo tan complejo.
¡Necesitamos más posts tuyos como este!