Subscribe to our newsletter
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Whether you're brand new to working with the Web Storage API or you've been around the block already, you likely already have your own thoughts on the future of these technologies. Read this latest blog from our Front End Developer Almaz Gabdulbarov to see what his take is on the future of modern Web Storage APIs.
Modern browsers offer different interfaces for working with browser memory. Such interfaces include well-known features like cookies, localStorage / sessionStorage, but also less-known features such as file system access and cache storage. In this article, we will review these technologies and understand suitable uses. And, perhaps, we will realize that it's time to abandon some of these technologies and stop using them in projects altogether. For example, you may be surprised to find that popular features like localStorage might not be the best fit for all situations.
A "cookie" is a small piece of data sent by a web server and stored on the user's computer. This method of storing data in the browser is one of the most popular at the moment. After all, everyone has seen the pop-ups á la “Our site uses cookies, if you agree with this, please click Accept.”
The convenience of this technology is that every time the client tries to open the page of the corresponding site, it sends a fragment of data from cookies to the web server as part of an HTTP request. Using cookies is a good, functional solution.
But if your project only involves storing data in cookies, there might be better options. Why?
It's all about the amount of data stored. Cookies provide a very small amount of storage space.
Sending cookies with all HTTP requests may affect performance and speed.
According to Wikipedia, internet storage or DOM storage is the software method and protocol of a web application used to store data in a web browser. Internet storage is permanent data storage, similar to cookies, but with a significantly expanded capacity and without storing information in the HTTP request header. There are two main types of web storage: local storage (localStorage) and session storage (sessionStorage), which behave similarly to persistent and session cookies, respectively[1]. Here the data is stored in string format.
The main, but not the only problem with session/local storage is performance. The Web Storage API is a synchronous API. This means that they occupy the execution thread (event loop) at the moment when the data is being saved. We won't go into the details of the event loop here, but we can superficially mention that it impacts the render speed of our web application.
This technology is already prohibited (deprecated). This technology was an SQL lite client, with the help of which it was possible to create realDB tables and SQL queries. But if for some reason you want to use SQL client, there is a good analog, which we will talk about later.
Application Cache is also deprecated. This technology helped make your Web application available offline roughly 10 years ago. With the development of PWA and hybrid applications, it has now lost its relevance.
As described on Wikipedia, IndexedDB is a JavaScript application programming interface (API) for client storage of large amounts of structured data, including files/blobs. In other words, it is a NoSQL data store in JSON format inside the browser.
File and Directories are not currently prohibited (but at the time of publication of this article they may already be deprecated). This technology only works on Chromium-based browsers. The main idea is to create an “artificial" file system for a specific origin. Directories and files can be created in this file system. It is supported by all modern browsers.
Including Cache Storage here may seem like cheating. But the thing is that the Cache Storage Interface is not an API and belongs to the Service Workers functionality. It is used to store HTTP responses - assets that we can save from the browser. It is supported by all modern browsers.
This API is the newest, and is probably the future of Web development. But at the moment, this technology is not supported by WebKit-based browsers. For instance, there is no full-fledged support in Safari.
This technology allows you to work through certain APIs with the real OS file system. Of course, to use this technology, the user must allow access to various client actions (access to open / create files and folders, read, write).
As I mentioned before, Safari does not provide full support for the FileSystem Access API and uses Origin Private FS instead. Origin Private FS does not provide access to the real file system and gives some small memory space to use.
For example, the online version of Visual Studio Code https://vscode.dev / uses this technology. Here you can fully create folders and files and write code. It's amazing! At this moment, I sincerely believe in the future only with Web applications, without installing desktop versions on our computers.
To fully describe the memory volumes of each technology, let's first introduce the concept of Quotas.
Local Storage provides up to 5 megabytes of memory for a web application. (<=5Mb).
Session Storage provides up to 12MB (<=12Mb).
IndexedDB provides all fully accessible browser quotes. And this amount of memory can reach up to 1 gigabyte!
For FileSystem Access, the amount of memory is not limited and theoretically can reach the entire available computer memory
And the larger amount of memory for IndexedDB is another reason why it is better in the modern world to use IndexedDB instead of Local Storage / Session Storage when launching new Web applications.
At the moment, there are a huge number of different technologies for the operation of the Web Storage API. But in my opinion, in modern browsers, it is already better to use IndexedDB instead of the incredibly popular localStorage. I know that many people are repelled from using IndexedDB by the seemingly complex syntax, because here the work is done with the database in the browser. However, this “complexity” is not entirely true. On the contrary, IndexedDB provides more flexibility, more supported work formats, and more memory.
Let's also hope that one day we will get full-fledged FileSystem Access on Apple browsers. Then let's live!
Almaz Gabdulbarov has worked with First Line Software as a Front End Developer for a year and a half, and has worked with Web Storage APIs for nearly his entire career.
.svg)
.svg)
.svg)