¿Por qué debo evitar las secuencias de comandos en línea?

  

¿Cuáles son los problemas reales con las secuencias de comandos en línea? ¿Existe un problema de rendimiento importante, o se trata principalmente de un buen estilo?

Las ventajas no se basan en el rendimiento, son (como Michael señaló en su comentario) más que ver con la separación de la vista y el controlador. El archivo HTML / CSS debería, idealmente, contener solo la presentación y se deberían usar archivos separados para los scripts. Eso hace que sea más fácil para usted (y sus compañeros) leer y mantener los aspectos tanto visuales como funcionales.

  

¿Puedo justificar una acción inmediata en el frente de scripts en línea a mis superiores, cuando hay otras cosas en las que trabajar que podrían tener un impacto más evidente en el sitio?

No, probablemente no. Puede ser muy difícil convencer a los poderes de ser un trabajo de mantenimiento puro, incluso si usted cree que les ahorrará dinero a largo plazo. Sin embargo, en este caso, no creo que sea tan importante que deba detener todo y deshacerse de sus secuencias de comandos en línea. En su lugar, solo asegúrese de hacer un esfuerzo consciente para rectificar las áreas a medida que trabaja en ellas por otras razones. El código de refactorización debería ser algo que haces regularmente pero solo un poco a la vez.

  

Si se detuvo en un sitio web y echó un vistazo al código fuente, ¿qué factores lo llevarían a decir "hmm, trabajo profesional aquí" y qué le haría retroceder ante un trabajo obviamente amateur?

El factor número uno que me diría que no es profesional es el uso excesivo de tablas o divs. Aquí hay un artículo que explica por qué ninguno de los dos debe ser usado en exceso.

No voy a ser el defensor del diablo, pero no hay una relación estricta entre el trabajo amateur y el JavaScript en línea. Veamos el código fuente de varios sitios web más conocidos:

• Google,
• Wikipedia,
• Microsoft,
• Adobe,
• Dell,
• IBM.

Cada una de sus páginas de inicio usa JavaScript en línea. ¿Significa que todas esas empresas contratan personas amateur para crear sus páginas de inicio?

Soy uno de esos desarrolladores que no pueden poner código JavaScript dentro de HTML. Nunca lo hago dentro de los proyectos en los que trabajo (excepto, probablemente, algunas llamadas como <a href="javascript:..."> para los proyectos en los que el JavaScript discreto no era un requisito desde el principio, y siempre elimino el JavaScript en línea cuando refactorizo el código de otra persona. Pero lo hace Vale la pena el esfuerzo? No estoy tan seguro.

En lo que respecta al rendimiento, no siempre tiene mejores actuaciones al colocar JavaScript en un archivo separado. Por lo general, nos sentimos tentados a considerar el ancho de banda de desperdicio de JavaScript en línea, ya que no se puede almacenar en caché (excepto cuando se trata de código HTML almacenable estático). Por el contrario, un archivo .js externo se carga solo una vez.

En realidad, esto es solo otra optimización prematura : puedes tener razón al pensar que la externalización de JavaScript podría mejorar tu sitio web, pero también puedes estar totalmente equivocado:

• ¿Qué pasa si la mayoría de los usuarios vienen con un caché vacío?
• ¿Consideró que con un archivo .js externo, se realizará una solicitud a este archivo en cada solicitud de página, si el sitio web no está configurado correctamente (y generalmente no lo está),
• ¿El archivo .js realmente está en caché (con IIS, puede que no sea tan fácil)?

Entonces, antes de optimizar de manera prematura, recopile estadísticas sobre sus visitantes y evalúe las actuaciones con y sin JavaScript en línea.

Luego viene el argumento final: mezcló JavaScript y HTML en su fuente, así que apesta. Pero ¿quién dijo que mezclaste ambos? El código fuente utilizado por el navegador no siempre es el código fuente que escribió. Por ejemplo, el código fuente puede estar comprimido, minimizado, o varios archivos CSS o JS pueden unirse en un solo archivo, pero esto no significa que realmente nombraste las variables a , b , c ... a1 , etc. o que escribiste un enorme archivo CSS sin espacios ni nuevas líneas. De la misma manera, puede hacer que el código fuente externo de JavaScript se inyecte fácilmente en HTML en el momento de la compilación o posteriormente a través de las plantillas.

Para concluir, si combina JavaScript y HTML en el código fuente que escribe, debería considerar no hacerlo en sus proyectos futuros. Pero no significa que si el código fuente enviado al navegador contiene JavaScript en línea, siempre es malo.

• Puede ser malo.
• Por el contrario, puede ser una señal de que el sitio web fue escrito por profesionales que se preocuparon por el rendimiento, realizaron pruebas específicas y determinaron que sería más rápido para sus clientes acceder a las partes en línea de JavaScript.
• O puede que no signifique nada en absoluto.

así que es una vergüenza para la persona que dice "sitio muy bueno, vergüenza acerca de las secuencias de comandos en línea en el código fuente" mirando solo la fuente enviada al navegador, sin saber nada sobre cómo se realizó el sitio web.

En general, es bueno tratar de mantener HTML y JS generalmente separados. HTML es para la vista, JS es para la lógica de la aplicación. Pero en mi experiencia, el desacoplamiento extremo de html y javascript (en aras de la pureza) no lo hace más fácil de mantener; En realidad, puede ser menos mantenible.

Por ejemplo, a veces uso este patrón (tomado de ASP.net) para configurar los controladores de eventos:

<input type="button" id="yourId" onclick="clickYourId()" />

o

<input type="button" id="yourId" onclick="clickYourId(this)" />

No hay ningún misterio en lo que hace que ocurra un evento. El motivo es que seis meses después, puede inspeccionar el elemento (por ejemplo, en Chrome) y ver inmediatamente qué evento javascript se activa.

Por otro lado, imagina que estás leyendo el código de otra persona, que es cien mil líneas, y te encuentras con un elemento mágico que dispara un evento javascript:

<input id="yourId"  />

¿Cómo puedes decirme fácilmente a qué método de javascript está llamando? Chrome ha hecho esto más fácil, pero quizás el evento esté vinculado a la identificación, o quizás esté vinculado al primer elemento secundario del contenedor. Tal vez el evento está adjunto al objeto padre. ¿Quién sabe? Buena suerte encontrándolo. :)

También, diría que ocultar el javascript completamente al diseñador puede aumentar la probabilidad de que lo rompan en una actualización. Si alguien edita el código para un elemento mágicamente activo, ¿qué indicación tiene en el código que les permita saber que este es un elemento activo en la página?

En resumen, la mejor práctica es separar HTML y Javascript. Pero también entender que las reglas generales a veces son contraproducentes cuando se llevan al extremo. Yo abogaría por un enfoque intermedio. Evite grandes cantidades de js en línea. Si utiliza inline, la firma de la función debería ser muy simple como:

1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)

He aquí algunas razones.

1. El script en línea no se puede minimizar (se puede convertir a una versión más corta mediante la reducción de símbolos). No es una preocupación sobre la banda ancha, pero considere un dispositivo móvil en un área con poco ancho de banda o usuarios que están en roaming global de datos: cada byte puede contar.

2. El navegador no puede almacenar en caché la secuencia de comandos en línea a menos que la propia página pueda guardarse en caché (lo que resultaría en una página muy opaca) Los archivos Javascript externos solo necesitan recuperarse una vez, incluso si el contenido de la página cambia cada vez. Puede afectar seriamente el rendimiento en conexiones de ancho de banda bajo.

3. El script en línea es más difícil de depurar porque el número de línea asociado con cualquier error no tiene sentido.

4. Se considera que el script en línea interfiere con las consideraciones de accesibilidad (508 / WAI), aunque eso no significa que todo el script en línea cause problemas. Si terminas con un lector de pantalla que anuncia contenido de script, ¡tienes un problema! (Nunca he visto que esto suceda).

5. El script en línea no se puede probar independientemente de su página; Los archivos Javascript externos se pueden ejecutar a través de pruebas independientes, incluidas las pruebas automatizadas.

6. El script en línea puede llevar a una separación deficiente de las preocupaciones (como lo describen muchas de las otras respuestas aquí).

Un argumento que me estoy perdiendo aquí es la posibilidad de una mayor protección contra los secuencias de comandos entre sitios .

Es posible deshabilitar la ejecución de JavaScript en línea en el navegador moderno a través de la Política de seguridad de contenido . Esto redujo el riesgo de que su sitio sea víctima de XSS. Este puede ser un argumento más convincente para que su administración invierta en eliminar el script en línea.

Hay varias razones que justificarían no incluir el script en línea:

• En primer lugar, la respuesta obvia es que el código es más limpio, más conciso, más fácil de entender y leer.

• Desde un punto de vista más práctico, a menudo desea reutilizar scripts / CSS / etc. En todo su sitio web, incluir estas partes significaría tener que editar cada página cada vez que haga un pequeño cambio.

• Si usa un SCM para su proyecto, tener sus diferentes componentes bien separados hará que el seguimiento de los cambios y los compromisos sea más fácil para todos los involucrados.

Por lo que yo sé, el rendimiento no sería una preocupación. Dependería de muchas cosas relacionadas con la naturaleza de su sitio web, las especificaciones de su servidor, etc. Por ejemplo, si su página web utiliza muchos javascript, su navegador puede almacenar en caché los scripts, lo que resultaría en un mejor rendimiento cuando El código está separado en varios archivos. Por otro lado, me sentiría tentado a decir que algunos servidores pueden servir un solo archivo grande más rápido que varios archivos más pequeños; en este caso, se podría argumentar que no separar el código es un mejor rendimiento.

No tengo conocimiento de ninguna prueba formal en esta área, aunque es muy probable que alguien las haya hecho.

Al final, diría que es una cuestión de buenas prácticas más que cualquier otra cosa, y que las ventajas en términos de legibilidad y organización (específicamente el punto 2) hacen que la separación del código en archivos distintos sea una opción mucho mejor.

La respuesta realmente depende de cómo se usa el código en línea (asumiendo que es javascript).

Utilizamos una combinación de código en línea, SSI's (lado del servidor), archivos js y archivos css para crear los efectos que queríamos y también para reducir los viajes de retorno del servidor para eventos onClick.

Entonces, para alguien que haga una declaración general de que el uso del "código en línea" es malo sin entender completamente cómo se usa, puede ser engañoso.

Habiendo dicho eso, si cada página tiene la misma copia y el código javascript pegado en lugar de usar un archivo js, digo que es malo.

Si cada página tiene su propia copia y la sección CCS pegada en lugar de usar un archivo css, digo que es malo.

También es muy costoso incluir tu biblioteca js completa en cada página, especialmente si ninguna de las funciones se usa en esa página.

Voy a asumir javascript en línea aquí.

Sin ver el código, es difícil estar seguro. Sospecho que se refería a una de dos cosas:

1. Tienes <script> s repartidos por toda la página
2. Todo lo que JS está en el encabezado de la página, no en archivos externos

La primera es una mala decisión de diseño. Difundir los scripts a lo largo de un archivo de origen hace que la página sea mucho más difícil de mantener, porque tiene que buscar un script determinado. Es mucho mejor mantener todo ese código en un solo lugar (prefiero en la parte superior del archivo de origen).