4 ms·

As much as I also wish we could have a full SQL engine in browsers, it's just too much work. The web as a platform thrives on multiple implementations, even go

As much as I also wish we could have a full SQL engine in browsers, it's just too much work. The web as a platform thrives on multiple implementations, even going so far as to require it for new standards in many areas. All implementations of WebSQL were basically a lightly wrapped SQLite, and that meant that a bug in SQLite was a bug in all browsers, and design decisions in SQLite would impact the entire web ecosystem, and that was consitered by many involved to be a bad tradeoff. IndexedDB is much simpler to spec out, much simpler to build multiple implementations of, and much simpler to maintain and improve over time. In a way it's punting the problem down to userland, but userland doesn't need to abide by the same rules and restrictions as a blessed standard does, so it makes sense to push more complexity down to that level. 400kb is a lot to pay, but it just goes to show how complex an SQL engine really is. Paying for that in the form of a JS bundle download is one thing, but having that complexity in every browser means a larger attack surface, larger maintenance surface, and at the end of the day still doesn't completely remove the need for things like AlaSQL.js (which may target a different implementation than WebSQL)

vandorjw 8y ago
I think it is too bad. Almost all browsers except for Firefox use Chromium (blink) as their browser engine. That means that a bug in Chromium is a bug in almost all browsers, and design decisions in Chromium impact the entire web ecosystem. I agree with your above comment, and we can argue that working on a single web-engine might lead to less duplicated work for Front-End devs, and less bugs in the web overall. Given that sqlite is the most widely deployed DB already, making it part of web browsers doesn't seem like a huge deal to me. https://www.sqlite.org/mostdeployed.html https://www.sqlite.org/mostdeployed.html
- Klathmon 8y ago
  But the bug aspect is only one part of it, the other is that it ties the future goals of the projects together. What happens when the web wants to implement some special optimization or security addition but SQLite doesn't want or support being used that way? What happens when SQLite makes a breaking change in a future version that might make sense for them, but would break a large number of web apps? Once something is in the web standards, it's VERY hard to drop support for it. SQLite might make sense now, but what about in a decade? No matter how you slice it, WebSQL has the ability to become a massive maintence liability, one that all major browsers agreed was too significant to codify into a standard.
  - judge2020 8y ago
    The user seems to be complaining more against Chromium's dominance and not about SQLite being left out of the web ecosystem. You can replace every mention of "SQLite" in your comment with Chrome (or Google) and suddenly you're agreeing with the comment instead of expressing your opinion against it. Chrome currently dominates web standards, and other browsers must keep up or risk losing even more market share to Chrome.
    - Klathmon 8y ago
      But that's not exactly something that Chromium or the web standards bodies can change... (well, Chrome might be able to, but i'm not so sure it would be beneficial) Many web standardization systems already require multiple implementations of a feature before it can become "standard", and by that nature some will have to implement it first. Chrome has Google behind it, and they have a lot of money and a good reason to spend it here (the better the web is as a platform, the better their company which is based on the web works). But there are plenty of examples of where Chrome's "dominance" didn't allow them to just unilaterally push through APIs or platform changes. PNaCl failed and we got WebAssembly which is much better. The original version of ShadowDOM was shot down and it left Chrome behind other browsers when it came to the true implementation. HTML Imports were again something chrome implemented first and is currently being removed due to it ultimately not working out well and the platform as a whole moving in a different direction. Hell most of the WebComponents spec was changed or removed before it started getting in other browsers in a major way. Sure, Chrome could just stop improvements altogether, but that seems like a poor solution. One thing I'd love to see from Google is for them to pull their (in)famous move of eating their own lunch. I'd love to see them pull a Servo and try to spend the time and money creating a new rendering engine from scratch to compete with their own Blink engine.
- idbehold 8y ago
  Don't forget that all iOS devices use WebKit. Even Chrome and Firefox on iOS are using WebKit under the hood.
- da_chicken 8y ago
  > Almost all browsers except for Firefox use Chromium (blink) as their browser engine. Edge and Opera have only a fraction of the Firefox, IE, and Safari usage, so I'm not entirely sure why you're phrasing things this way.
untog 8y ago
> IndexedDB is much simpler to spec out, much simpler to build multiple implementations of, and much simpler to maintain and improve over time. Agreed. It's not easier to use though - almost everyone ends up bundling 10s of KBs of code just to wrap around it and make it useful. That doesn't seem great to me.
- Klathmon 8y ago
  I completely agree, IndexedDB sucks to use on it's own. But that is the direction most web-platform APIs are going, and if I'm being honest, it's working out pretty well for most people involved. Using bare IndexedDB sucks, but it's flexible enough to support a pretty wide range of needs. Using bare Fetch sucks in some cases (it's a hell of a lot easier than xmlhttprequest!), but most people create small wrappers in their applications to do things like add headers, auth information, and simplify JSON parsing and error handling. Using bare canvas APIs sucks, but with a small wrapper allows pretty powerful abstractions with very little code. It has the unfortunate side effect of a lot of code written and shipped to users to simplify APIs and make common use cases easier, but if that downside allows the APIs to be as flexible and powerful as they are, then I'm personally all for it.
tracker1 8y ago
SQLite is already likely the most widely distributed software library in the world. It's in most browsers, it's in both major mobile platforms. It's in cars, planes, boats, trains, and probably in more than one software on your desktop, if not your desktop OS/platform itself. It's also one of the most thoroughly tested libraries on the planet. In any case, I would rather have the W3C, etc. just setting on a minimal SQLite version implementation as a baseline. Or, similar to JS spec now follow with the minimal active version in major browsers. MS IE/Edge was the main holdout, and they're going with Blink (Chrome) based builds now. As to AlaSQL, I'm curious how it compares to an emscripten build of SQLite.
lucideer 8y ago
> it's just too much work. Creating two+ independent implementations before allowing the spec to be adopted may be too much work, but the same would be true of HTML5 or modern DOM specs to implement from scratch today. Fighting to ensure that there are multiple implementations of standards is a noble goal (incidentally, a fight we're in dire need of for HTML/DOM), but expecting these implementations to materialise fully formed for new standards is a severely limiting requirement. Without that requirement, supporting WebSQL would be less work for browser makers and web developers alike. Who knows, competing implementations might even have followed down the line had the spec. been adopted.
- Klathmon 8y ago
  But that requirement is the only thing that keeps one browser engine from being able to run FAR ahead and take over the standards process. Without that requirement, PNaCL would be the standard not WebAssembly, without that requirement ShadowDOM would be Chrome's version and not the version that most browsers are implementing now and which most people agree is better. It's not just a philosophical goal, but one that has time and time again found issues with proposed standards and prevented them from being included. It may keep some things out of the standards which should be in it, but it also keeps a LOT of mistakes out as well.

vandorjw 8y ago

I think it is too bad. Almost all browsers except for Firefox use Chromium (blink) as their browser engine. That means that a bug in Chromium is a bug in almost all browsers, and design decisions in Chromium impact the entire web ecosystem. I agree with your above comment, and we can argue that working on a single web-engine might lead to less duplicated work for Front-End devs, and less bugs in the web overall. Given that sqlite is the most widely deployed DB already, making it part of web browsers doesn't seem like a huge deal to me. https://www.sqlite.org/mostdeployed.html https://www.sqlite.org/mostdeployed.html

Klathmon 8y ago
But the bug aspect is only one part of it, the other is that it ties the future goals of the projects together. What happens when the web wants to implement some special optimization or security addition but SQLite doesn't want or support being used that way? What happens when SQLite makes a breaking change in a future version that might make sense for them, but would break a large number of web apps? Once something is in the web standards, it's VERY hard to drop support for it. SQLite might make sense now, but what about in a decade? No matter how you slice it, WebSQL has the ability to become a massive maintence liability, one that all major browsers agreed was too significant to codify into a standard.
- judge2020 8y ago
  The user seems to be complaining more against Chromium's dominance and not about SQLite being left out of the web ecosystem. You can replace every mention of "SQLite" in your comment with Chrome (or Google) and suddenly you're agreeing with the comment instead of expressing your opinion against it. Chrome currently dominates web standards, and other browsers must keep up or risk losing even more market share to Chrome.
  - Klathmon 8y ago
    But that's not exactly something that Chromium or the web standards bodies can change... (well, Chrome might be able to, but i'm not so sure it would be beneficial) Many web standardization systems already require multiple implementations of a feature before it can become "standard", and by that nature some will have to implement it first. Chrome has Google behind it, and they have a lot of money and a good reason to spend it here (the better the web is as a platform, the better their company which is based on the web works). But there are plenty of examples of where Chrome's "dominance" didn't allow them to just unilaterally push through APIs or platform changes. PNaCl failed and we got WebAssembly which is much better. The original version of ShadowDOM was shot down and it left Chrome behind other browsers when it came to the true implementation. HTML Imports were again something chrome implemented first and is currently being removed due to it ultimately not working out well and the platform as a whole moving in a different direction. Hell most of the WebComponents spec was changed or removed before it started getting in other browsers in a major way. Sure, Chrome could just stop improvements altogether, but that seems like a poor solution. One thing I'd love to see from Google is for them to pull their (in)famous move of eating their own lunch. I'd love to see them pull a Servo and try to spend the time and money creating a new rendering engine from scratch to compete with their own Blink engine.
idbehold 8y ago
Don't forget that all iOS devices use WebKit. Even Chrome and Firefox on iOS are using WebKit under the hood.
da_chicken 8y ago
> Almost all browsers except for Firefox use Chromium (blink) as their browser engine. Edge and Opera have only a fraction of the Firefox, IE, and Safari usage, so I'm not entirely sure why you're phrasing things this way.

untog 8y ago

> IndexedDB is much simpler to spec out, much simpler to build multiple implementations of, and much simpler to maintain and improve over time. Agreed. It's not easier to use though - almost everyone ends up bundling 10s of KBs of code just to wrap around it and make it useful. That doesn't seem great to me.

Klathmon 8y ago
I completely agree, IndexedDB sucks to use on it's own. But that is the direction most web-platform APIs are going, and if I'm being honest, it's working out pretty well for most people involved. Using bare IndexedDB sucks, but it's flexible enough to support a pretty wide range of needs. Using bare Fetch sucks in some cases (it's a hell of a lot easier than xmlhttprequest!), but most people create small wrappers in their applications to do things like add headers, auth information, and simplify JSON parsing and error handling. Using bare canvas APIs sucks, but with a small wrapper allows pretty powerful abstractions with very little code. It has the unfortunate side effect of a lot of code written and shipped to users to simplify APIs and make common use cases easier, but if that downside allows the APIs to be as flexible and powerful as they are, then I'm personally all for it.

tracker1 8y ago

SQLite is already likely the most widely distributed software library in the world. It's in most browsers, it's in both major mobile platforms. It's in cars, planes, boats, trains, and probably in more than one software on your desktop, if not your desktop OS/platform itself. It's also one of the most thoroughly tested libraries on the planet. In any case, I would rather have the W3C, etc. just setting on a minimal SQLite version implementation as a baseline. Or, similar to JS spec now follow with the minimal active version in major browsers. MS IE/Edge was the main holdout, and they're going with Blink (Chrome) based builds now. As to AlaSQL, I'm curious how it compares to an emscripten build of SQLite.

lucideer 8y ago

> it's just too much work. Creating two+ independent implementations before allowing the spec to be adopted may be too much work, but the same would be true of HTML5 or modern DOM specs to implement from scratch today. Fighting to ensure that there are multiple implementations of standards is a noble goal (incidentally, a fight we're in dire need of for HTML/DOM), but expecting these implementations to materialise fully formed for new standards is a severely limiting requirement. Without that requirement, supporting WebSQL would be less work for browser makers and web developers alike. Who knows, competing implementations might even have followed down the line had the spec. been adopted.

Klathmon 8y ago
But that requirement is the only thing that keeps one browser engine from being able to run FAR ahead and take over the standards process. Without that requirement, PNaCL would be the standard not WebAssembly, without that requirement ShadowDOM would be Chrome's version and not the version that most browsers are implementing now and which most people agree is better. It's not just a philosophical goal, but one that has time and time again found issues with proposed standards and prevented them from being included. It may keep some things out of the standards which should be in it, but it also keeps a LOT of mistakes out as well.