mostrar - ejecutar javascript despues de cargar pagina

Usando DOMContentReady considerado anti-patrón por Google (7)

Creo que este consejo no es realmente útil. DOMContentReady solo puede ser una mala práctica porque actualmente está sobreutilizada (tal vez debido al evento preparado de jquery fácil de usar). Muchas personas lo utilizan como el evento de "inicio" para cualquier acción de javascript. Aunque incluso el evento ready () de jQuery estaba destinado a ser utilizado como punto de inicio para las manipulaciones de DOM.

Inferencial, las manipulaciones DOM en la carga de la página llevan a una mala experiencia de usuario Debido a que no son necesarios , el lado del servidor podría haber generado completamente la página inicial.

Entonces, ¿tal vez los miembros del equipo de cierre simplemente intentan orientarse en la dirección opuesta y evitan que las personas realicen manipulaciones de DOM en la carga de la página?

Un miembro del equipo de la biblioteca de Google Closure asserts que esperar por el evento DOMContentReady es una mala práctica.

El cuento es que no queremos esperar a DOMContentReady (o, peor aún, al evento de carga) ya que conduce a una mala experiencia del usuario. La IU no responde hasta que todo el DOM se ha cargado desde la red. Así que la forma preferida es usar scripts en línea tan pronto como sea posible.

Dado que aún no proporcionan más detalles sobre esto, me pregunto cómo manejarán el diálogo de la Operación Abortada en IE. Este diálogo es la única razón crítica que conozco para esperar el evento DOMContentReady (o carga).

¿Conoces alguna otra razón?
¿Cómo crees que tratan con ese problema de IE?

El mayor problema con los scripts en línea es que no se puede almacenar en caché correctamente. Si tiene todos sus scripts guardados en un archivo js que está minimizado (usando un compilador), entonces el archivo puede ser almacenado en caché solo una vez, para todo el sitio, por el navegador.

Eso lleva a un mejor rendimiento a largo plazo si su sitio tiende a estar ocupado. Otra ventaja de tener un archivo separado para tus scripts es que tiendes a no "repetirte" y declarar las funciones reutilizables tanto como sea posible. DOMContentReady no conduce a una mala experiencia de usuario. Además, proporciona al usuario el contenido de antemano, en lugar de hacer que el usuario espere a que se cargue la interfaz de usuario, lo que podría convertirse en un gran desvío para el usuario.

Además, el uso de scripts en línea no garantiza que la interfaz de usuario sea más receptiva que cuando se usa con DOMContentReady. Imagine un escenario en el que está utilizando scripts en línea para realizar llamadas ajax. Si tiene un formulario para presentar su multa. Tiene más de una forma y termina repitiendo sus llamadas ajax ... por lo tanto, repite el mismo script cada vez. Al final, lleva al navegador a almacenar más código javascript del que tendría si se separara en un archivo js cargado cuando el DOM está listo.

Otra gran desventaja de tener scripts en línea es que necesita mantener dos bases de código separadas: una para el desarrollo y otra para la producción. Debe asegurarse de que ambas bases de código se mantengan sincronizadas. La versión de desarrollo contiene la versión no minimizada de su código y la versión de producción contiene la versión minificada. Este es un gran dolor de cabeza en el ciclo de desarrollo. ¡Tienes que reemplazar manualmente todos los fragmentos de código ocultos en esos archivos html voluminosos con la versión minificada y también al final espero que no se rompa ningún código! Sin embargo, al mantener un archivo separado durante el ciclo de desarrollo, solo necesita reemplazar ese archivo con la versión compilada minificada en el código base de producción.

Si usas YSlow ves que:

El uso de archivos JavaScript y CSS externos generalmente produce páginas más rápidas porque los archivos están almacenados en caché por el navegador. JavaScript y CSS que están incluidos en los documentos HTML se descargan cada vez que se solicita el documento HTML. Esto reduce el número de solicitudes HTTP pero aumenta el tamaño del documento HTML. Por otro lado, si el JavaScript y CSS están en archivos externos almacenados en caché por el navegador, el tamaño del documento HTML se reduce sin aumentar el número de solicitudes HTTP.

Puedo responder por secuencias de comandos en línea solo si el código cambia tan a menudo que tenerlo en un archivo js independiente es irrelevante y al final tendría el mismo impacto que el de estas secuencias de comandos en línea. Sin embargo, estos scripts no son almacenados en caché por el navegador. La única forma en que el navegador puede almacenar scripts en caché es si se almacena en un archivo js externo con un etag .

Sin embargo, esto no es el cierre de JQuery vs Google de ninguna manera. El cierre tiene sus propias ventajas. Sin embargo, el cierre de la biblioteca hace que sea difícil tener todos los scripts en archivos externos (aunque no es imposible, solo lo hace difícil). Sólo tiendes a usar scripts en línea.

Probablemente sea porque a Google no le importa si no tiene Javascript, lo requieren para todo lo que hacen. Si utiliza Javascript como una adición en la parte superior de su sitio web que ya funciona, entonces cargar scripts en DOMContentReady está bien. El punto es usar Javascript para mejorar la experiencia del usuario, no aislarlo si no lo tiene.

Si el tiempo que se tarda en analizar, cargar y renderizar el diseño (el punto en el que domready debería dispararse) sin tener en cuenta las cargas de imagen lleva tanto tiempo que causa un notable retraso en la interfaz de usuario, es probable que tenga algo realmente feo al construir esa página en Back-end, y ese es tu verdadero problema.

Además, JavaScript antes del final de la página detiene el análisis de HTML / DOM evaluando hasta que se analiza y evalúa el JS. Google debe mirar a su Java antes de dar consejos sobre JavaScript.

Si necesita deshacerse de su HTML por su cuenta, el enfoque de Google parece muy incómodo. Utilizan el enfoque compilado y pueden desperdiciar sus ciclos cerebrales en otros temas, lo cual es sensato dada la compleja interfaz de usuario de sus aplicaciones. Si se dirige a algo con requisitos más relajados (lea: casi todo lo demás), tal vez no valga la pena el esfuerzo.

Sin embargo, es una pena que GWT solo esté hablando de Java.

Una pequeña explicación primero: el punto con JavaScript en línea es incluirlo lo antes posible. Sin embargo, ese "posible" depende de los nodos DOM que el script requiere que se declare. Por ejemplo, si tiene algún menú de navegación que requiere JavaScript, incluiría el script inmediatamente después de que el menú esté definido en el HTML.

<ul id="some-nav-menu"> <li>...</li> <li>...</li> <li>...</li> </ul> <script type="text/javascript"> // Initialize menu behaviors and events magicMenuOfWonder( document.getElementById("some-nav-menu") ); </script>

Siempre y cuando solo dirijas los nodos DOM que sabes que han sido declarados, no tendrás problemas de indisponibilidad con DOM. En cuanto al problema de IE, el desarrollador debe incluir estratégicamente su script para que esto no suceda. No es realmente una gran preocupación, ni es difícil de abordar. El problema real con esto es el "panorama general", como se describe a continuación.

Por supuesto, todo tiene sus pros y sus contras.

Pros

Tan pronto como un elemento DOM se muestra al usuario, cualquier funcionalidad que se agregue mediante JavaScript también estará disponible casi de inmediato (en lugar de esperar a que se cargue toda la página).
En algunos casos, Pro # 1 puede dar como resultado tiempos de carga de página más rápidos y una experiencia de usuario mejorada.

Contras

En el peor de los casos, está mezclando la presentación y la lógica empresarial; en el mejor de los casos, está mezclando las script incluidas en toda la presentación, ya que ambas pueden ser difíciles de administrar. Tampoco son aceptables en mi opinión, así como por una gran parte de la comunidad.
Como señaló la eyelidlessness , si las secuencias de comandos en cuestión tienen dependencias externas (por ejemplo, una biblioteca), esas dependencias deben cargarse primero, lo que bloqueará la representación de la página mientras se analizan y ejecutan.

¿Utilizo esta técnica? No. Prefiero cargar todas las secuencias de comandos al final de la página, justo antes de la etiqueta de cierre </body> . En casi todos los casos, esto es lo suficientemente rápido para el rendimiento de inicialización percibido y real de los controladores de eventos y efectos.

¿Está bien que otras personas lo usen? Los desarrolladores van a hacer lo que quieren / necesitan para hacer el trabajo y hacer felices a sus clientes / jefes / departamento de marketing. Hay compensaciones, y siempre que las entienda y las administre, debería estar bien de cualquier manera.

Una razón para evitar los scripts en línea es que requiere que coloque las bibliotecas de dependencias en el documento, lo que probablemente anulará las ganancias de rendimiento de los scripts en línea. La mejor práctica con la que estoy familiarizado es colocar todos los scripts (en una sola solicitud HTTP) al final del documento, justo antes de </body> . Esto se debe a que la carga de secuencias de comandos bloquea la solicitud actual y todas las solicitudes secundarias hasta que la secuencia de comandos se carga, analiza y ejecuta por completo.

Aparte de una varita mágica, siempre tendremos que hacer estas concesiones. Afortunadamente, el documento HTML en sí mismo se convertirá cada vez más en la solicitud con menos recursos (a menos que esté haciendo cosas tontas como grandes data: URL y enormes documentos SVG en línea). Para mí, el compromiso de esperar el final del documento HTML parece ser la opción más obvia.