Las tecnologías de componentes web son una realidad que ha llegado a nuestros días. Hoy por hoy todos los frameworks de mercado y todos los profesionales que desarrollan productos digitales sobre la web hacen uso de este tipo de soluciones para encapsular modelos de interacción sobre la base de contenidos visuales. Sin embargo, el cambio paradigmático no está tanto en aspectos tecnológicos como pareciera pensar inicialmente, sino más bien en consideraciones de carácter metodológico. Y es que lo verdaderamente importante es crear catálogos de componentes bien formados que den respuesta precisa y adecuada a cada una de las necesidades de interacción que surgen en el marco de las soluciones web. Construir catálogo significa dejar de pensar en producto para pensar en dominio, dejar de operar desde la descomposición modularidad para construir en base a la reutilización compositiva, y dejar de pensar en desarrollo de componentes locales a proyecto para crear un verdadero lenguaje de composición declarativo que de forma a toda una superficie visual funcional y sin fisuras experienciales. Conocer los principios fundacionales del paradigma de componentes, la estructura anatómica y contractual de los mismos y las etapas del proceso metodológico de construcción de catálogos es punto clave para la obtención de éxito en este tipo de iniciativas.

El desarrollo de soluciones digitales se ha enfocado, de manera convencional, como un proceso que nace del diseño formal y sistemático de modelos de información que se desarrollan y despliegan en el lado del servidor. Solo entonces son consumidos por clientes específicos que elaboran soluciones visuales a medida para los modelos de información así diseñados. Esta aproximación implica grandes ventajas con respecto a los desarrolladores de back que gozan de libertad absoluta en cuanto a la toma de decisiones refería a cómo diseñar los modelos de información subyacentes y cómo exponerlos en base a un espacio de recursos de acuerdo a los principios de las arquitecturas REST. Sin embargo, esta aproximación es penalizante en relación a los esfuerzos ímprobos que tienen que hacer los equipos de front para adaptarse de manera recurrente y sistemática a la demanda cambiante de la parte del back. Se impone, en este sentido, una inversión de control relacionada con la forma en la que deben ser enfocados los esfuerzos de desarrollo. Dado que los modelos de interacción en la parte del front son recurrentes y limitados, tiene sentido permitir que sean los desarrolladores de esta parte los que dirijan los procesos constructivos demandando a los desarrolladores de back que expongan un modelo de interrogación y respuesta adaptado a las necesidades visuales y interactivas que demanda la interfaz.

En los últimos 20 años la web se ha reinventado recurrentemente a si misma pasando de ser un mero expositor de contenidos estáticos a ser una verdadera plataforma de ejecución que da soporte a toda la interacción colaborativa entre los usuarios. Y es que ciertamente, el cambio no ha sido meramente tecnológico, que también, sino que se advierte una transformación igualmente relevante de carácter cultural referida a la forma en la que los usuarios perciben y consumen este medio digital. En particular, en todo este tiempo los usuarios han pasado de tener un rol meramente pasivo como meros consumidores observantes a mostrar una verdadera participación activa como contribuidores de contenido. Me gusta pensar que toda esta evolución se ha producido a lo largo de tres grandes transformaciones que dan lugar a sendas webs bien diferenciadas: la web nomádica, la web feudal y la web consumista, aquella que los usuarios vivimos hoy en dia. Y es que lo cierto es que cada etapa de este recorrido histórico tiene sus condiciones y sus principios fundacionales. Ser conocedores de estos aspectos es especialmente relevante para los técnicos y profesionales que creamos soluciones sobre las arquitecturas de canales digitales que proporciona la web y, si queremos ser buenos asesores de nuestros clientes, tendremos que conocer bien este relato y los principios asociados. Porque los usuarios siempre estarán donde quieran estar y no donde les pidamos que estén.