¿Cuándo NO utilizar AJAX en el desarrollo de aplicaciones web?

Estoy construyendo una aplicación web con Zend Framework. He querido incluir algunos formularios tipo AJAX y cuadros modales, pero también quiero que mi aplicación sea lo más accesible posible. Quiero que mi aplicación sea mejorada por AJAX, pero también totalmente funcional sin AJAX.¿Cuándo NO utilizar AJAX en el desarrollo de aplicaciones web?

Por lo tanto, como una guía general ... ¿cuándo no debería usar AJAX? Quiero decir, ¿debería molestarme en usar mi aplicación sin AJAX? ¿O todos tienen navegadores AJAX habilitados en estos días?

Fuente

2009-11-25 Andrew

AJAX? ¿Tal vez estás hablando de "sin JavaScript"? Es una buena idea hacer que tu sitio funcione para los navegadores con js-disabled ... Pero creo que no vale la pena: demasiados esfuerzos para hacer felices a los usuarios del 1%. Y el 1% es un número sobrevalorado. Estoy seguro de que el 0.9% es un robot de búsqueda y solo el 0.1% son usuarios reales con navegador de texto o smtng sin soporte js. – NilColor

Aquí hay una pregunta similar: http://stackoverflow.com/questions/155615/ –

Si quiere decir "accesible" en el sentido de ADA, AJAX suele ser un no-no; su sitio debe proporcionar todo su contenido y funcionalidad principal usando solo estándar (X) HTML y CSS. Cualquier javascript utilizado simplemente debe extender la funcionalidad principal, y su sitio debe estar codificado para funcionar elegantemente en ausencia de un navegador habilitado para javascript.

Ejemplos: si desea que un usuario haga clic en una miniatura y obtenga una versión de tamaño completo de la imagen como resultado, puede hacer que la miniatura sea un enlace. Luego, el evento onclick disparará un método JQuery que cancela el comportamiento de navegación del enlace y muestra un divisor flotante JQuery para mostrar la imagen en la página actual. Si el navegador del usuario no es compatible con JavaScript, el evento onclick nunca se activará y se le presentará la imagen en una página nueva. La funcionalidad principal es la misma con o sin secuencias de comandos.

EDITAR: Ejemplo de esqueleto, código JQuery específico.

<html> 
<body> 
<a href="some.url" onclick="JQueryToOpenPopupImage(); return false;">Some URL</a> 
</body> 
</html>

Para cancelar la operación de navegación, sólo tiene que asegurarse de que el método invocado por el evento onclick devuelve falso al final.

Un buen ejemplo de la imagen emergente de JQuery que describí se puede encontrar here.

Fuente

2009-11-25 21:11:40 Dathan

¿Te importaría mostrar un código de ejemplo de cómo desactivar el clic y hacer algo más con jQuery, como mencionaste? – Andrew

Muy bien, he publicado una actualización de mi respuesta. – Dathan

Puede usar http://docs.jquery.com/Events/jQuery.Event#event.preventDefault.28.29. El código Javascript en onClick es más difícil de administrar. –

Use ajax si agrega valor para el usuario.

Si la versión de Ajax agrega un lote más valor que la versión que no es ajax, entonces podría justificar el gasto para desarrollar una solución que atienda a ambos clientes. En general, no recomendaría hacer el trabajo extra (recuerde ... más código da como resultado más mantenimiento).

Fuente

2009-11-25 21:02:31

La cantidad óptima de código no es código, por lo que estoy de acuerdo con cottsak: use ajax solo si agrega valor real para el usuario. – hora

98% de los usuarios tendrán navegadores habilitados para AJAX.

Un porcentaje significativo de esas personas no lo encenderán cuando visiten su sitio por primera vez (o tal vez nunca).

He visto sitios web que parecen una página en blanco sin javascript activado. No seas uno de ellos. Javascript para solucionar problemas de diseño es una idea horrible en mi opinión. Asegúrate de que se carga y se ve bien sin Javascript. Si la gente puede al menos ver lo que se están perdiendo, es probable que lo enciendan, pero si su sitio web parece simplemente roto, entonces ...

Fuente

2009-11-25 21:05:31

Defina "Un porcentaje significativo". De acuerdo con w3schools, a partir de enero de 2008, solo el 5% de los usuarios no tenían habilitado JavaScript http://www.w3schools.com/browsers/browsers_stats.asp y sospecho que verá que ese número disminuirá un poco este año. Además, la demografía es una cosa importante a considerar. Si el OP no se dirige a los desarrolladores ni a los paranoicos, es probable que JavaScript esté habilitado. –

5% es un número significativo en la mayoría de los círculos. Si tuviera que pagarme el 5% de sus ingresos, estoy seguro de que comenzaría a quejarse bastante rápido. –

Sin embargo, como un ejemplo más sólido, solo el 10% de los usuarios (con las mismas estadísticas) usan Chrome o Safari (~ 5% cada uno), pero donde trabajo también probamos ambos casos. –

A menos que esté apuntando a dispositivos móviles u otra web no estándar usuarios, puede estar bastante seguro de que la gran mayoría tiene Javascript habilitado, porque la mayoría de los sitios más importantes (incluido SO) dependen mucho de él.

Fuente

2009-11-25 21:06:02 Manu

Mi práctica es utilizar dos páginas principales, digamos index.py y ajax.py. El primero es responsable de generar el sitio web completo, y es el objetivo predeterminado de los formularios. Otro genera solo resultados específicos para una consulta adecuada de Ajax. La lógica detrás de ambos es la misma, solo que el método de generación de salida es un poco diferente. En jquery simplemente cambio el parámetro de acción cuando envío una solicitud. Funciona tanto con y sin ajax, aunque hace mucho tiempo que no he visto a alguien con discapacidades js y ajax.

Fuente

2009-11-25 21:07:56

A menudo tengo noscript bloque de Flash y JavaScript hasta que tome la decisión de que su sitio es digno.

Así que asegúrese de decirme lo que me falta si tengo JavaScript desactivado.

Fuente

2009-11-25 21:08:09 Nosredna

¿Te importaría mostrar un código de ejemplo de cómo detectar si el usuario ha desactivado javascript? – Andrew

Como no tiene JavaScript en ejecución, no puede usar JavaScript para verificar. En cambio, eche un vistazo a la etiqueta HTML noscript. – Nosredna

Me gusta la idea de codificar su aplicación sin JavaScript/Ajax y luego agregarla más tarde para mejorar la interfaz de usuario sin privar a los usuarios de la funcionalidad solo porque no tienen habilitado JavaScript. Leí sobre esto en Pro ASP.NET MVC, pero creo que lo he visto en otra parte al leer sobre JavaScript discreto.

Fuente

2009-11-25 21:38:16 Mayo

No debe hacer que su servicio se infle con efectos web 2.0 como acordeón, formularios modales/etc, zooms de imágenes, etc.
Utilice la tecnología moderna más inteligente (AJAX es una de ellas) y sus usuarios estarán contentos. No temas a AJAX: esto es muy bueno para que la experiencia del usuario sea fluida. Pero no haga las cosas porque le guste; hágalo porque su usuario lo necesite;)

Fuente

2009-11-25 22:01:06 NilColor

Depende de la complejidad de su aplicación web.
Si puede, tenerlo funcional con javascript disabled es excelente, ya que hace que su aplicación no solo pueda ser utilizada por usuarios en navegadores js-disabled sino también por robots. El día que decide escribir una aplicación para llenar automáticamente sus formularios, por ejemplo, no tiene que escribir una API desde cero.

En cualquier caso, ¡no utilice AJAX para TODO! Acabo de heredar un proyecto que básicamente consiste en una sola página que está llena de toneladas de llamadas AJAX y puedo decir que solo pensando en me da dolor físico. Supongo que al desarrollador original no le gustó el concepto de usar el botón Atrás/Adelante en el navegador como medio de navegación.

Fuente

2009-11-25 22:47:04 Loris

Creo que falta un punto aquí: Use Ajax solo para contenido que ningún motor de búsqueda necesita.

Fuente

2009-11-26 00:54:39 TheHippo

¿Cuándo quiere hacer que un sitio web parezca un sitio web, no una imitación fugitiva de una aplicación de escritorio?

Fuente

2009-11-26 00:56:23

No debe usar AJAX o JavaScript en los casos en que:

su sistema tiene que ser accesible
su sistema necesita ser buscar amigable

Sin embargo, mediante el uso de un moderno JS marco con algunas prácticas sólidas "discretas", puede mejorar progresivamente las páginas para que sean accesibles y fáciles de buscar, al tiempo que ofrece una interfaz de usuario hábil para los usuarios.

Fuente

2009-11-26 00:59:50

Esto depende totalmente del tipo de aplicación o función que esté desarrollando. Si es crucial que la aplicación sea accesible a pesar de la ausencia de Javascript, entonces sería útil contar con métodos alternativos (es decir, formas alternativas) para permitirle a su usuario usar dicha funcionalidad/función. Para eso, requerirá que dedique parte de su tiempo a desarrollar métodos para recopilar información, no solo utilizando scripts del lado del cliente, sino también del lado del servidor.

Para funciones diversas que solo sirven para mejorar la experiencia del usuario, en su mayoría no vale la pena desarrollar métodos alternativos.

No hay ninguna razón para no usar AJAX por completo. AJAX ayuda a minimizar su tráfico, después de todo.

Fuente

2017-02-03 12:02:17 RRB

Mi experiencia es que deberíamos usar ajax después de que funcione sin él. Por un par de razones. Primero, si algo se rompe en el ajax, y no lo tiene funcionando sin él, el sitio simplemente no funciona. Por ejemplo, una lista de productos con paginación. Debería funcionar solo con los enlaces, luego usar ajax cuando sea posible. En segundo lugar, para la indexación y accesibilidad del sitio. Si funciona sin ajax, es mejor.

Y es más fácil romper algo (aunque solo sea por unos momentos). Un código incorrecto, una excepción no detectada, una biblioteca externa no cargada, una extensión de bloqueo del navegador, ...

Después de todo funciona sin ajax, es bastante más fácil agregar ajax. Simplemente haz que el ajax capte la acción, agrega ajax = 1 y cuando devuelvas el resultado, devuelve solo lo que necesitas si ajax = 1, de lo contrario devuelve todo. En el ejemplo de la lista de productos, solo devolvería los productos y la paginación html, y los agregaría a la div correcta. Si ajax deja de funcionar, se carga la página completa y el cliente ve la segunda página a medida que se carga.

Ajax agrega mucho valor a UX. Si se hace bien, el usuario obtiene una gran sensación al usar el sitio, y un mejor uso de datos, ya que no carga toda la página cada vez.

Pero la pregunta es "cuando no se usa ajax", diría que siempre debes contar con ella para mejorar el UX pero no para que el sitio funcione (como otros usuarios también mencionaron). Y hoy en día necesitamos ambos, buen código y una gran experiencia de usuario.

Fuente

2017-02-04 09:57:21 sadlyblue

"si algo se rompe en el ajax", entonces lo arreglamos, al igual que si algo se rompe en el código sin AJAX, lo arreglamos – bugwheels94

"Después de que todo funciona sin ajax, es bastante más fácil agregar ajax". No creo que ese sea el caso. Con las API RESTful, la arquitectura en estos días es bastante diferente. Al sugerir el parámetro de consulta de uso ajax, ¿no está sugiriendo diseñar ambos? Y como dijiste "como otros usuarios también mencionaron", lo dijeron hace 8 años. Echo de menos cualquier punto fuerte en esta respuesta – bugwheels94

Por supuesto, si algo se rompe, lo solucionamos, pero hay un momento en que el error/error está rompiendo el sitio web. Si confía solo en ajax, podría ser un problema y el sitio web no podría funcionar correctamente. Y no olvidemos las incompatibilidades del lado del cliente. Y dependiendo de cómo diseñe el sitio web, podría ser más fácil de implementar. El uso del parámetro de consulta es como un complemento para la implementación que un nuevo.Y mi punto es que nunca confíes solo en ajax. Pero no hay ninguna razón (a menos que sea un cliente barato) para no usarlo. – sadlyblue

Puede usar siempre AJAX y actualizar el estado del historial mediante Push State o para obtener más compatibilidad, utilice el hash sin navegadores compatibles con HTML5.

con esto puede hacer que su servidor cargue una página, luego javascript lea el document.hash y reanude el estado de la base de la aplicación en el estado del hash.

por ejemplo, llegué a /index.html hago clic en algo, por ejemplo, un cliente para abrir el cliente de vista, puede cambiar el hash a #/view/client/{client_id}/, luego, si lo vuelve a cargar o lo vuelve a usar el hash con cambio y puede utilizar el evento onhashchanged para capturarlo y que coincida con el estado de los sitios a la nueva almohadilla entonces igual si uno de los favoritos de un cierto estado

Fuente

2017-02-09 00:47:23

Quiero que mi solicitud sea lo más accesible posible.

Puede hacer cosas como representar sus modales y formularios como una página que puede operar de forma independiente.

La versión AJAX tira de la plantilla en un modal/recipiente, la versión independiente comprueba si se trata de una petición AJAX y hace que la página, incluyendo el encabezado/pie de página (esto puede ocurrir a partir de la misma URL si se planifica bien)
La versión de AJAX intercepta el envío y la entrega de AJAX luego proporciona un agradecimiento en línea, el que no es AJAX abre una página de agradecimiento. Una vez más, es probable que pueda utilizar las mismas páginas para cada una de estas funciones si se piensa correctamente. La reutilización de plantillas y URL ayuda a evitar el mantenimiento adicional para las versiones AJAX/no AJAX.

Quiero que mi solicitud sea reforzada por AJAX, sino también completamente funcional sin AJAX.

Pensando través de la estructura de sus URL y plantillas puede recorrer un largo camino hacia el este, si usted hace la mayor parte de sus peticiones AJAX tirar en las plantillas completamente prestados (en lugar de sólo los datos), entonces por lo general puede usar el mismo URL para servir ambas versiones. Solo sirve solo las entrañas del modal/formulario a la solicitud de AJAX y la página completa a una solicitud normal.

¿Cuándo no debo usar AJAX?

No debe usar AJAX si al hacerlo causará una mala experiencia para una porción significativa de su base de usuarios (hay de técnicas de golf que se pueden utilizar para mitigar este)
No se debe utilizar AJAX si el tiempo de desarrollo asociado con su implementación será demasiado significativo para justificar las mejoras en la experiencia del usuario
No debe usar AJAX para contenido que tenga un valor SEO significativo sin implementar un respaldo apropiado que permita indexarlo (los rastreadores están mejorando) constantemente, pero sigue siendo una buena idea)

Quiero decir, ¿debería molestar en hacer que mi aplicación se pueda utilizar sin AJAX? O ¿todos tienen navegadores AJAX habilitados en estos días?

yo diría que una gran parte del tiempo que es innecesario, ya que la gran mayoría de los usuarios tendrán AJAX navegadores, pero hay situaciones en las que es crítica, tales como la optimización de SEO o cuando una gran parte de su base de usuarios es es probable que use navegadores que es menos probable que también admitan Javascript o donde es probable que tengan JavaScript/AJAX deshabilitado.

Algunos ejemplos de estos escenarios:

Un sitio web para una empresa o gobierno que utiliza un navegador obsoleto de serie
un sitio web donde una gran parte de los usuarios puede ser desactivada en una La manera en que pueden afectar negativamente su experiencia, como un sitio web para personas con problemas de visión o habilidades motrices, puede verse afectado negativamente al actualizar el contenido a través de AJAX, especialmente si ocurre rápidamente.
- Un sitio visitada regularmente por medio de un dispositivo o navegador menos común que provocará un impacto negativo a una gran parte de los usuarios

Entonces, ¿qué debería hacer?

pensar en quién se va a usar el sitio, cómo van a acceder a ella, y lo que van a acceder a ella con. También intente pensar no solo en el presente sino también en el futuro.
Diseñe el sitio de una manera que se adapte a la mayoría de estos usuarios.
Piense en quién ganará y quién perderá según mi decisión de utilizar AJAX y, en caso de duda, eche un vistazo a sus datos analíticos para ayudar a sopesar la decisión y si le faltan datos, puede valer la pena actualizar su seguimiento y obtener una muestra para ayudar a la decisión
Piensa que mi decisión de utilizar AJAX causa alguna contradicción con los requisitos básicos para este proyecto
Utilice AJAX para mejorar el contenido siempre que sea posible en lugar de hacerlo obligatorio, es decir, el contenido debería funcionar con o sin JS/AJAX
Considere el tiempo de desarrollo adicional involucrado con el uso de AJAX (si existe)

Fuente

2017-02-09 01:32:36 Brian

Un par de otros escenarios en los que uno puede ser mejor no utilizar AJAX:

Dejar que alguien a iniciar sesión en la aplicación web. Utilice el formulario tradicional de envío en su lugar.
Buscando y devolviendo más de unas 100 filas de la base de datos. O rompe el proceso o deja que el lenguaje del lado del servidor lo maneje.

Fuente

2017-02-09 07:29:19

"Usar el formulario tradicional enviar en su lugar". ¿Por qué? ¿Cuál es la desventaja de usar AJAX para enviar formularios? – bugwheels94

"O rompe el proceso o deja que el lenguaje del lado del servidor lo maneje". ¿Por qué crees que tiene algo que ver con AJAX? En AJAX, el lenguaje del lado del servidor maneja las bases de datos. Entonces, ¿qué sentido tiene – bugwheels94

(1)? No pretendía ser una declaración generalizada para todos los formularios como tal, solo aquellos que están destinados a permitir que el usuario inicie sesión en la aplicación web. No quiere decir que los inicios de sesión no se pueden hacer con AJAX, pero como el canal de autorización sería el más crítico de las interfaces de usuario, es conveniente diseñar la aplicación para que se encargue de los problemas de seguridad relacionados con las autorizaciones y el inicio de sesión. usar el lado del servidor solo y limitar AJAX para obtener los datos dinámicamente, una vez que se haya establecido la sesión. –

¿Cuándo NO utilizar AJAX en el desarrollo de aplicaciones web?

Respuesta

Cuestiones relacionadas