2009-05-11 19 views
5

A veces escucho el argumento en contra de hacer cosas en el lado del cliente usando javascript. La gente dice cosas como "JavaScript es ineficiente ... o lento". Me pregunto si hay hechos reales que respalden esta conclusión.¿Qué tan eficiente es javascript?

+5

"lento" o "ineficiente" en comparación con otro lenguaje de scripting del lado del cliente? – Joseph

+3

"Ineficiente" y "lento" son términos altamente subjetivos, porque plantean las preguntas, demasiado ineficientes o lentos para quién? En comparación con qué? –

Respuesta

12

En realidad, hay dos factores en el rendimiento de JavaScript:

  1. Su código
  2. El motor de secuencias de comandos que se ejecutan su código

Su código es el factor más fácil de solucionar. Mientras desarrollas, optimiza tu código lo mejor que puedas. Fácil.

El segundo no siempre es tan fácil. He tenido algunas aplicaciones donde el rendimiento en un navegador fue excelente y otro fue más lento que el barro. Otros corren muy bien en todos los ámbitos. Lo mejor que puede hacer es probar, probar, probar y probar nuevamente. Si quieres un buen artículo, consulte el enlace:

Coding Horror: The Great Browser JavaScript Showdown

+0

que es un gran mensaje de jeff atwood. Gracias. –

+6

Tres factores! El navegador es el tercero y generalmente el más lento. Recuerde que el DOM no es parte de Javascript, sino del navegador. – svinto

2

Eso depende mucho del motor de JavaScript del navegador.

En general, es un lenguaje de scripting, por lo que no funcionará tan bien como C++ u otro lenguaje compilado. Sin embargo, es bueno para lo que estaba destinado, y eso es conducir las páginas web.

0

Bueno, depende. ¿A qué lo estás comparando? Difiere mucho entre diferentes navegadores.

Puede funcionar muy bien, o al revés, según el código escrito.

TIENE que usar JavaScript para hacer ciertas cosas, como manipular el dom por ejemplo.

0

¡Me imagino que en la mayoría de los casos es mucho más rápido que una publicación posterior!

+0

¡Si vas a votar abajo al menos explica por qué! – stevehipwell

0

Diría que es una respuesta incorrecta. ¿Cómo medirías el rendimiento de JavaScript y lo usarías para comparar? Supongo que, siempre que JavaScript sea la única opción para la programación web del lado del cliente (no estoy hablando de VBScript), no se puede decir nada con respecto a su eficacia.

+0

Sí puede, puede determinar si es mejor enviar el procesamiento al cliente o al servidor. También puede determinar qué guardar y qué cortar, algunas cosas simplemente no se pueden hacer en ie6 a cualquier velocidad. – garrow

+0

Probablemente malinterpreté la pregunta. Estaba pensando si el uso de JavaScript es eficiente en absoluto. Y sí, tienes toda la razón, hay varias preocupaciones con respecto a que allí exactamente se pone la lógica de producir cálculos diferentes. Como regla general, la lógica debe dividirse de la siguiente manera: "No debe haber ninguna lógica comercial en la interfaz". El objetivo principal de JavaScript es hacer cosas de aspecto dinámico y mejorar la experiencia del usuario. Y todavía dudo de cómo se puede medir la eficacia de JavaScript en eso. –

0

También depende de cómo escriba su código. Si sigues las mejores prácticas, está bien y, como dije antes, ¡es mejor que las devoluciones!

0

Usted sólo puede realmente responder a esta pregunta en el contexto de un problema específico que estamos tratando de resolver. Publique un ejemplo y luego podemos debatir los méritos de varias tecnologías ...

0

Javascript no es ineficiente, la eficiencia no depende del idioma. Los intérpretes pueden ser ineficientes. Por ejemplo, el intérprete de Firefox se ejecuta muy lento en FF para Linux y mucho mejor en FF para Windows. Chrome ha implementado un intérprete que es mucho más rápido. Hay intérpretes de Javascript que no se ejecutan en un navegador, por lo general son más rápidos.

1

Javascript es RÁPIDO si lo usa correctamente. De otro modo, se comporta mal. Por ejemplo: un bucle ilimitado puede colgar su navegador.(Pero el navegador le preguntará si desea detener la ejecución)

+0

lol, um, ¿no es así como TODO lo es? si un programa de C++ tiene un bucle ilimitado, el sistema operativo le preguntará si desea eliminar el programa. –

+1

@Darren: si una aplicación C++ (o cualquier otra aplicación de escritorio) tiene un bucle ilimitado (normalmente llamado "infinito", ¿no?), El sistema operativo solo le pedirá que lo mate si se comporta de algún modo. Por lo general, esto significa que no responde a las señales. Si no se envían señales (incluyendo cualquier tipo de señal de ping), permitirá que su programa se ejecute para siempre sin interrupción. No es así con JS en un navegador. – rmeador

1

La elección de qué tareas realizar en el cliente y en el servidor es importante, y la eficacia de JavaScript como idioma no es el único factor que debe ser considerado.

Los datos que se manipularán en el cliente se deben transmitir al cliente. Si el script no necesita toda la información que se enviará al cliente, el tiempo de carga de la página se verá afectado y la operación de filtrado se realizará en el extremo menos eficiente del enlace (es decir, pagará por la red). tiempo de transmisión antes de que el usuario obtenga su información).

Las reglas de negocio que se ejecutan en el cliente estarán expuestas a usuarios finales curiosos.

Las reglas comerciales de validación que se ejecutan en el cliente se deben ejecutar nuevamente en el servidor, porque no se puede confiar en que el código se ejecute en un entorno que no se controla.

Los diferentes navegadores e incluso entre las implementaciones de ECMAScript disponibles dentro de una familia de navegadores dada hacen que esta pregunta sea desagradablemente subjetiva y sujeta a mucha variación.

0

Supongo que lo que las personas intentan decirle es: haga lo que pueda en el servidor, en lugar de poner todo el código en el lado del cliente.

El rendimiento de JavaScript difiere de un navegador a otro (o de un intérprete a otro), pero javascript no debe cumplir los mismos fines que los lenguajes del lado del servidor.

+0

Flávio, una mejor manera de decir lo que quieres decir es usar JS para lógica de UI, no para lógica de negocios. Combine eso con AJAX como consumidor de sus propios servicios web y tenga la poción adecuada para una aplicación de rendimiento –

0

Soy un "chico de los números" así que cuando alguien dice cosas como "bueno, X es lento" o "por supuesto, porque Y es rápido", eso realmente me saca de quicio. Así que para empezar, es necesario utilizar datos reales si se va a realizar cualquier tipo de evaluación:

JavaScript Performance Rundown

También pienso viendo Dromaeo en acción es un poco frío

0

navegadores modernos están implementando más y más compilación justo a tiempo para sus intérpretes.

Mi regla de oro es que si no puede confiar en que JavaScript esté encendido, haga todo lo que pueda en el servidor. Si sabe que JavaScript está activado, haga todo lo que pueda en el cliente y ahorrará ancho de banda y carga del servidor.