Intent to Deprecate and Remove: WebSQL in third-party contexts.ChromeStatus entry: Deprecate and remove WebSQL in non-secure contexts.ChromeStatus entry: Deprecate and remove WebSQL in third-party contexts.All deprecations and removals in Chromium.Membership in this group is open to anyone, and anyone is allowed to post. If you have any concerns about the deprecation steps communicated in this post, please let us know on the blink-dev mailing list. Additionally, Nolan Lawson's blog post provides a good overview of what happened. For some more history, check out the W3C Web Applications Working Group minutes (and, if you really want to go into the details, read the IRC logs) and the mailing list archives). You can read about Mozilla's concerns in former Mozillan Vladimir Vukićević's blog post. Additionally, we don't want changes to SQLite to affect the web later, and don't think harnessing major browser releases (and a web standard) to SQLite is prudent." "We don't think is the right basis for an API exposed to general web content, not least of all because there isn't a credible, widely accepted standard that subsets SQL in a useful way. If you were to run this code and inspect the created table with Chrome DevTools, this is the result: # Lack of implementer supportĪpart from the arcane API shape (at least from today's point of view), Mozilla had many concerns about Web SQL being built upon SQLite: log ( 'Transaction failed!: ' + err ) Ĭonsole. 'select * from rainstorms where mood = ?' ,Ĭonsole. 'create table rainstorms (mood text, severity int)' , As you can see, the SQL statements (using the SQLite SQL dialect) are passed as strings to the database methods. Being a child of the late 2000s, it's a great example of "callback hell", as the code sample ( courtesy of Nolan Lawson) below impressively demonstrates. Web SQL also is an API that shows its age. This comes in direct conflict with Web SQL's requirement of behaving exactly as SQLite 3.6.19. The need to keep up with security and stability fixes dictates updating SQLite in Chromium. SQLite was not initially designed to run malicious SQL statements, yet implementing Web SQL means browsers have to do exactly this. The last version of the standard literally states "User agents must implement the SQL dialect supported by Sqlite 3.6.19". The Web SQL specification cannot be implemented sustainably, which limits innovation and new functionality. # Reasons for deprecating Web SQL # Sustainability and security concerns What's more, we're hoping that this example will help a new ecosystem of open-source databases to flourish! The release of file system access handles finally provides the new primitive on which custom storage solutions can be built. Our objective really is to let developers bring their own database to the web. In fact, we're planning to replace it with something that will be maintained by the open-source community, served as a package that can be updated at will-without the burden of introducing fixes and new features directly into browsers. We're not planning to just remove Web SQL. Based on these creations, we feel that the developer community can iterate on and create new storage solutions faster and better than browser vendors. One example is DuckDB-Wasm, another is absurd-sql. With the advent of Wasm, SQL or NoSQL solutions can come to the web. # Rationale for leaving storage to web developers The article will be updated once the replacement is ready. For developers looking for a drop-in replacement, we're investigating if a shim script can be provided. We're therefore working with the SQLite community on a replacement for Web SQL based on SQLite implemented in WebAssembly (Wasm), which will be released in the near future.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |