Get best of the week

Arquitecturas modernas de front-end (Parte 2)

imagen

La segunda parte del artículo " Arquitecturas front-end contemporáneas ", que discute la arquitectura del front-end en términos de distribución de flujos de datos. Comience aqui

Implementación


Algoritmos generados por DOM (algoritmos infundidos por DOM)


La técnica, introducida y dominada por la biblioteca jQuery , realmente fue el comienzo de escribir aplicaciones cliente a gran escala, aunque de hecho jQuery no resolvió problemas arquitectónicos. Fue diseñado para facilitar la manipulación del árbol DOM cuando había demasiadas inconsistencias en el comportamiento del navegador. Esto proporcionó una API independiente del navegador.

No creo que esto haya sido intencional, pero jQuery ha simplificado la API DOM hasta tal punto que fue difícil distinguirla de las API habituales del lenguaje de programación. Esto, a su vez, permitió a los desarrolladores mezclar literalmente el nivel de DOM API ( Ver ) con la lógica de negocios ( Modelo ).

Una vez más, todavía estamos en el contexto del mismo MVC del lado del servidor. Esto es solo una secuela. No hay una inversión real de control. El control general sobre las vistas / páginas todavía está determinado por el código del lado del servidor.





En el fragmento de código anterior, el Modelo, la Presentación y el Presentador / Controlador se combinan de alguna manera en una estructura de código monolítico. Este es el caso cuando el Modelo consta de una sola propiedad. Imagine intentar crear una aplicación web sin un ciclo de exploración del servidor (como SPA). Sería imposible manejar todo esto de una manera conveniente. El código para interactuar con el DOM es penetrado por el resto de la lógica de la aplicación y, por lo tanto, se conoce como el algoritmo infundido por DOM (no estoy seguro de que haya un término oficialmente)

Backbone.js - MV *


Como hemos visto, en jQuery, al desarrollar aplicaciones, la forma de estructurar y organizar nuestro código está claramente ausente. Aquí es donde apareció Backbone.js como la próxima solución evolutiva. Fue una de las primeras bibliotecas en traer los beneficios del estilo MVC del lado del cliente.



Si miramos el diagrama de flujo de datos Backbone, veremos claramente el modelo y la vista, pero no hay un objeto equivalente al controlador. Las plantillas están evolucionando, y MVC del lado del cliente es simplemente una evolución de las arquitecturas MVC anteriores. Durante esta evolución, gran parte de la comunidad JavaScript estuvo de acuerdo con la definición del modelo y la vista, pero no hubo consenso sobre el controlador. Dado el entorno del cliente, la idea de Controller no es muy adecuada. El controlador se deja abierto para interpretación.

En cuanto a Backbone, no hay controlador en él. ¿Entonces qué es esto? ¿Es MVC, MVP o MVVM? Tomando prestado de la definición de servidor MVC, el controlador tiene dos responsabilidades, a saber: responder a las acciones del usuario en forma de solicitudes HTTP entrantes y controlar el modelo para crear la vista (página HTML). En el caso de Backbone, estas responsabilidades se comparten entre View y Router . Pero falta la noción independiente de controlador o presentador.
, Backbone — MVP, View Presenter, Template — View, Model Collection Model.

, Backbone - . , Backbone MVC, MVP. , .

Así es como nace MV * o Model-View-Whatever ("lo que sea"). Para una discusión detallada, se recomienda que visite el blog de Addi Osmani.

En comparación con jQuery anterior, Backbone ayudó a crear un código más estructurado.









Anteriormente en este artículo, llamé a Backbone la próxima solución evolutiva. La razón es que él simplemente extendió el MVC del lado del servidor para complementarlo. Por ejemplo, si nuestro servidor es RESTful e implica que el código front-end es solo un medio para representar el modelo en el lado del servidor, entonces Backbone está preconfigurado para sincronizarse con la API:



Y además, hay muchas otras convenciones pequeñas integradas en Backbone que se sienten como una extensión. En conclusión, digo que Backbone podría no haber sido la única solución en ese momento, pero fue realmente un trabajo innovador en términos de estructura y organización del código. Al igual que jQuery, ha sido utilizado por muchos productos.

Knockout.js: enlace de datos para el front-end


Knockout.js es nuestro último ejemplo de uso de plantillas básicas. Su objetivo es implementar MVVM - Model-View-ViewModel para JavaScript. Y asi es. Si bien Backbone se ocupó del problema de la organización y la estructura del código, Knockout es una implementación eficiente del nivel de Vista utilizando enlaces de datos declarativos . Las ventajas de los enlaces declarativos son las mismas que con cualquier construcción de programación declarativa:

  1. Fácil de leer: el código declarativo ayuda a programar
  2. Acortando la plantilla estándar: los enlaces nos permiten actualizar automáticamente el DOM cada vez que cambia el ViewModel, y también actualizar el ViewModel cada vez que la Vista cambia a través de la entrada del usuario.
  3. Observable: Knockout proporciona un mayor nivel de abstracción para eventos. Esto permite que Knockout rastree automáticamente las dependencias entre las propiedades de ViewModel. Si es necesario, podemos suscribirnos a las propiedades Observables.





Si bien Knockout proporciona construcciones bien definidas para View y ViewModel, no dice nada sobre cuál debería ser el modelo de aplicación. Esto hace que Knockout sea extremadamente enfocado y versátil, ya que puede usarse como una biblioteca en lugar de un marco. Desde mi propia experiencia, vi que se usaba para crear miniaplicaciones de SPA, donde una aplicación web consta de varias páginas y cada página es una pequeña aplicación Knockout. Esta respuesta a StackOverflow define claramente el alcance de MVVM en Knockout.
A menudo se supone que con el modelo, Knockout está en el lado del servidor. ViewModel simplemente solicita un modelo del lado del servidor usando Ajax o su equivalente.

Knockout reemplaza jQuery y soluciones de plantillas como Handlebars para actualizaciones DOM, pero aún usa jQuery para animaciones, Ajax y otras utilidades. En combinación con Backbone, puede servir como una implementación completa de la plantilla MVVM. Teóricamente, esto podría suceder, pero antes de que esto pudiera suceder, estos conceptos ya se desarrollaron en las herramientas de la próxima generación.
Aquí comienza el movimiento revolucionario de Angular 1, Aurelia, Ember.js, etc.

Debido a su estrecha conexión con el mundo .NET, Knockout ha sido ampliamente utilizado en la aplicación ASP.NET MVC. Al igual que Backbone, fue otra solución evolutiva a un problema ligeramente diferente. Y nuevamente, la suposición de que el código del lado del cliente es simplemente una extensión del patrón MVC del lado del servidor no ha cambiado. El lado del servidor seguía siendo la arquitectura dominante.

Tanto Knockout como Backbone son bibliotecas de JavaScript. De una forma u otra, Backbone fue visto como un marco. ¿Por qué? No hay una respuesta definitiva, pero probablemente fue en perspectiva. La columna vertebral siempre se ha manejado con una abstracción de nivel superior debido a su énfasis en la estructura del código. Además, Backbone nunca tuvo la intención de reemplazar el omnipresente jQuery (incluso en 2019, el 70% de los principales 10,000,000 sitios web usan jQuery), mientras que Knockout se superpuso con el núcleo de jQuery, es decir, las manipulaciones DOM, que naturalmente complicaron Knockout. Por lo tanto, la adaptación de Knockout fue limitada en comparación con Backbone. Pero todavía era una de las primeras implementaciones de enlaces de datos declarativos para la comunidad front-end, y merece una mención especial.

Angular 1 - dame control


Lo que jQuery hizo con el DOM, Angular 1 lo hizo con el ecosistema front-end en su conjunto. Esto cambió para siempre la idea de crear aplicaciones cliente a gran escala. Presentó muchos conceptos como base: un sistema modular, inyección de dependencia, inversión de control, enlace de datos más fácil, etc.

Era y sigue siendo una tarea difícil elegir las bibliotecas JavaScript correctas y crear la pila de tecnología perfecta para la interfaz. Angular 1 simplemente proporcionó una alternativa más simple pero más coherente. Lo mismo puede decirse de Ember.js y otros sistemas similares, pero la aplicabilidad de Angular 1 estaba en un nivel cualitativo diferente al de sus alternativas de la época.
Angular 1 es una solución revolucionaria en el sentido de que claramente marcó un alejamiento de la idea de una simple extensión MVC del lado del servidor con código del lado del cliente disperso en las páginas. Angular 1 ha convertido a SPA en una solución de primera clase, casi de facto, para crear una experiencia de usuario de próxima generación.

Marco o biblioteca?


Las soluciones anteriores eran más bibliotecas que un marco. Angular 1 es sin duda una estructura bien definida. Un factor distintivo necesario entre la plataforma y la biblioteca es IOC - Inversión de control. Además, para calificar Angular 1 como marco, podemos observar:

  1. MVVM bien definidos: Angular 1 tiene objetos claros de Modelo, Vista y Modelo de vista.
  2. (DI): Angular 1 DI, Model. Angular 1 (Service). , .
  3. (data binding) : , . , MVVM. . (Angular 1 ). . . MVC. , .
  4. Sistema modular: Angular 1 introduce un sistema modular específico para el marco. Los módulos son la base para organizar el código para casi todos los idiomas. JavaScript no tenía un sistema modular hasta 2015 (los navegadores no lo admitían hasta 2018). Angular está muy adelantado a su tiempo en términos de organización.

Al mismo tiempo, Angular 1 también fue criticado por la complejidad que introdujo. La crítica más importante es que fue modelada en diseños del lado del servidor. Esto no es típico de los desarrolladores frontend. Algunas cosas fueron francamente malas:

  1. Colisión de espacio de nombres: aunque DI fue excelente, se implementó utilizando el patrón Localizador de servicios que utilizaba el espacio de nombres global. Esto hizo que el prefijo de servicios fuera casi obligatorio.
  2. . , , , . React . -, .
  3. . , Angular 1, . , Angular 1 $scope, ViewModel, Controller, $scope. , VMFactory . , Angular 1 , .

Hubo muchos otros problemas menores. Angular 2, o simplemente Angular, fue un avance completo en la medida en que parecía un marco completamente nuevo. No encuentro nada en común entre ellos, excepto el nombre y algunos conceptos.



A lo largo de los años, se han publicado pequeñas versiones de Angular 1, en las que se han solucionado muchas de las pequeñas complejidades de su uso. El más significativo de estos fue la incorporación del Modelo de Componentes , en el que convergieron la mayoría de las tendencias de desarrollo front-end.

Angular 1 vivió mucho tiempo y continúa viviendo entre la comunidad front-end. Con todos sus pros y contras, ayudó a la comunidad a comprender la importancia de la arquitectura de software y proporcionó la base para escribir aplicaciones escalables. Sus desventajas y deficiencias se convirtieron en la base para resolver problemas para futuras arquitecturas.

More articles:


All Articles