3 ms·

Right, but the problems Safari has on mobile aren't going to be fixed by implementing IndexedDB; and honestly the WebSQL vs IndexedDB argument is irrelevant to

by exelius 11y ago

Right, but the problems Safari has on mobile aren't going to be fixed by implementing IndexedDB; and honestly the WebSQL vs IndexedDB argument is irrelevant to most people: 95% of web developers will just use a framework that abstracts the differences. And I wouldn't claim that mobile Chrome is a whole lot better on this front, even (or especially) on Android. The limitations of mobile CPUs combined with higher user expectations on responsiveness mean you have to pull the plug on a runaway process a lot faster than on a PC, and neither Apple nor Google is immune to this.

streptomycin 11y ago
Have fun abstracting the difference between a relational database and a NoSQL database! That will only work for trivial applications.
- dragonwriter 11y ago
  There are already abstractions that work over both and work for nontrivial apps, including, IIRC, an indexedDB polyfill using WebSQL. Going the other way might be harder, but every rdbms is, itself, an abstraction over a nonrelational storage system of some kind, so it's clearly not impossible.
  - streptomycin 11y ago
    The IndexedDB polyfills over WebSQL are horribly slow and buggy. You'd be hard pressed to do something non-trivial with them. Believe me, I've tried. Still better than using Safari's IndexedDB though!
criley2 11y ago
Chrome on Android works great and experiences literally zero of the issues mentioned for Safari. Chrome for Android is an app, not a system component, and does not require Android point releases to be updated. It is frequently updated on a regular schedule by Google and pushed out to devices. Using sources like www.caniuse.com, I frequently find that Safari/iOS does not support a feature that is supported on Android browsers and desktop browsers. When designing responsive in 2015, I limit myself to Safari/iOS, the worst browser I build for, then quickly and effortlessly make sure all other browsers work. That's my reality, Safari/iOS is the worst platform to develop for for me. I can't even remember the last time Chrome/Android had any issues that weren't also present on Chrome/Firefox/Desktop. Safari iOS though, even with CSS Resets, even with custom CSS, always finds a way to be non-standard with text size, or font weight with bold, or some "feature" that breaks Safari and nothing else.
- LoSboccacc 11y ago
  this. and don't get me started with the whole mess that happens if you dare to use a css transform on a positioned element, which works kind of differently according to every browser already, but is completely different than every other on safari/ios
- disusered 11y ago
  https://developer.android.com/about/dashboards/index.html?utm_source=suzunone https://developer.android.com/about/dashboards/index.html?ut... What about the other 50% of Android users that don't have Chrome or Chrome WebView? I've been working mobile for a few years now and would love to drop anything before KitKat, but that's not something feasible given market share. In practice, pre 4.4 embedded WebViews have worse support for standards than Mobile Safari. Chrome for Android was in part a system component in order to replace 4.4's embedded WebView, only until 5.0+ did it become decoupled.[1] Google's evergreen approach reduces fragmentation of a core API and it's been a godsend. I know in the future, Safari will be left alone as a pain point. Just don't misrepresent the present situation, where older Android has worse standards support than Mobile Safari and can't even be debugged in devtools. [1] https://developer.chrome.com/multidevice/webview/overview https://developer.chrome.com/multidevice/webview/overview
  - lotharbot 11y ago
    > "pre 4.4 embedded WebViews have worse support for standards than Mobile Safari" My old Windows XP box also has worse support for standards than Mobile Safari. OK, so XP also doesn't have market share. But it's hard to blame older versions of Android for not supporting standards that didn't exist when they were implemented, just because people continue to buy low-end devices running those old versions.
    - exelius 11y ago
      Right, but at the same time you can't say that Safari is the only thing holding mobile web development back. Because dropping users on "old" versions of Android isn't an option from a business standpoint, Safari isn't the only thing holding people back. And 4.4 really isn't that old; so there are tons of users on older devices.

by exelius 11y ago

streptomycin 11y ago

Have fun abstracting the difference between a relational database and a NoSQL database! That will only work for trivial applications.

dragonwriter 11y ago
There are already abstractions that work over both and work for nontrivial apps, including, IIRC, an indexedDB polyfill using WebSQL. Going the other way might be harder, but every rdbms is, itself, an abstraction over a nonrelational storage system of some kind, so it's clearly not impossible.
- streptomycin 11y ago
  The IndexedDB polyfills over WebSQL are horribly slow and buggy. You'd be hard pressed to do something non-trivial with them. Believe me, I've tried. Still better than using Safari's IndexedDB though!

criley2 11y ago

Chrome on Android works great and experiences literally zero of the issues mentioned for Safari. Chrome for Android is an app, not a system component, and does not require Android point releases to be updated. It is frequently updated on a regular schedule by Google and pushed out to devices. Using sources like www.caniuse.com, I frequently find that Safari/iOS does not support a feature that is supported on Android browsers and desktop browsers. When designing responsive in 2015, I limit myself to Safari/iOS, the worst browser I build for, then quickly and effortlessly make sure all other browsers work. That's my reality, Safari/iOS is the worst platform to develop for for me. I can't even remember the last time Chrome/Android had any issues that weren't also present on Chrome/Firefox/Desktop. Safari iOS though, even with CSS Resets, even with custom CSS, always finds a way to be non-standard with text size, or font weight with bold, or some "feature" that breaks Safari and nothing else.

LoSboccacc 11y ago
this. and don't get me started with the whole mess that happens if you dare to use a css transform on a positioned element, which works kind of differently according to every browser already, but is completely different than every other on safari/ios
disusered 11y ago
https://developer.android.com/about/dashboards/index.html?utm_source=suzunone https://developer.android.com/about/dashboards/index.html?ut... What about the other 50% of Android users that don't have Chrome or Chrome WebView? I've been working mobile for a few years now and would love to drop anything before KitKat, but that's not something feasible given market share. In practice, pre 4.4 embedded WebViews have worse support for standards than Mobile Safari. Chrome for Android was in part a system component in order to replace 4.4's embedded WebView, only until 5.0+ did it become decoupled.[1] Google's evergreen approach reduces fragmentation of a core API and it's been a godsend. I know in the future, Safari will be left alone as a pain point. Just don't misrepresent the present situation, where older Android has worse standards support than Mobile Safari and can't even be debugged in devtools. [1] https://developer.chrome.com/multidevice/webview/overview https://developer.chrome.com/multidevice/webview/overview
- lotharbot 11y ago
  > "pre 4.4 embedded WebViews have worse support for standards than Mobile Safari" My old Windows XP box also has worse support for standards than Mobile Safari. OK, so XP also doesn't have market share. But it's hard to blame older versions of Android for not supporting standards that didn't exist when they were implemented, just because people continue to buy low-end devices running those old versions.
  - exelius 11y ago
    Right, but at the same time you can't say that Safari is the only thing holding mobile web development back. Because dropping users on "old" versions of Android isn't an option from a business standpoint, Safari isn't the only thing holding people back. And 4.4 really isn't that old; so there are tons of users on older devices.