:::: MENU ::::

La evolución: Local Storage & Session Storage

¡Hola programadores!
Como ya dije hace un tiempo, me niego a poner el cartelito de las cookies, pero bueno, luego en la práctica no es para nada necesario y en realidad… si os quedáis hasta abajo, veréis que en este tema, no influye.

Sea como fuere, no vengo a hablar de esto, si no de la evolución de la web. Y es que Local Storage y Session Storage (aunque personalmente desprecio completamente la segunda), nos permite ver hacia dónde apunta el desarrollo web, y es que estas no pueden ser accedidas por el servidor.

¿Qué significa esto?
Muy fácil: así como las cookies son accedidas por el servidor, normalmente, ya que se mandan junto a las cabeceras, para controlar el logueo de los usuarios; el Local Storage, que no es más que un objeto en JavaScript en el cual podemos guardar strings, u objetos (si contamos que podemos hacer uso de funciones como stringify o parse de JSON), que es almacenado en el navegador al igual que las cookies, no puede ser leído ni se envía mediante las cabeceras al servidor.
Esto último implica que tenemos que usar JavaScript sí o sí para poder interactuar con dichos objetos, de esa forma esto marca una tendencia hacia tener un cliente que muestra la web a base de pequeños datos, como pueden ser objetos JSON, XML (que ya va quedando obsoleto…) u otros métodos como la utilización de node.js, en lugar de que sea el servidor que pre-procese el HTML añadiéndole el contenido.
Obviamente con cookies ya se podía hacer esto, permitiendo además que el servidor leyera directamente de ellas la información que necesitaba para identificar al usuario, pero que las nuevas tecnologías como es LocalStorage apunten a evitarlo, implica y marca una tendencia a seguir.

¿Es mejor?
En caso de usar node.js/websockets, no nos va a afectar, puesto que podíamos leer las cookies desde JavaScript con el objeto docmuent.cookie, pero eso reduce en un pequeñísimo porcentaje la carga de la web, puesto que no tiene que enviar las cookies mediante las cabeceras.
Si usamos PHP puro, podemos olvidarnos, pero lo que sí que podemos hacer, al igual que antes (solo que ahora creando la necesidad implícita de transferir los tokens de las sesiones mediante el método get o post en una petición ajax, y siendo esto una práctica que utilizan servicios como Habbo Hotel para cargar, por ejemplo, las notícias) es enviar con ajax, como he mencionado anteriormente, una petición al servidor, adjuntando también un token, y que este nos devuelva todos los datos necesarios para la web, que además serán colocados con JavaScript.
Con esto último, reduciremos considerablemente el tiempo de carga de nuestra web, o como mínimo el de repuesta del servidor, ya que una vez servido el HTML y los scripts por primera vez, no necesitaremos obtenerlo de nuevo para cambiar su contenido, puesto que podremos hacerlo con solo obtener objetos JSON (u otras maneras) y reemplazando el contenido de elementos por otros, como por ejemplo un campo de nombre de usuario.
No solo, además, podremos cambiar solo el contenido en cuanto a texto, sino que podremos también cambiar el HTML, implicando así que podremos cargar páginas distintas en una sola página, y gracias a funciones como ‘location.pathname.replace’, podremos incluso cambiar la dirección en la barra de direcciones, de forma que si un usuario copia un link al visualizar una foto y se lo pasa a otra persona, podremos cargar la foto directamente al cargar la página (como ya hace twitter o facebook).

Por supuesto, para proyectos pequeños en los cuales la carga del servidor no sea tan importante (ya que obviamente la diferencia será de milisegundos, y que si solo se ve una página será contraproducente), no necesitamos usar dicha nueva tecnología, que además de ser más tediosa y larga a la hora de desarrollar, también aumenta la carga en el navegador, mucho más que una simple página estática en HTML puro, de forma que si hacemos un pequeño blog o una web de empresa, con ni tan solo un millón de visitas mensual, no recomiendo hacerlo bajo ningún concepto.

Entonces… ¿Cookies o LocalStorage?
Fácil, como he aclarado en el párrafo anterior, según el tamaño del proyecto, cargar el cliente en exceso y/o si la carga del servidor no importa, usar LocalStorage es contraproducente. En cambio, si es un gran proyecto como Twitter o Facebook, entonces, usar el cliente como base para cargar toda la web puede ser la mejor opción. Por ende, yo usaría cookies si queremos tirar de servidor y LocalStorage si de JavaScript va la película.
A excepción de si usamos PHP, entonces usar LocalStorage no vale la pena del todo, de cualquier forma vamos a transferir los datos al servidor mediante cabeceras (ojo, si que nos puede servir para controlar qué datos le enviamos, y además, recordemos que si los datos son sensibles o solo se requieren para el funcionamiento temporal de la web, puede ser mejor usar LocalStorage).
Y sí, eso último que acabo de decir se hace posible con LocalStorage, pues este nos permitirá almacenar parámetros como el color de fondo que preferimos u otros detalles (incluso que pueden ser asignados por el servidor al iniciar sesión) y así no tener que cargarlos cada vez, reduciendo una petición al servidor por cambio/carga nueva de página.

Por ende, y contando que cada uno tiene sus pros y sus contras y que no nos vamos a saltar el cartelito de las cookies (puesto que este también es regulado por la famosa ‘ The Cookie Law’), va a depender del caso el hecho de usar uno u otro.

Para los que reclamen por la seguridad: ambos son IGUAL de seguros en cuanto a que el cliente los puede leer y modificar con tan solo la consola JavaScript, pero las cookies se enviarán al servidor en las cabeceras, mientras que el LocalStorage/SessionStorage permanece en el navegador si no lo enviamos nosotros con JavaScript.

Espero que os haya servido de ayuda esta pequeña reflexión.
¡Un saludo a todos!