¿Soy el único que piensa que la carga diferida de módulos / código de AngularJS es increíblemente estúpida?

Debe haber algún punto intermedio entre cargar todo ansiosamente y cargar todo perezosamente. Depende en gran medida del contexto de su aplicación.

En mi proyecto de juego personal, quiero que la pantalla de introducción se muestre lo más rápido posible, hasta el punto de incluir los activos y las dependencias necesarias en el archivo HTML. Una vez hecho esto, el resto del código del juego se descargará en segundo plano mientras se muestra la pantalla del título.

Si algo necesita mostrarse rápidamente, asegúrese de que se cargue lo más rápido posible aplazando la carga de pesos innecesarios. Luego pronostique lo que los usuarios harán a continuación y precargúelos. Eso es carga inteligente.

Si está escribiendo un sitio web que será compatible con el teléfono y las tabletas, lo que debería ser dado que el 60% del tráfico web ahora es móvil, entonces querrá una carga lenta. Las conexiones móviles rara vez son 4G, más cercanas a 3G, que a menudo equivale a un marcado de 15 KB / seg.

Twitter optimizado para la carga diferida, y vio un aumento dramático en la participación del usuario. Su sitio debería renderizarse, no necesariamente completamente cargado, en menos de 3 segundos.

Tiempo para el primer tuit

En mi humilde opinión, el beneficio de hacerlo no es necesariamente la carga perezosa per se, sino la innecesaria compilación futura para la ejecución local. Por ejemplo, si está utilizando browserify en su proyecto, encontrará que en proyectos más grandes tendrá que esperar un poco después de la compilación para ver los cambios.

En lugar de ello, si carga módulos de forma AMD, puede actualizar su navegador y ver los cambios inmediatamente sin esperar a que finalice la compilación (localmente).

Otro beneficio de usar AMD es la capacidad del código de carga que puede no ser necesario justo cuando el usuario lo necesita. Esto puede ser más obvio en aplicaciones más grandes cuando tiene módulos compartibles para interacciones especiales donde puede involucrar no solo JS específicos sino también CSS y HTML.

La optimización debe hacerse cuando tenga un problema de rendimiento. No antes. Este es un error común de los ingenieros de software junior (y a veces incluso senior). La carga diferida de algunos recursos específicos para hacer que su aplicación sea más rápida en algunos lugares (como la carga inicial) podría funcionar bien, pero la carga diferida puede resultar en un peor rendimiento.

Este tipo de optimización no solo es prematuro, sino también muy probablemente destructivo. JavaScript es extremadamente pequeño en comparación con los activos estáticos como las imágenes, por lo que cargarlos de forma diferida va a ser perjudicial para el rendimiento general de su aplicación debido a la sobrecarga de la solicitud.

Cree una gran aplicación de SPA y se dará cuenta de quién es el estúpido.

Tomemos un ejemplo de una aplicación con 4 características, cada una de las cuales requiere una gran cantidad de plantillas js y html. Si bien la mayoría de los usuarios necesitan solo 1 funciones, su navegador necesita cargar js no utilizadas de las 4 funciones

Puede tener sentido en aplicaciones grandes si el paquete JS se hace grande. De forma predeterminada, Angular lo obliga a cargar todo el JavaScript cuando la aplicación se inicia. En una aplicación grande, esto podría significar varios MB, por lo que puede haber beneficios de un enfoque más lento.

Para admitir la verdadera carga diferida en Angular, tenemos que agregar una biblioteca de terceros como oclazyload. Aquí hay un ejemplo: Angular con RequireJS AMD y ocLazyLoad

Creo que depende de la intención de la carga lenta / inicialización. Si es solo para ahorrar recursos / ancho de banda, podría no merecerlo. Si sirve para cargar dinámicamente módulos / funcionalidades que crean una interfaz de usuario / función dinámica, hay algunos escenarios para ello.