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
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.
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:
- la aplicación no es intuitivo o se desvía del modelo mental de los usuarios, o
- la aplicación es excesivamente difícil o demasiado caros de mantener para los que vienen después de nosotros
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.
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.
"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. –
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. –
No me importa que javascript se use siempre que no exponga información confidencial ni abra vulnerabilidades de seguridad.
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
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.
+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
me gustaría señalar a una pregunta/respuesta:
How many lines of code is in your custom jQuery script on your site? And how much is too much?
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.
demasiadas buenas respuestas para marcar solo una. – CountCet
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.
- 1. ¿Cuánto CSS es demasiado CSS?
- 2. ¿Cuánto de STL es demasiado?
- 3. ¿Cuánto JSON es demasiado JSON?
- 4. memoria php cuánto es demasiado
- 5. (HTML 5) ¿Cuánto es demasiado almacenamiento local?
- 6. ¿Cuánto manejo de ciclo de vida de Android es demasiado?
- 7. ¿Cuánto para iniciar sesión en una aplicación y cuánto es demasiado?
- 8. ¿Cuánta abstracción es demasiado?
- 9. ¿Cuánto proceso debe seguir un solo desarrollador? ¿Es demasiado un proceso formal?
- 10. ¿Cuál es la desventaja de usar demasiado JavaScript?
- 11. ¿Cuánto JavaScript dejas que genere Rails?
- 12. ¿FILTER_VALIDATE_URL es demasiado estricto?
- 13. caso onbeforeunload es demasiado entusiasta en IE9
- 14. ¿Cuándo es demasiado "acción lambda"?
- 15. ¿Este código es demasiado frágil?
- 16. PHP: scandir() es demasiado lento
- 17. espíritu Boost es demasiado codicioso
- 18. gcc -Wshadow es demasiado estricto?
- 19. ¿Cuánto se utiliza PhoneGap?
- 20. ¿Qué es em font-size? ¿Cuánto es en píxeles?
- 21. DI: ¿Cuánto inyectar?
- 22. ¿Qué es el comando Unix para ver cuánto espacio en disco hay y cuánto queda?
- 23. figura de imshow() es demasiado pequeña
- 24. Mi archivo de registro es demasiado grande
- 25. ¿Cuándo es un CSS Sprite demasiado grande?
- 26. ¿Es demasiado difícil un proyecto? ¿Qué haces?
- 27. ¿Cuándo es una clase demasiado larga?
- 28. LayoutLib es demasiado reciente. Actualiza tu herramienta?
- 29. vba lookahead positivo es demasiado codicioso
- 30. Unir consultas y cuando es demasiado
Muy buen enlace! Lo encontré útil. –