2009-01-27 18 views
14

Recientemente he estado trabajando con alguien en un proyecto que es muy ajax intenso. Todas las llamadas se realizan a servicios web utilizando ajax y la lógica de datos se maneja en el lado del cliente. El código del lado del servidor simplemente actúa como data access layer y hace poco más. ¿Cuánto javascript es demasiado?Cuánto javascript es demasiado

Respuesta

11

Realmente depende de sus necesidades y las expectativas del usuario. Mi única sugerencia es pensar en los lugares que está haciendo AJAX cuando el usuario en su lugar realmente espera navegar una página nueva. Esos son los casos en los que está haciendo "demasiado".

Recuerde, el usuario pasa el 99% del tiempo usando otros sitios, no el suyo. Asegúrese de que su sitio web cumpla con lo que espera del resto de la web, así como del uso de computadoras en general.

Por cierto, las pruebas de usabilidad se pueden utilizar para descubrir "lo que el usuario realmente espera" en cualquier área. Sus juicios como diseñador probablemente sean completamente diferentes a los de los usuarios típicos; ver también Why You Only Need to Test with 5 Users.

+0

Muy buen enlace! Lo encontré útil. –

9

Si la aplicación resultante es intuitiva y útil para el usuario, entonces no puede decir que ha usado demasiada tecnología.

Brindar una gran experiencia de usuario es lo que nuestro principal objetivo como desarrolladores de software debe ser. La tecnología que utilizamos para hacer eso es solo un habilitador.

Sólo han usado demasiado de/la tecnología equivocada si:

  1. la aplicación no es intuitivo o se desvía del modelo mental de los usuarios, o
  2. la aplicación es excesivamente difícil o demasiado caros de mantener para los que vienen después de nosotros
16

Javascript puede ser demasiado cuando se revela demasiado el cliente, entonces lo miraría desde la perspectiva de seguridad. Desde la perspectiva del rendimiento en general, usar Javascript es mejor.

3

La pregunta es más bien, ¿la aplicación todavía proporciona características necesarias como la capacidad de marcar y respetar el historial de navegación de los usuarios?

Si el usuario no puede marcar una página/estado específico, eso debe ser marcado, eso es una señal de advertencia.

Además, no poder usar sensiblemente el botón Atrás puede causar dolor.

+0

"bookmarkability"/"el botón Atrás" y "demasiada javascript" no son mutuamente excluyentes.Se pueden resolver con más Javascript :) Pero en serio, a veces la ganancia de un esfuerzo significativo en javascript supera la pérdida de marcadores. por ejemplo, Google Maps. –

+0

Tienes mucha razón. Algunos problemas pueden solucionarse con aún más JS. Google Maps lo hace al tener el widget "enlace" donde puede copiar la vista actual como URL directa. Si bien veo que no es posible, de lo contrario, en este caso, todavía debe haber una compensación conciente entre la usabilidad y el rendimiento. –

4

No me importa que javascript se use siempre que no exponga información confidencial ni abra vulnerabilidades de seguridad.

0

Demasiado de todo es:

Cuando no se puede leer el código

Cuando el usuario no get/necesidad/como/etc la interfaz de usuario

Cuando esté matando los recursos del lado del servidor/del lado del cliente que necesites

3

Yo diría que para cualquier técnica, si estás ignorando un método más directo de resolver un problema a favor de hacer todo "de la misma manera", hay una oportunidad oportunidad de que te sobrepases haciéndolo. Una forma fácil de probar esto es tomarse un tiempo extra para escribir una prueba de concepto que no utilice el método en cuestión y llevar un registro de cuánto tiempo le lleva hacerlo, etc. Si puede lograr lo mismo con su prueba de concepto y entregar una experiencia adecuada para el usuario, entonces la estrategia de desarrollo puede tener que cambiar.

+0

+1 por tomar el enfoque más directo. Yo agregaría que hay un equilibrio entre el tiempo ahorrado para el desarrollador y el tiempo ahorrado para el usuario; es una compensación, y en algún punto, comerciar demasiado en cualquier dirección es algo malo; y muy a menudo el rendimiento óptimo para el desarrollador y el usuario es tomar un enfoque más directo. Tenga en cuenta que gran parte de lo que se utiliza AJAX es para emular las actividades de navegación, pero dentro de un navegador. Empujar esa redundancia rápidamente se vuelve autodestructivo. – zxq9

0

Esto realmente depende de lo que el proyecto es para.

¿Quiénes son los usuarios? ¿Es esto solo una cosa interna o estará abierto al mundo? ¿Están esperando una interfaz de estilo web regular? ¿Eso se interpondrá en el camino de la usabilidad de la vista?

¿Qué tan seguro debe ser? Usar javascript abre una gran cantidad de su aplicación a los usuarios, lo que puede ser un problema de seguridad.

¿Puede la máquina típica de los usuarios manejar tanta javascript (las máquinas antiguas pueden ser casi inútiles con una gran cantidad de javascript)?

Hay muchas preguntas que deben responderse antes de poder decidir cuánto javascript es demasiado.

Al final, lo más probable es que termine decidiéndose por pruebas y comentarios de los usuarios.

+0

demasiadas buenas respuestas para marcar solo una. – CountCet

0

Depende de varios factores:

  • hace el script revelan información al usuario final sobre el funcionamiento interno de su aplicación?
  • ¿Necesitas mantener una amplia gama de navegadores?
  • ¿Necesitas apoyar a los usuarios móviles (o PDA's)?
  • ¿Impone la lógica comercial con Javascript? (Generaly esto debe hacerse en el servidor)
  • Etc.

Una vez que tenga una respuesta a estas preguntas, creo que es fácil de determinar wheter que ha cruzado una línea en algún lugar o no. Además de esto, desde el punto de vista del rendimiento, distribuir la carga del procesador al cliente siempre es algo bueno. La aplicación de la lógica comercial del lado del cliente también está bien, pero asegúrese de verificar dos veces en el servidor.

Espero que esto ayude.

Cuestiones relacionadas