¿Por qué el desarrollo frontend / JavaScript se ha vuelto tan complejo?

Se ha vuelto complejo porque ahora tenemos que manejar el estado persistente del lado del cliente.

El desarrollo web ha pasado de los sitios web prestados por el servidor y de recarga de páginas a las aplicaciones modernas de una sola página.

Tradicionalmente, el servidor es responsable de generar el 100% del contenido que aparece inmediatamente en la página.

Cuando hacemos una acción como hacer clic en un enlace o enviar un formulario, se volverá a cargar la página, lo que significa otro viaje de ida y vuelta al servidor.

Cada recarga de página borra el javascript de la memoria. Si escribimos código terrible, como el que:
– Crea pérdidas de memoria al no desasignar memoria
– Crea variables globales únicas
– Asume que el código se ejecutará una vez por página
– Asume que solo existirá una instancia de un componente en un momento dado

Entonces podemos salir con la suya, porque la página se volverá a cargar lo suficientemente pronto.

HTML, CSS, jQuery y Grunt son suficientes para manejar sitios como estos.

Pero con una sola aplicación de página, la página nunca se recarga. Ahora tenemos que manejar el enrutamiento del lado del cliente. Ahora tenemos que preocuparnos por el estado del lado del cliente. Ahora, todo el código que se ejecutó una vez por página se puede ejecutar varias veces invocando esa ruta varias veces. Ahora, esas malas prácticas de codificación anteriores causarán errores devastadores.

Ahora tenemos más ventanas emergentes, ventanas modales, flujos de varios pasos. Los gerentes y diseñadores de productos tienen formas muy indirectas de decir las cosas en el sentido de:
– “poner todo en una ventana modal”
– “Cambiar la interfaz de usuario al azar, probando constantemente formas nuevas, diferentes y cada vez más inconsistentes … porque las pruebas AB …”
– “¿Por qué no funciona el botón Atrás? ¿Por qué no podemos guardar los datos del usuario tan pronto como lo ingresan?

Y tenemos ventanas emergentes más dinámicas. Y a veces esas ventanas emergentes contenían contenido que tiene información sobre herramientas. Y a veces esas informaciones sobre herramientas tienen información sobre herramientas. Y esa información sobre herramientas abre una barra lateral que tiene un enlace que abre la misma instancia de la ventana emergente que ya está abierta.

Por lo tanto, la necesidad de componentes reutilizables es clave … para que podamos poner esos componentes en ventanas emergentes. La necesidad de sistemas que puedan manejar aplicaciones de una sola página es esencial … para que podamos manejar el enrutamiento y la representación del lado del cliente.

jQuery y Grunt no pueden manejar esto bien.

¡Buenas noticias! Los marcos de javascript modernos y los sistemas de compilación están aquí para rescatarnos, para ayudarnos a construir aplicaciones de una sola página (SPA). Malas noticias: muchos desarrolladores de JavaScript se vuelven dependientes de dichos marcos para construir SPA, y no pueden crear uno desde cero.

La otra mala noticia es que los marcos JS a menudo se rompen y mienten sobre cuán modulares y poco obstinados son (“Reaccionar es solo la capa de vista …”). Algunos sufren problemas de rendimiento insoportables que solo se pueden solucionar al piratear los detalles de su implementación.

Ahora agregue el DOM virtual, la curva de aprendizaje del paquete web, las características experimentales de ES6, y se hace cada vez más difícil comprender con precisión cómo funciona una interfaz moderna en un nivel bajo.

En realidad, no debería ser tan complejo como es. Hay algunas razones principales y algunas de ellas están bien fundadas:

1. La capacidad de computación se ha desplazado al lado del cliente porque una computación distribuida es más efectiva. Sin embargo, esto es solo un “cambio”, el backend será menos complejo. (OK, junto con este cambio, la complejidad general se ha incrementado un poco).
2. El valor de “marketing” de un sitio también se ha incrementado. La mayoría de los propietarios de sitios web / aplicaciones web no están satisfechos con una interfaz de usuario minimalista, simple (y bien utilizable ). Esperan más movimiento, más “factor cool”, etc. (junto con una menor usabilidad). En mi opinión, esta no es una buena dirección, pero aún así. El propietario del sitio web paga.
3. Los desarrolladores no están satisfechos con las tecnologías estables y probadas. Les gustaría usar tecnologías “de punta”, sin importar cuán inmaduras sean. Y, dado que son inmaduros, todavía no están limpios. Son más complicados de lo que son después de eliminar componentes innecesarios y pasos de desarrollo.

Los usuarios de la aplicación web no detectan 3, pero en realidad tampoco detectan 2 ,. Estos esfuerzos generalmente no valen la pena. ( 1, es importante para el manejo adecuado de los recursos).

El desarrollo web se ha transformado de sitios web simples que tienen contenido estático a aplicaciones web complejas que tienen contenido dinámico.

Para proporcionar datos dinámicos en HTML con facilidad, estos marcos son útiles. Extiende la funcionalidad de html y mejora la legibilidad del código. Estaría escribiendo código menor y de calidad. Si el proyecto es grande, las estructuras del proyecto compatibles con los marcos son útiles para crear código:

1 legible

2 escalables

3 reutilizables

4 estructurado

La demanda de experiencia del usuario ha aumentado día a día con la aparición de HTML 5. Los sitios web no son solo sitios web hoy en día. Son una aplicación dinámica altamente interactiva. Solo mira Facebook. No necesita actualizar la página ni hacer nada para ver las actualizaciones que se aproximan. Simplemente aparecen en su fuente de noticias, notificación o mensajería cada vez que llegan actualizaciones.