IndexedDB is an emerging web standard for storing large amounts of structured data in a browser and performing high-performance data search using indexing. Mozilla has made a significant
technical contribution to this specification, and we plan to implement it in Firefox 4
(supported in FF RC4 - approx. Lane) . We communicated with well-known web developers to implement an elegant API for storing structured data on the web. Safari, Chrome and Opera support the
Web SQL Database technology, which uses
SQL queries that are passed as string arguments to the JavaScript API; it seems to us that the aesthetic component of the development also deserves attention, and such a solution is not very elegant for client web applications. We conveyed the opinion of the developers to
the IndexedDB specification editor , and
talked to Microsoft , which noted that
IndexedDB would not be a bad decision for the web. With the
implementations from the Chrome team looming on the horizon, it seems necessary to us to explain our choice of architecture and why it seems to us that
IndexedDB is a better solution for the web than Web SQL Database.
Web applications can already take advantage of
localStorage and sessionStorage , supported by IE 8+, Safari 4+, Chrome 4+, Opera 10.5 and Firefox 2+, to store key-value pairs using a simple JavaScript interface.
The Web Storage standard (which includes localStorage and sessionStorage) is already implemented and is very good for storing small amounts of data, but not good for storing large amounts of structured data. Although many server-side databases use SQL to work with structured data, its use on the client in the JavaScript API is questionable.
SQL? Which is SQL?
Most web developers are familiar with SQL, because they have to work both with the client (JavaScript, CSS, markup, etc.) and with the server part (for example, PHP and database manipulations). However, despite the ubiquitous use of SQL, there is no single standard that defines SQL technology. Specifically, the
SQLite , on which the WebDatabase API is based, supports most of
SQL-92 , but with noticeable gaps. But SQLite is not a specification, it is a technology ready for launch! And the only document from which you can understand which part of SQL supports SQLite is the
SQLite manual . To make a Web SQL Database right, you need to start by determining which part of SQL is important for web development. Why drag a completely different language if there are more elegant ways in JavaScript anyway?
')
Benefits and pitfalls in SQLite
SQLite seems to us a very useful technology for applications, and we have made it available for
Firefox extensions and trusted code . But we do not think that it is correct to extend this API to all web content, not least because there is no clear, widely applicable standard that describes the required SQL subset. In addition, we do not want changes in SQLite to affect the web in the future, and consider it unwise to connect most browsers with SQLite. IndexedDB is free from this problem; and even if we implement IndexedDB on SQLite technologies, developers will be isolated from changes to SQLite, because the interface used will not be based on SQLite syntax.
Aesthetics and web developers
Last year
(2009 - approx. Lane) we held a summit on storage on the web at Mozilla. We asked the web developers to tell us how they would like to see the structured data storage interface for the web. Many said they support the SQLite API, because they experimented with Web SQL Database in several browsers, and something that works is better than a set of ideas. Nevertheless, everyone expressed enthusiasm for what would be nice to have the best architectural choice and how a simpler model would make their lives easier for them. After we observed how the developers described the simplest interface for the
B-tree , which they claimed would completely satisfy the needs of their applications; this made us think about other schemes. It became clear to us that in using strings describing SQL commands, there is little elegance in native JavaScript, and they began to look for alternatives. Together with Microsoft, we sent suggestions on IndexedDB and were involved in the standardization process as active participants.
In another article, we
compared IndexedDB with the Web SQL Database , and demonstrated that the former has greater semantic simplicity. IndexedDB allows third-party JavaScript libraries to ignore basic primitives using a bi-tree interface, and we hopefully watch projects like
BrowserCouch built on the basis of IndexedDB. The bravest web developers using IndexedDB can even build an interface for SQL. It was wrong to first create a SQL-based API for working in a browser, but such interfaces can be well implemented based on IndexedDB.
From the translator:
I was faced with (not yet full length, but this is a matter of time) two tasks: to reduce the number of client requests to the server and use the competencies of web development in building desktop applications that do not need to be constantly connected, but only occasional synchronization.
Starting a search for technologies that could help me with these issues, I came across the terms IndexedDB and Web SQL Database. It was then that I wondered: why did Mozilla go its own way?
Because I am at the very beginning of the search for a solution, I think this is only the first article from the cycle, both translations and copyright, in which these technologies will be described and compared.
I hope for detailed comments that will be able to direct me to the right path, and I will pay back with a description of the solutions and their comparison.