¿Todavía necesitamos marcos de JavaScript?

Como desarrollador web, trato de evaluar mi caja de herramientas con regularidad y determinar si puedo prescindir de esta o aquella herramienta. Recientemente, he estado investigando lo fácil que es desarrollar una aplicación de interfaz de usuario compleja sin un marco de interfaz de usuario.

¿Qué es un marco de JavaScript?

En pocas palabras, un marco de JavaScript es una herramienta que puede aprovechar para desarrollar aplicaciones web avanzadas, especialmente SPA.

En el pasado, los desarrolladores web implementaban la lógica del front-end confiando en gran medida en Vanilla JS y jQuery. Pero, a medida que las aplicaciones de front-end se volvieron cada vez más complejas, las herramientas aumentaron para satisfacer esa complejidad.

Los marcos que son populares hoy en día tienen algunos puntos en común básicos. La mayoría de los frameworks / bibliotecas de front-end, desde Vue hasta React, proporcionan alguna combinación de lo siguiente:

  • Sincronización de estado y vista
  • Enrutamiento
  • Un sistema de plantillas
  • Componentes reutilizables

¿Siguen siendo necesarios los marcos?

Depende de cómo acentúes la palabra necesaria. Muchos dirían que los marcos frontales no son y nunca han sido necesarios. Sin embargo, son herramientas muy útiles.

Entonces la pregunta es: ¿son los frameworks jQuery de hoy? ¿Los problemas que resuelven se abordarán mediante cambios como los de la API DOM?

Es difícil de decir, pero los avances en JS nativo, la especificación del componente web y las herramientas de compilación fácilmente configurables, han hecho que desarrollar un SPA sin un marco sea tan fácil como siempre.

Para examinar esto más a fondo, desarrollé una aplicación de una sola página usando solo JavaScript vanilla, componentes web nativos y Parcel. Hubo un puñado de trampas y dificultades en el camino que destacaron las fortalezas de los marcos JS.

Al mismo tiempo, una vez que pasé los obstáculos iniciales, me sorprendió lo simple que era crear una aplicación de una sola página con solo Vanilla JS.

Visión general

La aplicación es sencilla. Es una aplicación de recetas con capacidades CRUD básicas. El usuario puede crear, editar, eliminar, marcar como favorito y filtrar una lista de recetas.

Componentes

La creación de un componente web también es sencilla. Creas una clase que se extiende HTMLElement(o HTMLParagraphElementasí sucesivamente) y luego usas esa clase para definir un elemento personalizado.

También puede hacer uso de enlaces de ciclo de vida como connectedCallback, connectedCallback, attributeChangedCallback.

Enrutamiento

El enrutamiento para la aplicación de recetas también es bastante simple. Dado un evento de navegación, configuro el contenido de la aplicación en el componente web correspondiente.

Inicialmente, estaba usando un paquete npm llamado Vanilla JS Router. Con la API del historial del navegador, ¡no es tan complejo implementar el suyo en menos de 100 líneas de código! Nota: No estoy implementando una lógica realmente compleja como los guardias de ruta.

Ese es un resumen rápido. Quiero mantener este artículo en una extensión razonable. Puedo escribir una publicación de seguimiento con una explicación más detallada de la aplicación. ¡Implementé algunas funciones divertidas como el desplazamiento infinito, un cargador personalizado de arrastrar y soltar, y más!

Retrospectivo

Después de crear la aplicación, me tomé un tiempo para pensar en los pros y los contras de todo el proceso de principio a fin. Empezaré por las malas noticias.

Contras

La especificación todavía está cambiando

La especificación del componente web es antigua y nueva. Ha existido por mucho más tiempo de lo que había pensado originalmente. Los componentes web fueron presentados por Alex Russell en la Fronteers Conference 2011 por primera vez. Sin embargo, el impulso detrás de los componentes web realmente ha crecido en los últimos dos años. Como tal, todavía hay mucha confusión en la especificación. Por ejemplo, las importaciones de HTML se han abandonado, aunque la mayoría de la documentación / recursos todavía hacen referencia a ellas.

Pruebas

No existen muchos recursos dedicados para probar componentes web nativos. Hay algunas herramientas prometedoras como skatejs ssr y el probador de componentes web de Polymer. Pero estas herramientas están realmente diseñadas para su uso con sus respectivas bibliotecas. Esto presenta algunas dificultades para su uso con componentes web nativos.

Detección de cambios

Tener un sistema subyacente que mantenga automáticamente la vista sincronizada con el modelo de datos es increíble. Es lo que atrajo a muchos a Angular y otros frameworks en primer lugar.

Mantener el estado sincronizado con la vista no es tan difícil a pequeña escala. Pero puede salirse de control muy rápidamente y se encontrará agregando toneladas de detectores de eventos y selectores de consultas.

El DOM de la Sombra

Estoy realmente desgarrado por la sombra DOM. Por un lado, me encanta la idea de encapsulación. Es un patrón de diseño sensato, hace que su estilo en cascada sea más manejable, simplifica sus preocupaciones, etc. Sin embargo, también presenta problemas cuando desea que ciertas cosas penetren en esa encapsulación (como una hoja de estilo compartida), y hay debates en curso sobre la mejor manera de hacerlo.

Generando estructuras DOM

Parte de la magnificencia de los frameworks / bibliotecas como Angular y React es que son maestros de su DOMain. Es decir, son excelentes para renderizar y volver a renderizar estructuras en el DOM de manera eficiente. Del blog de Angular University:

Angular no genera HTML y luego lo pasa al navegador para analizarlo, sino que Angular genera estructuras de datos DOM directamente.

Angular, por ejemplo, a diferencia de jQuery, procesa las estructuras de datos DOM directamente. Es decir, en lugar de pasar HTML al navegador para analizarlo y luego representarlo en estructuras de datos DOM. Esto es más eficaz ya que elimina ese paso de análisis. El DOM virtual también es bastante útil, ya que evita que vuelva a renderizar todo cada vez que necesite actualizar su vista.

Pros

Por otro lado, existen algunos beneficios innegables al desarrollar aplicaciones de esta manera:

Tamaño del paquete

El producto final puede ser (énfasis en lata ) mucho más pequeño y compacto que cualquier producto desarrollado con un marco moderno. Por ejemplo, la compilación final de mi aplicación de recetas con todas las funciones tenía menos de la mitad del tamaño de una compilación Angular nueva.

Nota: Estos son los tamaños de paquete optimizados y actualizados.

Comprensión

Si solo ha desarrollado realmente con un marco y su CLI, puede ser un gran ejercicio hacer una aplicación web sin herramientas adicionales. Como alguien que quiere lograr un cierto nivel de dominio (en la medida de lo posible) del desarrollo web, ha sido esencial para mí obtener más experiencia práctica con herramientas de construcción, API de navegador, patrones de diseño, etc.

Actuación

Lo que estas bibliotecas y frameworks de front-end están haciendo detrás de escena es asombroso. Sin embargo, puede pagar un precio de rendimiento si decide utilizar alguno de ellos; no existe tal cosa como un almuerzo gratis. Hay muchos obstáculos potenciales en el rendimiento a escala: ya sean re-renderizaciones desperdiciadas, oyentes redundantes, comparación profunda de objetos o manipulaciones DOM grandes e innecesarias. Puede eliminar mucha complejidad aquí implementando cosas desde cero.

Los equipos de Angular y React parecen estar al tanto de estos errores y han proporcionado cosas como shouldUpdate anulaciones del método y onPush ChangeDetection como un medio para optimizar aún más el rendimiento.

Sencillez y propiedad del código

Te arriesgas cada vez que traes código de terceros. Este riesgo se reduce con bibliotecas / marcos probados y comprobados, pero nunca se elimina realmente. Si puede salirse con la suya escribiendo código usted mismo o con su equipo, puede reducir ese riesgo y mantener una base de código que conozca por completo.

Notas y curiosidades interesantes

Me lo pasé genial trabajando con Parcel. A veces se sentía un poco más limitado que Webpack cuando trataba de solucionar ciertos casos extremos, pero encontré que la línea de etiqueta 'configuración cero' era cierta, en su mayor parte.

También me queda claro que muchos etiquetan React como una 'biblioteca' y Vue como un marco 'progresivo'. Si bien entiendo las razones de esto, creo que React, Vue y Angular resuelven muchos de los mismos problemas. Por lo tanto, los estoy considerando todos juntos bajo el término 'marcos'.

¿Por qué no utilizar Stencil o Polymer? Quería evitar el uso de paquetes, bibliotecas y marcos tanto como fuera posible. Quería ver hasta dónde habían llegado los estándares web para cumplir con el desarrollo moderno (además de las herramientas de construcción).

Estoy seguro de que hay muchas otras formas de desarrollar una aplicación de interfaz de usuario o SPA en general sin un marco o biblioteca importante, probé una forma aquí, ¡y me encantaría conocer otras!

Resumen

Una gran heurística para la decisión de usar o no un marco es lo que yo llamo, "el punto de inflexión". Llega un momento a medida que su aplicación crece, en el que termina creando su propio marco para reutilizar la funcionalidad y la estructura. Por ejemplo, tiene un montón de formularios y desea crear una lógica reutilizable para la validación reactiva.

Si termina en este punto, debe decidir si vale la pena invertir el tiempo en crear sistemas para lograr lo que puede lograr rápidamente con un marco o biblioteca. Habrá diferentes puntos de inflexión dependiendo de cuáles sean sus limitaciones de tiempo o limitaciones presupuestarias, pero los marcos siguen siendo muy relevantes dados los escenarios correctos.

Dicho esto, mucho de lo que hacen los frameworks probablemente será más fácil de hacer con bibliotecas más pequeñas y / o código nativo a medida que pase el tiempo. Tome mi aplicación como ejemplo. Al mismo tiempo, si los grandes marcos y bibliotecas siguen siendo versátiles, pueden transformarse, adaptarse y quedarse. De lo contrario, pueden terminar como jQuery, una herramienta del pasado en su mayor parte.

Conclusión

En conclusión, existen formas prometedoras de desarrollar aplicaciones frontales complejas sin marcos. Sin embargo, la especificación para cosas como los componentes web aún está evolucionando y hay problemas por resolver. Los marcos todavía hacen muchas cosas increíbles y pueden hacer que el desarrollo sea mucho más fluido.

En este momento, por lo que puedo decir, las ventajas de usar un marco a menudo superan las desventajas. Sin embargo, si los marcos no comienzan a resolver nuevos problemas y continúan evolucionando, eventualmente se desvanecerán.

Recursos

Guía de Angular para principiantes: ¿Por qué Angular? Los principales beneficios

Nota: Esta publicación es parte de la serie Angular para principiantes en curso, aquí está la serie completa: Angular para principiantes ... blog.angular-university.io Comparación con otros marcos - Vue.js

Vue.js - El marco de JavaScript progresivo vuejs.org Optimización del rendimiento - Reaccionar

Internamente, React utiliza varias técnicas inteligentes para minimizar el número de costosas operaciones DOM necesarias para actualizar los… reactjs.org Web Components

Como desarrolladores, todos sabemos que reutilizar el código tanto como sea posible es una buena idea. Esto tradicionalmente no ha sido tan… developer.mozilla.org La razón más profunda por la que existen los frameworks JavaScript modernos

He visto a mucha, mucha gente usando un framework moderno como React, Angular o Vue.js a ciegas. Estos marcos proporcionan ... medium.com Diseño de componentes web utilizando una hoja de estilo compartida

Los componentes web son una nueva característica sorprendente de la web, que permite a los desarrolladores definir sus propios elementos HTML personalizados ... www.smashingmagazine.com