Avance rápido hasta diciembre de 2017, Websockets es compatible con (prácticamente) todos los navegadores y su uso es muy común.
Sin embargo, esto no significa que Websockets haya logrado reemplazar AJAX, al menos no por completo, especialmente porque la adaptación HTTP / 2 está en aumento.
La respuesta breve es que AJAX sigue siendo excelente para la mayoría de las aplicaciones REST, incluso cuando se usan Websockets. Pero Dios está en los detalles, así que ...:
AJAX para encuestas?
El uso de AJAX para el sondeo (o el sondeo largo) está desapareciendo (y debería serlo), pero aún permanece en uso por dos buenas razones (principalmente para aplicaciones web más pequeñas):
Para muchos desarrolladores, AJAX es más fácil de codificar, especialmente cuando se trata de codificar y diseñar el backend.
Con HTTP / 2, se eliminó el costo más alto relacionado con AJAX (el establecimiento de una nueva conexión), lo que permitió que las llamadas AJAX fueran bastante efectivas, especialmente para publicar y cargar datos.
Sin embargo, Websocket push es muy superior a AJAX (no es necesario volver a autenticar o reenviar encabezados, no se necesitan viajes de ida y vuelta "sin datos", etc.). Esto fue discutido varias veces.
AJAX para DESCANSO?
Un mejor uso para AJAX son las llamadas REST API. Este uso simplifica la base del código y evita que la conexión Websocket se bloquee (especialmente en cargas de datos de tamaño mediano).
Hay una serie de razones convincentes para preferir AJAX para llamadas API REST y cargas de datos:
La API AJAX fue diseñada prácticamente para llamadas API REST y es una excelente opción.
Las llamadas y cargas REST usando AJAX son significativamente más fáciles de codificar, tanto en el cliente como en el backend.
A medida que aumenta la carga útil de datos, las conexiones de Websocket pueden bloquearse a menos que se codifique la lógica de multiplexación / fragmentación de mensajes.
Si se realiza una carga en una sola sendllamada de Websocket , podría bloquear una transmisión de Websocket hasta que la carga haya finalizado. Esto reducirá el rendimiento, especialmente en clientes más lentos.
Un diseño común utiliza pequeños mensajes bidireccionales transferidos a través de Websockets mientras que REST y las cargas de datos (cliente a servidor) aprovechan la facilidad de uso de AJAX para evitar que el Websocket se bloquee.
Sin embargo, en proyectos más grandes, la flexibilidad que ofrece Websockets y el equilibrio entre la complejidad del código y la gestión de recursos inclinarán la balanza a favor de Websockets.
Por ejemplo, las cargas basadas en Websocket podrían ofrecer la posibilidad de reanudar cargas grandes después de que se desconecte y restablezca una conexión (¿recuerda la película de 5GB que quería cargar?).
Al codificar la lógica de fragmentación de carga, es fácil reanudar una carga interrumpida (la parte difícil fue codificar la cosa).
¿Qué pasa con HTTP / 2 push?
Probablemente debería agregar que la función de inserción HTTP / 2 no reemplaza (y probablemente no puede) a Websockets.
Esto se discutió aquí anteriormente, pero es suficiente mencionar que una sola conexión HTTP / 2 sirve a todo el navegador (todas las pestañas / ventanas), por lo que los datos que HTTP / 2 envía no saben a qué pestaña / ventana pertenece, eliminando su capacidad para reemplazar la capacidad de Websocket de enviar datos directamente a una pestaña / ventana específica del navegador.
Si bien los Websockets son excelentes para la comunicación de datos bidireccional pequeña, AJAX aún tiene una serie de ventajas, especialmente cuando se consideran cargas útiles más grandes (cargas, etc.).
¿Y seguridad?
Bueno, en general, cuanto más confianza y control se ofrece a un programador, más poderosa es la herramienta ... y más preocupaciones de seguridad surgen.
AJAX por naturaleza tendría la ventaja, ya que su seguridad está integrada en el código del navegador (que a veces es cuestionable, pero todavía está allí).
Por otro lado, las llamadas AJAX son más susceptibles a los ataques de "hombre en el medio", mientras que los problemas de seguridad de Websockets generalmente son errores en el código de la aplicación que introdujo una falla de seguridad (por lo general, la lógica de autenticación de back-end es donde los encontrará).
Personalmente, no creo que esto sea una gran diferencia, en todo caso creo que los Websockets están un poco mejor, especialmente cuando sabes lo que estás haciendo.
Mi humilde opinión
En mi humilde opinión, usaría Websockets para todo excepto las llamadas a la API REST. Cargas de Big Data que fragmentaría y enviaría a través de Websockets cuando sea posible.
Las encuestas, en mi humilde opinión, deberían prohibirse, el costo en el tráfico de red es horrible y el empuje de Websocket es lo suficientemente fácil de administrar incluso para los nuevos desarrolladores.