Summary

  • El primer borrador del W3C sobre Web Storage, publicado el 23 de abril de 2009, usó dos reservas de avión simultáneas para mostrar cómo una cookie compartida podía cruzar decisiones entre ventanas.
  • sessionStorage guardaba datos por ventana principal y origen. localStorage daba al origen un espacio que podía sobrevivir a esa ventana y estar disponible en las demás, sin viajar automáticamente en cada petición HTTP.

En una ventana, el vuelo sale a las ocho. En la otra, a las seis, esa hora en que la terminal parece un castigo con tiendas. La persona va y viene: mira el equipaje, cambia un asiento, revisa el precio. Cuando por fin pulsa comprar, la web le presenta el itinerario equivocado. Su cookie recuerda un vuelo. Ha trabajado con entusiasmo. El problema es que había dos.

El primer borrador de Web Storage del W3C, fechado el 23 de abril de 2009, describe precisamente una compra de billetes de avión en dos ventanas. Si el sitio emplea una cookie para identificar el viaje en curso, la elección de una ventana puede filtrarse a la otra. El texto lleva el accidente hasta el bolsillo: el cliente podría terminar comprando dos billetes para el mismo vuelo. Las especificaciones rara vez muestran tan pronto la factura de una mala decisión de diseño.

La cookie acompaña las solicitudes dirigidas al sitio. Es práctica para que el servidor reconozca el navegador, pero una cookie común a las dos ventanas difícilmente distingue qué compra sigue activa en cada una. El navegador sí conoce esa distinción: sabe a qué ventana principal pertenece cada documento. Web Storage puso a disposición de los programas un pequeño almacén cuya dirección incluía esa frontera.

El primer cajón se llamó sessionStorage. La Recomendación de 2013 asigna áreas de sesión a cada contexto de navegación principal y a cada origen. Las páginas sucesivas de un mismo sitio, abiertas en la misma ventana, pueden recuperar las decisiones de ese itinerario. Otra ventana trabaja con su propia área. Si una ventana relacionada nace de la primera, puede recibir una copia inicial; a partir de ahí, ambas copias cambian por separado. La comparación de vuelos deja de depender de una única nota pegada al monitor que diga «el vuelo actual».

El origen completa la dirección. Cada sitio tiene sus áreas; otro origen no abre esos cajones a su antojo. En la reserva, la ventana separa las dos operaciones simultáneas y el origen identifica a qué sitio pertenecen los datos. Es una división sencilla que permite a la persona cambiar de página durante una compra sin perder el hilo y, a la vez, mantener vivo otro hilo en la ventana de al lado.

El segundo cajón fue localStorage. Sus claves y valores pertenecen al origen y pueden seguir disponibles entre ventanas y después de una sesión. El borrador imaginaba documentos escritos por la persona o datos de correo guardados en el navegador. Una cookie se envía con cada petición aplicable; el valor local permanece en el equipo hasta que el programa lo consulta y decide qué comunicar. La especificación incluye un contador de visitas como ejemplo: para recordar un número, la página ya no necesitaba adjuntarlo a cada viaje por la red.

La segunda edición de 2016 detalló la conducta de esos cajones. setItem, getItem, removeItem y clear administran las entradas. Si una escritura o eliminación falla, el área conserva el estado anterior. Cuando el espacio se agota o una política impide guardar, setItem puede lanzar QuotaExceededError. Los demás documentos que comparten el área pueden recibir un evento storage al cambiar una clave. Los programas deben observar valores coherentes; la especificación no exige esperar a que cada operación termine físicamente en el disco.

La comodidad tenía una pelea interna. En la sección de problemas de la Recomendación de 2013, algunos implementadores consideraban demasiado caro el bloqueo previsto para evitar carreras entre scripts de distintas ventanas. El pequeño cajón compartido necesitaba reglas de tráfico. Cuanto más fácil parecía guardar una clave, más trabajo exigía decidir quién podía verla mientras otro script la cambiaba.

La cronología oficial del W3C pasa del borrador de 2009 a las Recomendaciones de 2013 y 2016. El ejemplo de los billetes siguió allí porque la pregunta sobrevivió a cada edición: ¿a qué escala debe existir un recuerdo? Una compra en curso cabe en su ventana. Un borrador que debe permanecer, en el espacio del origen. La cookie sigue su ruta hacia el servidor. Ordenados los cajones, el pasajero puede concentrarse en lo importante: si de verdad quiere levantarse a las cuatro de la mañana.