El protocolo HTTP, además, no tiene estado. Cada consulta que recibe un servidor es totalmente nueva para él. Por ello son necesarias las cookies (o mantener un id en la URL) para que el servidor rescate la información de una sesión de un mismo usuario.

Pronto apareció la necesidad de no tener que recargar una página entera para actualizar una parte de ella, lo que conocemos hoy como AJAX. Microsoft inventó el Remote Scripting en 1998 seguido pronto por la librería JSRS de Brent Ashley, pero no fue hasta 2005 cuando Jesse James Garrett acuñó el termino en Ajax: a new approach to Web Applications con el que conocemos a esta técnica basada en aprovechar una conexión desde JavaScript para solicitar datos al servidor y actualizar la página visualizada en cuanto llegue la respuesta.

¿Qué tenemos? Una web asimétrica en la que aplicaciones web en un navegador realizan peticiones (de una página o parciales) a un servidor web. ¿Qué nos falta? Un método para que un servidor nos realice notificaciones (cuando algo cambia). Es lo que se conoce como PUSH y es idéntico a los sistemas de notificación de llegada de correo electrónico en los móviles: con una BlackBerry necesitamos una conexión continua con un servidor para que éste nos notifique las novedades.

Existen tres formas para conseguir que el navegador se entere de que hay novedades:

• Consultar insistentemente al servidor. Es la forma más ineficiente. Consume muchos recursos y la mayor parte de las veces la respuesta va a ser que no hay nada nuevo. Es el sistema que se utiliza con las fuentes RSS o ATOM sobre novedades en una web. Es equiparable al niño en el asiento de atrás del coche preguntando cada 10 segundos: "¿Cuánto queda?"
• Comet. Abrir una conexión permanente/persistente con el servidor web. También consume recursos y origina un problema al obligar a que el servidor mantenga abiertas un número elevado de conexiones. Es posible implementarla sobre HTTP de forma que el servidor web no cierre una conexión y vaya ofreciendo la información en pequeñas dosis con las actualizaciones. O bien se puede montar un servidor paralelo dedicado a ellas. Es el sistema que se utiliza en los chats web.
• Finalmente, y he aquí la novedad, se puede rescatar la idea original de Tim Berners-Lee y añadir un pequeño servidor a cada navegador. ¿Con qué finalidad? Permitir que un servidor nos haga una petición directamente al navegador. Si no lo has visto aún, echa un vistazo a esta demo. Esa página web, crea una conexión persistente con un servidor, a través de la cuál puede recibir peticiones que la propia página web en el navegador se encarga de contestar (mediante una petición HTTP con la respuesta al mismo servidor). Funciona y permite hacerse una idea de las posibilidades, aunque no haya un servidor realmente en el navegador. El principal inconveniente de implementar un servidor como tal es que por la arquitectura de Internet resulta muy complejo conseguir que éste reciba peticiones desde el exterior saltándose proxies y firewalls. Por ello en el ejemplo anterior, conocido como ReverseHTTP, la conexión de servicio la inicia el navegador, porque en ese sentido (navegador -> servidor web) la conexión no es un problema. La idea que intento transmitir es vencer la asimetría del HTTP (el servidor no puede enviar información al navegador) creando una infraestructura idéntica a la existente pero en sentido contrario (el servidor se convierte en cliente/navegador y realiza peticiones HTTP al servidor incorporado en el navegador del visitante). Se trata de una solución extremadamente elegante que permite la que esta empezando a conocerse como web en tiempo real. Al mecanismo por el que un servidor notifica a otro mediante una petición HTTP a una URL acordada entre ambos se conoce como WebHook. Actualmente se empieza a usar entre servidores de Internet y permite, por ejemplo, que un nuevo artículo de una web sea enviado a nuestro móvil en el instante en que es publicado. Términos como PushButton, RSSCloud o PubHubSubBub están ahora mismo en pleno auge, pero sigue necesitándose un estándar en el mismo navegador que permita convertirlo en una especie de servidor que reciba notificaciones y actúe en consecuencia. Y estamos a un solo paso: HTML5 Server-sent Events.

La Web en Tiempo Real es un paradigma basado en enviar información a los usuarios tan pronto como esté disponible - en lugar de requerir que éstos o su software compruebe periódicamente si hay actualizaciones. Puede ser habilitada de diferentes formas y puede requerir una arquitectura técnica distinta. Se está implementando en redes sociales, búsquedas, noticias, y otros sitios - haciendo esas experiencias más parecidas a la Mensajería Instantánea (chat) y facilitando innovaciones imprevisibles. Los primeros beneficios incluyen un compromiso mayor de los usuarios ("flujo") y cargas más reducidas en los servidores, pero esto es sólo el principio. La entrega de información en tiempo real probablemente se haga ubicua, un requisito para casi cualquier website o servicio.