Hacker News new | past | comments | ask | show | jobs | submit login
IndexedDB is completely broken in latest Safari (twitter.com/feross)
255 points by feross 7 months ago | hide | past | favorite | 231 comments



OP here. This issue broke the website we've been building: https://wormhole.app

The vast majority of the time we spend diagnosing and working around browser bugs is devoted to Safari. As an iPhone/Mac user and lover of all things Web, I really, really want Apple to get their act together with Safari. We sadly keep running into issues like this.

Here are a few more recent examples:

https://twitter.com/feross/status/1386835131780931587

https://twitter.com/feross/status/1392671684419735552

https://twitter.com/feross/status/1263544033135038464


I've been facing bugs and non standard Safari behaviors for years.

I've been reporting bugs to WK for years and none have been solved.

Did you know you can't set the dimensions of an iframe in iOS?


Oh man. I have spent 100s of man hours on indexeddb on safari issues. Feel your pain!


Safari is the red-headed stepchild of browsers. The dev tools are weird and different, the bugs are obscure and it's pretty much impossible to do anything on it. I love browser diversity but I wouldn't be sad to see it go away.


You could always port the whole thing over to WASM and run it as a spooky blob of code!


WASM still needs IndexedDB (or other storage) to store data in the browser.


You could serialize the DB in localstorage as yet another mysterious blob of data!

But yeah that's not a good idea, really.


What do you need IndexedDB for?


Wormhole.app uses peer-to-peer transfer to send your files directly from your browser to the recipient, in addition to using cloud hosting.

We use WebTorrent behind-the-scenes, so we need random access to the end-to-end encrypted version of the files to satisfy requests from peers. So we try to put the files on disk using Filesystem Access API or IndexedDB, falling back to in-memory if there's not enough storage.


In-browser long-term storage.


Yeah, but of what? Caching the downloaded file? I wouldn’t think encrypted file links would need long term storage of anything. You receive the link, key exchange is derived from key in link, file is downloaded and decrypted on-the-fly.


> Yeah, but of what?

As far as I understand Google's recommendation for web developers, of anything [0]. Their position is, avoid localStorage because it's synchronous, use indexedDB because it's asynchronous. So anything you would use localStorage for, Google suggests putting into indexedDB instead.

I don't remember whether the browser API was expected to get AsyncLocalStorage like the Node API has, or whether that would change Google's recommendations for developers.

[0] - https://web.dev/storage-for-the-web/


GP’s point is that at first blush it doesn’t seem like the Wormhole app should need any local storage in the first place.


Easy, stop supporting Safari. No-one cares when IE support is dropped (people usually cheer for this) and user needs to download and install another browser. So, stop supporting Safari and concentrate on Chrome (I use Firefox but their market share is even smaller so who cares). If enough people show they don't support Safari, THEN Apple will listen. If you keep complaining about having to support Safari then why would Apple care? Not only are you doing all the work for free, you are paying them money for their devices and software.


Any browser on iOS must use safari browser engine (otherwise won't be approved in app store) - the same issue will arise while using Chrome or Firefox on iPhone. Unless you can afford not support iOS/iPadOS users, devs have not choice but complain about bugs.


> Any browser on iOS must use safari browser engine (otherwise won't be approved in app store)

How can they get away with this? That's like 10 times worse than what Microsoft was doing with ie in 00s and they got fined over it so many times.


There's a story about Apple abusing their power and being worse than 90s Microsoft on the front page every other day. The big problem is that there's a lot of cultish defense of Apple and as the victims are software developers and the software industry in general there's not as much visibility to the public as there otherwise would be. Thankfully a lot of the anti-trust action happening right now is focused on Apple so maybe government will help protect the software industry from Apple.


Mostly because iOS isn’t the market leader (and they don’t want to be).


In the US they are the market leader in both profit and volume [0].

[0] https://gs.statcounter.com/os-market-share/mobile/united-sta...


Not Safari per se. All App Store browsers must use Safari’s engine, WebKit.


Because this is a bit technical and regulators are not aware of it and its tremendous implications.

Hopefully the anti-trust investigations in the US, the EU and other parts of the world will change that...


The "tremendous implication" is that it forces developers to test on two browsers (mobile Safari, Chrome) rather than just one. It's the only reason Google is just mostly, rather than entirely, dictating the direction of the Web.


This thread exists because Apple didn't have a single test that creates an indexdb (or releases to users with broken tests) breaking the web and already developed sites.

So foisting the blame on webdevs by calling them lazy feels a bit out of place.

Apple has underinvested in Safari for years. It is clear that they have no intention in setting the direction for the web.


I think it would be bad if Chrome became the only browser worth supporting, as disappointing as it is that Safari has these problems.


Chrome 69.28%

Edge 7.75%

Firefox 7.48%

Internet Explorer 5.21%

Safari 3.71 %

Why would Safari be the one that's important and not firefox?

And why would it mean that Apple gets to be an asshole about it?


Mobile Safari. If a company officially tests on two browsers, it's Chrome and Mobile Safari, unless they're involved with some place still on old version of IE or something.

Mobile Safari matters because that's where the money is.


Firefox is important too (I use Firefox on desktop and Safari on iPhones), but Safari has a much higher percentage of mobile traffic (20% iirc). Edge is re-skinned Chrome these days.

As for why Apple gets to be an “asshole,” there’s no specific privilege granted, inconsistencies are just the nature of the web platform. They probably don’t devote enough resources to minimizing them, but that’s tangential.


Chrome has other issues once in a while as well. Ironically, they broke IndexedDB in 2018 when a device had less than 1 GB of available space (which happened surprisingly often in 2018 on Android).

A few months ago, Chrome broke all WebView-based apps. Fortunately, they fixed it within a day. The IndexedDb bug was fixed after 6 weeks.


The difference is Apple doesn't care about reported WK bugs.

I reported a bug in 2016 and it's still open.

Another bug I reported in early 2020 doesn't even have an answer from the team.


On iOS you don't have a choice other than Safari (other browsers are just wrappers around safari die to Apple policies). And most of us can't afford to drop iOS support (and most of us aren't even in the position to make that call).


The thing is, Apple WANTS us all to stop supporting Safari. It doesn’t help them make money to keep maintaining and extending WebKit to compete with the other browsers. Their (shareholders’) goal is to get more app purchases. I think the only realizable solution is something like antitrust litigation or class action lawsuit to allow web browser competition on iOS, allowing Firefox and Chrome to outcompete Safari. Then we can all drop support and give them the middle finger like IE


I agree that there seems to be no incentive for Apple to keep Safari up to date with features that make native-like web apps possible.

I suppose if they feel like they are big enough to bully websites into just working around long standing bugs, that may be intentional as well.


Yes, make Chrome the next IE. I wonder whther things that "do not work on Safari" are alredy Chrome specific.


On the market-strangling side, Chrome is already the next IE6. On the stuck-in-the-past-and-always-broken side, Safari is the next IE6.


I wrote up the bug report for this a couple of weeks ago when iOS 14.6 first rolled out. iOS 14.6 at least did finally fix using HLS streams in gl.texUpload2D() on iPhone 12 series (which was broken since launch) but this new bug did mean our delight at that fact was somewhat short-lived!

Well done on your viral tweet that got some personal attention from Apple. Usually when I spend days narrowing down Safari bugs to minimal reproducible test cases, finding workarounds, and writing everything up in detail on the webkit bug tracker the only public response from Apple is the radar importer bot, and then everything goes quiet.

Btw, your original twitter thread implies you were the author of the bug report. Minor annoyance, but I did spend quite a while writing that up :)


Chrome 91 on Android also managed to break WebAssembly memory growth which affects our sites too, so it's been a rough couple of weeks working around browser bugs for us. https://bugs.chromium.org/p/v8/issues/detail?id=11863

I find the Chromium team much more willing to engage directly and constructively on their bug trackers at least.


I also encountered this problem, can you please tell me how you solved it on Chrome 91 version?


I’ve been shocked at the number of show-stopper bugs shipping in Safari recently so I’m doing what I can to draw attention to it. I hope it helps the Safari team get the resources they need from the big wigs at Apple.

Also: Didn’t mean to imply I wrote that report. We were about to open a duplicate issue before noticing yours. Thanks!


No worries, I imagine many teams have been through the same process over the past couple of weeks!

We've definitely had the same experience of Safari introducing way more issues with new releases than Chrome, and the fact it's part of the iOS image seems to make quick patching just never really an option.

I just wish they'd engage a bit more directly on the bug tracker - find it hard to believe that twitter is a more effective means to get attention on bugs.


I've always been a Linux user, but recently I got a new Macbook Air and wanted to try a non-Chrome browser.

Then I loaded up my 2005-vintage personal wiki which has been working fine for 15 years on all the browsers I use (Chrome and Firefox).

And it has a tabindex bug in Safari!

https://stackoverflow.com/questions/1848390/safari-ignoring-...

I'm not sure but isn't this a violation of the spec? Or is there some newer thing for tabindex? Either way I switched back to Firefox and Chrome.

I kinda like the idea of a browser that doesn't implement all the Chrome crap. But I also feel like it should interpret 15 year old pages correctly!


I'm confused, you said there's a bug but as far as I can tell it's just that Safari disables using "tab" for more than form elements by default.


It might not be a bug in the sense that it's a spec violation, but it's behavior that every other browser I've used for 15 years has.

If this were a commercial product (my wiki), there would be a bug in the tracker for it :) In the link people have given JS workarounds.


> the only public response from Apple is the radar importer bot, and then everything goes quiet

That's been my experience as well.

When reporting a bug to Chromium you get an answer in hours.

When reporting a bug to WebKit it's mostly crickets.


It's a terrible API anyway and if it died I wouldn't shed a tear. If you need a good laugh (or more likely, a heart attack from the blood pressure rise it will induce) have a look at this blog post[1] by Mozilla justifying not using SQLite and choosing to implement the much more "elegant" IndexedDB. That post has too many examples of hubris and delusion for me to bother quoting it here, I'd just be reproducing most of it.

Then you can go to their code comparison page[2] and wonder what the hell they were on about.

> IndexedDB generally simplifies the programming model for interacting with databases, and allows for a wide number of use cases.

They can't be looking at the same code - what have they improved other than to use more Javascript?

The sooner it dies the sooner an alternative can appear… SQLite3, anyone?

[1] https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

[2] https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-we...


I mean I can understand why they dropped websql, as great a project as SQLite is, mandating that browsers expose SQLite is not a spec, and expecting a complete reimplementation of sql by browser developers would be foolish.

But yeah the assertion that indexeddb is any good is hardly convincing.

Nowadays you can use sqlite3 through wasm if you want, though I don’t know how you’d handle the persistence layer.


> Nowadays you can use sqlite3 through wasm if you want, though I don’t know how you’d handle the persistence layer.

There was a post on here in the last month or 2, atleast for reading, that used http range headers for reading the db pages.

as for writing, you're gonna hate this, but a vfs impl. for SQLite using indexedDB as the backing store is your best option (Safari stupidity not withstanding)


> There was a post on here in the last month or 2, atleast for reading, that used http range headers for reading the db pages.

That was for a local SQLite doing remote loads/stores, I was thinking more local loads/stores, what websql would have provided.

> as for writing, you're gonna hate this, but a vfs impl. for SQLite using indexedDB as the backing store is your best option (Safari stupidity not withstanding)

Yeah that’s what I was figuring out but then it feels like the SQLite bits are significantly less useful, and I’m not sure how good indexeddb is at being a block device.


You can still mandate a spec, and if everybody ends up picking SQLite to implement it, so what?


"Just use SQLite, lol" is not a spec.

P.S. SQLite doesn't have a spec. Once you start really using it and bumping into version differences, extensions, etc., you'll really feel the pain caused by this.


Why do you care more about this mythical spec - which clearly is s load of rubbish if IndexedDB is anything to go by - versus a working, powerful technology that is as close to being able to be dropped in quickly as one could hope for?


> working

Not after Google and Apple get their hands on it.


I didn't say that it is. But you could make a spec that is implementable using SQLite.

And no, it's not the same as mandating SQLite.


> But you could make a spec that is implementable using SQLite.

Yes, that would be the smart choice. But alas.


You can try to language-lawyer this as much as you want, but it doesn't matter; Browser developers clearly do not want to just adopt SQL into the browser layer without there being multiple independent implementations, and scoping the problem so that you can act all "whoops, wow, what did I trip over right here? so convenient!" to use SQLite and be done with it, is a tactic they almost certainly can predict and see as a bad one, nearly equivalent to just mandating it in the first place.

Like, does anybody here really think their actual complaints are about some minutae about wording in a spec about "mandates" or whatever? Their rejection is quite clearly against the spirit of the design, and again because because they don't think multiple browsers each independently reproducing a whole SQL stack with equivalent semantics is viable. It's not about technical nits or wordsmithing, little coder-logic-tricks aren't going to work.


> Browser developers clearly do not want to just adopt SQL into the browser layer

Why would they think it’s more viable as a JavaScript spec than a SQL one? It seems to me it’s about retaining control and about giving what some web devs want - JavaScript everywhere.


If you write the spec to be compatible with SQLite and everyone picks that, then you have in essence mandated SQLite and your spec is at the mercy of the project’s decisions.

If you write the spec to not be compatible with SQLite then every browser has to implement its own SQL layer which is a huge effort and frankly a waste because SQL is kinda shit.


SQLite is open source. If it goes away from the direction you want, then fork it. That's still way less effort than implementing a bunch of different IndexedDB variants.


Granted that the DOM event API feels clunky, but I actually think they got things mostly right: - low-level storage primitive with support for indices, "you pay only for what you use". - very fast if used in the right way - very large sizes supported - built-in version support, making it easy to do schema and data migrations. - basic query api that again gives you a lot of flexibility and control over performance - can be abstracted away by higher level libraries like Dexie

I've built a web-app heavily relying on IDB, and storage operations are generally much faster than the native app on Android using Realm DB. IDB is backed by leveldb on Chrome, which in benchmarks is consistently faster than sqlite. I'm happy we didn't end up with websql for one.

My biggest gripes are: - The incompatibility with ES6 promises early on (but IE11 still suffers from) was unfortunate. - The auto-commit behaviour of transactions is somewhat annoying and usually has an impact on your architecture if you want to write multiple things in one transaction, but it would have been easy to have memory leaks and deadlocks without this. - Quota management and eviction is wildly inconsistent between browsers, even on Chrome you get evicted when storage gets critically low. - Safari has a history of pretty bad IDB bugs.


SQLite is amazing. But after having worked with it for many years now, I believe it should never be a platform-level API, and not standardizing it for browsers was the right choice.

SQLite has a _lot_ of great features. Many of them only introduced in recent versions, and many of them are optional extensions enabled at compile-time. There is no feasible way to standardize this to get the same functionality across all browsers.

IndexedDB may not be great to work with (at least not without helper libraries), but at least the API surface is small, and much easier to ensure you get the same behaviour in all browsers.

I'd rather advocate for a proper block-level filesystem API that could be used as backing storage for a WASM SQLite library.


> SQLite is amazing. But after having worked with it for many years now, I believe it should never be a platform-level API, and not standardizing it for browsers was the right choice.

No it was never the right choice and it didn't need to become standardized at first place. Writing a query builder is an easy task, implementing a RDBMS on top of indexedDB, ironically implemented on top of SQlite in Firefoxis a much harder tasks.

IndexedDB is absolutely atrocious API wise, and largely useless to query structured data.


> I'd rather advocate for a proper block-level filesystem API that could be used as backing storage for a WASM SQLite library.

This is happening at https://web.dev/storage-foundation/ fwiw


IndexedDB's ugliness is due to being from a time before ES6+ really kicked into gear and we still had the old crud of weird callback stacks (See FileReader for another example).

As for SQLite, as lovely as that'd be, NOONE wanted to spend R&D on building a "SQLite clone" for the web SQL spec, and I can't blame them, how the hell can you justify that effort when SQLite exists and is crazy well tested and proven?


Have you ever tried to use it on a project? It's been a while for me as I moved to PouchDB or SQLite in WASM and never looked back.

Let's say you need to search for age > 19 and less than 30 for a person with the name of Jane or John.

That's nothing complicated, but indexedDB CANNOT DO THIS. I suppose you could do it by iterating every single data entry, but that's a performance no-go for even relatively trivial databases.

Likewise, joins on different stores simply don't exist. Iterating every entry in this case is O(N^2).

Might as well just store a giant JSON blob instead.

Quite literally, my only use of indexedDB these days is storing a SQLite file and whatever interactions PouchDB has (I think they are mostly limited to linking an ID with a JSON blob). Adding insult to injury, despite being a simple key/val store, it's SLOWER than SQLite too.


> Let's say you need to search for age > 19 and less than 30 for a person with the name of Jane or John.

I’m pretty sure you can do that. You can create an IDBIndex that covers multiple fields, then narrow down the search using key ranges. Though, even with key ranges, narrowing down results based on multiple independent ranges requires some manual work:

https://gist.github.com/inexorabletash/704e9688f99ac12dd336

But at least algorithmically speaking, that’s roughly the same thing that a database natively supporting such queries would be doing, so the big-O performance should be the same. Though I wouldn’t be surprised at all if it’s slower in practice.


WebSQL was what we all wanted. But if I remember right, it couldn't be standardised because the W3C requirement insists that there should be atleast 2 different implementations of it in the clients - however all the browsers that supported it only built it using SQLite (which is a very obvious choice). If atleast one of the browser had built an implementation with a different database backend (like perhaps BerkleyDB), it could have become a web standard and a reality today. Instead, we are stuck with crap like IndexedDB.


If a least one browser had used a different backend, the API behavior would have had to actually be defined instead of just saying "behaves like SQLite". And that defined behavior would have to be implementable on top of both SQLite an the other backend.

All doable, but quite a lot of work. Once you start looking at the details, every single database has its own SQL dialect and they're not all that compatible except for the simplest queries.


That's a shame. So we don't have it for bureaucratic reasons? What was the rationale behind that rule?


> Instead, we are stuck with crap like IndexedDB.

Which is implemented on top of Sqlite in many browsers, what a joke.

It's easier to implement IndexedDB on top of a SQL database than the other way around, so people claiming IndexedDB is "lower level" are ignorant.


IndexedDB does indeed suck, but there's really no alternative to it if you want Safari and Firefox support. Fortunately, in Chrome we have the FileSystem Access API which has a feature that lets you write into an "origin private" store, similar to how IndexedDB partitions storage per origin.

There's even recent work to add even higher performance APIs into the Filesystem Access API and the reception from Firefox and Safari has been positive. Really early work is happening here: https://github.com/WICG/storage-foundation-api-explainer and the latest proposal is here: https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUV...


> There's even recent work to add even higher performance APIs into the Filesystem Access API and the reception from Firefox and Safari has been positive.

Positive as in: "FileSystem Access is a significant security risk and we're not going to implement this"? https://www.chromestatus.com/feature/6284708426022912

Positive as in "No, we don't want fifteen different file access apis, and we don't think Storage Foundation API is going anywhere"? https://www.chromestatus.com/feature/5670244905385984

And even though this is a draft created and authored exclusively by Googlers, even other Googlers are confused: https://github.com/WICG/storage-foundation-api-explainer/iss...


Storage Foundation is being merged with the Origin Private part of the Filesystem Access API specifically to address feedback from Safari and Firefox teams about too many File APIs on the web, and if they only implement the Origin Private part of the spec there’s no more risk than IndexedDB since it doesn’t interact with the real file system.


> Storage Foundation is being merged with the Origin Private part of the Filesystem Access API specifically to address feedback from Safari and Firefox teams about too many File APIs on the web

Good. Still doesn't mean there's positive feedback.

> if they only implement the Origin Private part of the spec there’s no more risk than IndexedDB since it doesn’t interact with the real file system.

If. Or it may go the HID way: https://news.ycombinator.com/item?id=27512354

I wouldn't hold my breath for "positive feedback" on these APIs.


> FileSystem Access is a significant security risk and we're not going to implement this

Right now the Mozilla position is 'defer', not 'harmful'. See https://mozilla.github.io/standards-positions/#native-file-s....

That means yes, they're not implemented today, but they're open to doing so later on, given further specification development and real-world investigation to confirm that the security implications are minimal.

> No, we don't want fifteen different file access apis

Looks like there is some ongoing work to synchronize these APIs to resolve that concern: https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUV...

---

I 100% agree Google is too aggressive at publishing and releasing these features without widespread consensus from other vendors. If they were doing so with just origin trials or behind a flag that would seem reasonable to me, but the widespread release is surely going to cause problems for these specs, when they must be aware that further development and changes is going to be required. I'm not clear how they intend to mature these standards without breaking the early adopters.

I don't agree they're not desirable features though. Honestly I desperately wish Safari & Firefox would engage more and drive these specs themselves! It would be better to get their voices in the decisions that'll define these specs, rather than letting Google define the future of the web all by themselves.

There's clearly demand for these features (read the comments of https://github.com/mozilla/standards-positions/issues/154 for some examples). It would be better to have privacy and security baked in with input from a broad group of actors (I think we can all agree that Firefox is going to be a more useful voice than Google in that sense). It's not helpful to let Google run off and write every standard themselves, with other browsers watching from the sidelines until it's sufficiently done (and unchangeable) and then having to either adopt the existing standard as-is by necessity or to refuse to support many real world web applications (for as long as that's tenable).

Make no mistake - Chromium has the market share to be a workable target, and these APIs work well for developers and are genuinely useful. They will be used. There will be (in some areas there already is) a whole world of web apps using these APIs which only work in Chromium by necessity, no matter how much they'd like to support other browsers. As those get adopted by users, that's only going to drive the web further towards Chromium, until other browsers have to die or adopt the (entirely Google-written) standards themselves too to support the next generation of webapps.

This is happening on desktop in some areas already. In IDEs, for example - if you buy any IoT based on Espruino, the primary dev tool only works in Chrome due to WebUSB/WebBluetooth (https://www.espruino.com/Web+IDE), while tools like Godot Editor are already talking about Chrome-only save/load support using these filesystem APIs (https://godotengine.org/article/godot-editor-running-web-bro...), and I'd be extremely surprised if GitHub Codespaces and other tools aren't looking at doing the same. These are popular tools - many users want to use them, and they will have to switch to a Chromium-based browser to do so.

Mobile is somewhat protected due to Safari being the only option on iPhone, but I wouldn't be surprised if the ongoing antitrust cases force them to open that up to make PWAs look like a plausible app store competitor, and the exact same thing happens there.

WebExtensions is a case study of the same effect in the past. Chromium has so much weight that once they fully design and adopt an API and build an ecosystem around it, other browsers have to follow or get cut off. If Firefox & Safari had engaged with WebExtensions much earlier, they could have been driving it themselves and building consensus. Instead, they've had to copy every Google API while just tweaking around the edges.

One exception, interestingly: Brave is doing some intriguing work on driving decentralization APIs for the web (native Web3, native IPFS). It's early days, but I'm hopeful that this might have the same effect in the opposite direction for those features!


Firefox and Safari do engage early, and they do participate in discussions. GitHub comments are a very small visible part of it.

However, Chrome simply inundates them with APIs. There are 50 to 100 new APIs that Chrome releases with each new version. And a new version comes out once every two months. So, Firefox and Safari have to be "actively engaged in discussions" on 300 to 600 new APIs a year [1].

This is not sustainable in any way, shape, or form. Hell, Microsoft gave up on developing a browser of their own, and they are definitely not lacking in resources. How is Mozilla expected to cope? Safari has decided to set their own pace, and flat out refuse APIs that breach security and privacy, because by this time Chrome teams should really know better (if only they cared).

So, no, it's not true that Mozilla and Safari are "not engaged at an early stage". They are, to the best of their abilities and resources. But they also have browsers to develop, and in the end there are only so many hours in the day.

[1] https://web-confluence.appspot.com/#!/confluence


I hear you, I'm not saying it's easy! Firefox especially desperately needs more funding here (and Apple more competition, on mobile at least).

That said, that API count is referring to individual methods & fields (see https://web-confluence.appspot.com/#!/catalog) not whole specifications. I'm mainly concerned about them reviewing and making contributions to write these specs, rather the work to fully implement them, so that at least they end up with something they might be happy implementing in future.

Either way, if every few months Chrome can genuinely churn out hundreds of APIs that developers genuinely want and use (a big caveat!) and Firefox/Safari can't keep up, then that's game over. Chromium has the market share, people will start using these APIs, serving a relatively worse and worse version for the slower browsers (if they bother), and eventually the older browsers will either have to implement them to according to these defacto standards, design & implement a sufficiently better alternative somehow, or die (for the average user, at least).

Firefox beat IE last time because it took the 2nd option: it had better alternatives to Microsoft's non-standard web technologies (primarily: consistent APIs backed by clear standards and good tools that solved the same problems) and thereby managed to capture web developers and lead the compatibility game, rather than following. I don't see how they can do the same again if they can't propose workable alternatives to new standards other than 'defer' or 'reject'.


> Either way, if every few months Chrome can genuinely churn out hundreds of APIs that developers genuinely want and use (a big caveat!) and Firefox/Safari can't keep up, then that's game over.

It very much is, and has been for a while: Google completely dominates all of web-related standards bodies. And the specs that are rushed to completion in Chrome are more likely than not to be fully authored by Googlers only (sometimes with egregious disregard for standards work, see WebHID [1]).

[1] Issue https://github.com/mozilla/standards-positions/issues/459#is... and timeline https://news.ycombinator.com/item?id=27512354


Ok, if we take this as given then non-Chromium is dead. Yikes. I'm not convinced it's a lost cause yet, but yes it looks like a very plausible future imo.

Assuming that then, if we want healthy web standards then it sounds like the only option is to shut down Firefox et al ASAP (or make it another chromium wrapper) and spend that engineer time & money instead getting involved in these specs and Chromium development to try and provide non-Google input and ideas, and somehow transform Chromium itself into a community endeavour. If there's an inevitable chromium monopoly then that seems like the only choice. Unless something else blocks the chromium monopoly, e.g. Google antitrust of some sort, but that doesn't seem imminent (for Chrome specifically).

A somewhat bleak future, but if this becomes inevitable then that seems like the best option unfortunately.


I think that this may as well be a pendulum: many browsers, IE6 monopoly, many browsers, Chrome monopoly. We may yet swing back to many browsers at some point in the future :)


> That post has too many examples of hubris and delusion for me to bother quoting it here

Well, I could not help myself.

>> While versions of Safari, Chrome, and Opera support a technology called Web SQL Database, which uses SQL statements as string arguments passed to a JavaScript API, we think developer aesthetics are an important consideration, and that this is a particularly inelegant solution for client-side web applications.

>> We .. also spoke with Microsoft, who agree with us that IndexedDB is a good option for the web

OMG!! MS thought not doing what Apple and Google wanted was a good option. Earth shattering.

As for the code examples, both sets look horrible, but this and "_developer aesthetics_" don't go together. This is how they think their `JOIN` is "better" than SQL `JOIN`.

    candyEaters = [];
    function displayCandyEaters(event) {
      var display = document.getElementById("purchaseList");
      for (var i in candyEaters) {
        display.textContent += ", " + candyEaters[i].name + "bought " +
                               candyEaters[i].count + "pieces";
      }
    };

    var request = window.indexedDB.open("CandyDB",
                                        "My candy store database");
    request.onsuccess = function(event) {
      var db = event.result;
      var transaction = db.transaction(["kids", "candySales"]);
      transaction.oncomplete = displayCandyEaters;

      var kidCursor;
      var saleCursor;
      var salesLoaded = false;
      var count;

      var kidsStore = transaction.objectStore("kids");
      kidsStore.openCursor().onsuccess = function(event) {
        kidCursor = event.result;
        count = 0;
        attemptWalk();
      }
      var salesStore = transaction.objectStore("candySales");
      var kidIndex = salesStore.index("kidId");
      kidIndex.openObjectCursor().onsuccess = function(event) {
        saleCursor = event.result;
        salesLoaded = true;
        attemptWalk();
      }
      function attemptWalk() {
        if (!kidCursor || !salesLoaded)
          return;

        if (saleCursor && kidCursor.value.id == saleCursor.kidId) {
          count++;
          saleCursor.continue();
        }
        else {
          candyEaters.push({ name: kidCursor.value.name, count: count });
          kidCursor.continue();
        }
      }
    }


It's terrible, isn't it? Have these people ever used SQL? Doubtful, it they had then they might know the difference between joins and cursors!


I think indexedDb is just too low level for your use case. Because it’s actually very good! This low level primitive allows to implement various approaches on top of it, such as the excellent Dexie.js. You should have a look at it, it made me like indexedDb


Another vote for Dexie, the Typescript support is alright as well.


> Because it’s actually very good!

It's built on top of Sqlite in Firefox, it isn't "low level". Give me Sqlite directly instead of that horrible stuff.


What you say is the equivalent of saying « assembly is higher level than JavaScript because someone implemented a virtual machine that runs assembly code, in JavaScript in the browser ».

Just because someone used this technique for some technical reason does not change the fact that indexedDb is an API, is not built on top of SQLite, and is lower level, because you could build SQL databases on top of it.


This is an implementation detail. The fact is that indexedDB API is lower level than SQL.


> This is an implementation detail. The fact is that indexedDB API is lower level than SQL.

Why do you keep on claiming that? No it is not lower level than SQL. It's trivial to implement IndexedDB on top of of a SQL database. Good luck doing the other way around and that's the whole point of things. SQlite does everything IndexedDB does and more.... indexedDB isn't lower level, it's just more basic and limited. I have yet to see a SQL database equivalent to SQlite implemented on top of IndexedDB.


indexedDb is an API. This API is more primitive and limited than SQL. This API is basically a key value store with indices and transactions. This is what many SQL databases are implemented on top of (Postgres for example).

So yes it is absolutely possible to implement a SQL database on top of indexed DB, and that would be the architecturally logical thing to do.

The fact that Firefox goes the other way around is an implementation detail. What they did is called « emulation »: run a low level interface on top of a higher level one. This technique is very common and does not mean that the abstraction levels of API are suddenly magically reversed. It’s just an implementation detail of the architecture.

You can run NES code in an emulator in JavaScript on the web. Does this make NES assembly higher level than JavaScript ? No.


> indexedDb is an API. This API is more primitive and limited than SQL. This API is basically a key value store with indices and transactions. This is what many SQL databases are implemented on top of (Postgres for example).

SQL isn't an API. It's a language. Something to query a SQL database in the browser would constitute the API (thus WebSQL). You are mixing up language and API here. That's your first mistake.

> So yes it is absolutely possible to implement a SQL database on top of indexed DB, and that would be the architecturally logical thing to do.

And it's trivial to implement indexedDB over Sqlite, in fact, that's what Firefox did.

Where is the other way around? Where are RDBMS implemented on top of indexedDB?

> The fact that Firefox goes the other way around is an implementation detail.

No it isn't. It demonstrates my point entirely, that it is trivial to implement indexedDB on top of Sqlite, which makes Mozilla developers a bunch of hypocrites for not letting developers access an Sql layer directly.


Ok, look, I disagree.

I'll let you try to reconcile yourself about why "Mozilla developers are a bunch of hypocrites". I presented to you a very straightforward explanation that does not imply bad intent from an entire group of people.

I am sorry that this explanation does not fit your world view.

To me, what you say is the equivalent of saying « assembly is higher level than JavaScript because someone implemented a virtual machine that runs assembly code, in JavaScript in the browser ».

Just because someone at Mozilla used this technique for some technical reason (it is indeed often easier to emulate low level stuff on top of high level stuff, rather than the opposite) does not change the fact that IndexedDB is an API, is not built on top of SQLite, and is lower level than any API based SQL.


"Lower level" is a basic software engineering shorthand for minimal abstraction.

https://computersciencewiki.org/index.php/Higher_level_and_l...

IndexedDB builds on top of SQLite, so it's considered "higher-level", not lower level.


Indexeddb is not built on top of SQLite. IndexedDb is an API. This API is more primitive and limited than SQL. This API is basically a key value store with indices and transactions. This is what many SQL databases are implemented on top of (Postgres for example).

So yes it is absolutely possible to implement a SQL database on top of indexed DB, and that would be the architecturally logical thing to do.

The fact that Firefox goes the other way around is an implementation detail. What they did is called « emulation »: run a low level interface on top of a higher level one. This technique is very common and does not mean that the abstraction levels of API are suddenly magically reversed. It’s just an implementation detail of the architecture.

You can run NES code in an emulator in JavaScript on the web. Does this make NES assembly higher level than JavaScript ? No.


I agree with everything you said, and it was the first time I got disappointed by Mozilla. Their excuse was "well we'd have to spec a common SQL and we don't want to do that". No there was no need to spec a common SQL for all browsers, let vendors choose whatever SQL version they want to implement. People have been building query builders for years, it's easy, much easier than re-implementing a RDBMS on top of IndexedDB. Then I learned that Firefox implemented IndexedDB on top of SQlite, what a freaking joke...

It made me really angry at Mozilla. WebSQL was so invaluable to me.


IndexedDB is indeed cancer. Usually it's also unnecessary, as you can store a significant amount of data in localStorage and the API is extremely simple to use.

If you need to store more data, why not do it on the server? What are the use cases for having a full-blown relational db client-side?


> IndexedDB is indeed cancer.

So is PHP according the infallible SV pundits.

> it's also unnecessary, as you can store a significant amount of data in localStorage and the API is extremely simple to use.

Either you've never actually tried to store significant amounts of data in localstorage, or you're from the era of "640k is enough".

To say nothing of having no indexing functionality with localstorage, or paying the 33% base64 tax to put anything remotely binary into it.

> If you need to store more data, why not do it on the server?

"Because there is always, ALWAYS a high speed, low latency 100% uptime connection" /s

In answer to your last question, we have developed two PWAs reliant on local databases.

1. Was a product catalogue for use in stores, letting users filter down to select a particular appliance. two key requirements were that not all stores had great wifi coverage, and they wanted to easily update the catalogue (which meant no app recompilation).

So, Dexie atop IndexedDB, with indexes on the various facets for searching, and a simple settings page to run a sync. Dexie stored the product data, and a "immutable" SW cache strategy was used to keep the images available.

2. A detailed report generation app, Key requirement, must work with patchy connectivity as reports need to be taken in the field with unknown signal availability. Reports are locally stored and synced periodically (connection permitting). Again, Dexie atop IndexedDB, this time the images stored in the db as blobs prior to upload.


> So is PHP according the infallible SV pundits

Sarcasm is unnecessary but I'll admit that so is the word "cancer".

Your first example is a great one, although the catalog would have to be really huge to not fit in memory; and since it is static (the users don't update it) it can be upgraded by downloading a json file regularly?

The second example doesn't explain why you would need a relational db.

Anyway my point is not to second guess applications that run well, and even less to argue with people who have already mastered IndexedDB -- good for them!

My point is for people on the fence to take a good, hard look at what's possible with localStorage and make sure that before they embark on the IndexedDB voyage, they are absolutely, positively certain that they have no other choice.

I recently came across an app that stores a couple of user preferences on IndexedDB; the funny part is that the comments complain for paragraphs about its quirks and general unpleasantness. The time spent complaining in the source would have been better spent switching to localStorage.


> So is PHP according the infallible SV pundits.

Irrelevant, nobody is forced to use PHP as a server side technology. On the other hand, browser API are limited with what browser vendors implement, so there is no choice.


It's surprising how confident you are when you know so little. localStorage and indexedDB are very different in how they store data and read data, you also don't know the advantages both have over storing data on a server without using it as a full blown relational db.


> If you need to store more data, why not do it on the server? What are the use cases for having a full-blown relational db client-side?

Easier / cheaper to host only static files.


Agreed. All my respect for Mozilla went out the window after finding out they were the drivers for getting WebSQL removed as a spec.

I must admit there's a bit of schadenfreude in knowing that Firefox is almost irrelevant now, while SQLite keeps going from strength to strength.


I'm glad people are finally speaking out after all these years. I hated IndexedDB and got lambasted for expressing my views on this very forum. And I also recently just learned that IndexeDB was build on top of Sqlite in Firefox... what a cynical joke...


Apple responded:

> I have identified the regression point and assigned the bug to somebody. Thank you for the bug report. We will try and get this fixed ASAP.


In other words: we may fix this next year. Or the year thereafter. No promises though.


Well most Radars don't get assigned, so this is promising.


Most radars don’t get a public tweet saying ASAP, either!


All Radars get assigned, they just may not be assigned with a reasonable priority to an engineer who will work on it.


I'm keeping a record of all the problems around IndexedDB at https://gist.github.com/pesterhazy/4de96193af89a6dd5ce682ce2...

I just added a section on Safari's storage related bugs, of which there are many. Amazingly, IndexedDB broke in Safari 14.1.1 after localStorage broke in Safari 14.1, released a month earlier.


Yes... I've felt for years now that Safari in particular prioritized UI speed over correctness. They don't seem to care what they have to do to get a buttery UI. It is indeed buttery, much more than any other browser, but at what cost?

Bugs.


When something like this happens, you realize that it's not ust your client or your company that sucks at testing software.


Even if you are amazing at testing software you will still have bugs.

Especially for a browser engine where you have a ridiculous number of testing permutations to cater for.


While I agree with your point, indexeddb being completely broken seems like a major oversight.


> Opening an IndexedDB database fails 100% of the time on the first try.

This is something that should have been caught by automated tests.


Oh man, if you think browsers are well tested automatically, you’re very far off reality.

There’s basically no automated test suite even for CSS 2.1 that all vendors can rely on that matches behavior specified by the standards.

Luckily standards like that are so mature that it’s not needed as badly, but it definitely keeps incumbents safe from competition.


I assume you're aware of the WPT project (contributed to by all of the major browser vendors these days), and its CSS 2.1 coverage is lacking in a way I'm unaware of.

But for others who don't know:

https://web-platform-tests.org/

https://github.com/web-platform-tests/wpt/tree/master/css/CS...


Yes, this is the closest thing we have today, but it is built in such a way that implies you have a fully functioning browser already, which sort of defeats one aspect of the need for such a suite.

They’re also tests that don’t actually point anything out.

Take the CSS2 tests for example, https://wpt.live/css/CSS2/, I can’t do basically anything with these. They don’t tell me whether or not a particular part of the implementation has failed. They’re all basically arbitrary tests that sort of cover the appropriate properties, sometimes, maybe.

The biggest glaring issue is that the test runners run in the browser. Well, if my user agent doesn’t have JavaScript… I can’t “run” the tests.

Further, there are some parts of the standard that can’t be automated simply because it’s up to user agents to decide how the final rasterization turns out. You can’t just compare rasterization output or even reliably look for element heights for verification based on the differences between font rasterization.

This is also why a part of the suite requires manual verification.

What I really need as an implementor is the ability to point my software at some .html files, get some failures, add more implementation, get less failures, and repeat. With, of course, the caveat being that you can only really do this for what is well-defined in the standards.

But you can’t do that easily with the wpts.


Hi, I work on web-platform-tests.

I'm not really sure I follow your complaint, so I wonder if there's a point of misunderstanding. The tests written for DOM APIs certainly require running javascript to execute the test — that's a given — but most of the rendering tests are reftests. These consist of two files, one using the feature under test and one avoiding that feature [1]. The test passes when the two renderings are identical. That does make these tests difficult to run "by hand", but in terms of implementation it's possible to automate in anything that's capable of rendering to an image. Reftests are preferred over comparing rendering to a fixed image because fixed images tend to be invalidated due to unrelated/permitted changes in the rendering (e.g. a different font or different antialiasing choices). These will typically apply to both test and reference and so are handled automatically.

Reftests obviously aren't suitable to bootstrap getting very basic things working, so there are some manual tests; I suppose one could hope to avoid that by inventing a special kind of output inspection automation just for those basic tests, but it's hard to justify.

IN general, however, the "the ability to point my software at some .html files, get some failures, add more implementation, get less failures, and repeat" is exactly what wpt offers. There is some work required to stand up the necessary infrastructure to run the tests automatically, but it's common for new implementations of the platform to make use of web-platform-tests (e.g. Servo and Flow have both made use of wpt).

In terms of coverage it's very difficult to demonstrate that all the requirements of a spec, and all its interactions with other specs, are completely covered. There have been various proposals for adding test metadata to try to measure coverage, but these have largely proved impractical. Nevertheless some CSS specs have links from the spec to the relevant test cases. And if you find cases that aren't covered by exisitng tests it would be great to get a PR to add new tests [2]

[1] https://web-platform-tests.org/writing-tests/reftests.html [2] https://github.com/web-platform-tests/wpt


I’m not sure what you define as “getting very basic things working” but there’s no acceptable threshold for me. Are line boxes very basic? Is overflow compositing very basic? It’s irrelevant whether or not one is bootstrapping.

It is unacceptable to me to use the software I’m testing to test itself if I can’t establish a baseline for the rest of the tests.

Otherwise, all of the tests could be invalid one day based on a regression and I wouldn’t know. But this is explicitly done with reftests.

And I don’t know what you’re talking about with the DOM API tests, there are several layout and compositor tests that require JavaScript and it’s unclear why other than the test author decided to use JavaScript to verify DOM metrics. That’s fine, I just don’t want that in my layout tests.

I’m OK with a subset of the tests just not being automated based on font rasterization and line height calculations. The standards make those expectations clear, but everything else feels like fair game to me.

I can either test for it, or I can’t. If I can’t, it’s not automated. And if it’s automated, I need information about what is failing, and much of the reftests don’t explicitly point out what they’re testing. The assert data is useful when it’s available, but even then sometimes test authors neglect to point out explicitly what they’re testing for.

Plenty of the layout tests in particular are just box model renders that should match with no explanation as to what section or text is being tested against. That’s just not acceptable. It’s not even about interactions between specs, the specs isolated are not well tested.

If you’re testing, let’s say, the width calculation of a box based on children boxes’ widths in normal flow, it needs to say that. And I think I’ve only ever see some of WebKit’s test’s help links reference actual sections.

Otherwise the WPT provide little to no value to me.

My team has been better off writing our own tests because we directly refer to the recommended or living standards texts by section, quote it and link to it, and as a result there’s no ambiguity about what property, calculation, or raster output we’re testing for.


That seems unrelated to whether WPT could cover this bug?


This subthread isn’t discussing IndexedDB.


It isn't? It looks to me like this subthread started with a question of whether this regression could have been caught by automated tests: https://news.ycombinator.com/item?id=27511318


Are you speaking from experience?

Because a cursory glance at Chromium src tells me they do have automated tests for IndexedDB:

https://source.chromium.org/chromium/chromium/src/+/main:con...


Yes, I am. I'm an implementor. Some of the most fundamental parts of the web don't have comprehensive test suites. IndexedDB is relatively much more modern.

However, if you do stumble on some tests for basic things like the box model, I'd love to know where they are! Tests like those would allow other vendors to know whether or not they're adhering to specification, programmatically.

Earlier standards are very descriptive, rather than telling you how to implement the actual web technologies. That's left as an exercise for the reader. Seriously!


Interesting. This makes it even more bafling to me that Safari doesn't have basic unit tests for a modern feature such as IndexedDb. It's certainly not for a lack of funds.

I guess applications living in the browser don't align well with Apple's interest in pushing their app store.


A part of it is interest, too. Simply because there is a exceedingly small number of vendors, building comprehensive test suites that benefit newcomers is just not in most organizations' best interests.

There actually are some partial tests from the W3C regarding basic web technologies, but they're not really automated ones in the way you'd think.


I don't think the other poster was talking about automated tests for conformance to the specification, just basic unit tests indicating that the feature works at all by any reasonable definition.


That kind of an issue is generally tested against by integration tests. Depending on the root cause unit tests for the entry point code might not have caught it.


You are right, an integration test would probably be better for demonstrating that this feature works.

I only mean to say that you don't need a whole compliance testing suite to catch a major bug like this.


However, if you do stumble on some tests for basic things like the box model, I'd love to know where they are!

Its not really a test suite, but back in the early days of CSS we had https://en.m.wikipedia.org/wiki/Acid2 It'd be easy to write a set of tests based on Acid2.

There's also https://en.m.wikipedia.org/wiki/Acid3 but that doesn't quite test things 'properly'.


Yes, I fondly remember the Acid tests. Unfortunately, they aren’t very useful for implementors as they don’t cover the entire breadth of the specifications in isolation.

In addition the specs have changed somewhat so now CSS 2.1 and the modules that existed at that point in time have matured beyond what the tests were written for, so a browser matching the spec today would fail.

They were very fun for end users to see whether or not a browser was in compliance, though!


I wonder if the path of least resistance would be to slowly convince the people that like writing Acid* tests to take things up a notch and rearchitect the next version(s) so that success is a measurement of collective+isolated implementational correctness.

Such an effort would probably involve a higher level of ongoing support from the vendor side of the fence (in terms of motivation and iterative discussion etc), but relative to other options might be, as I said, the path of least resistance.

</armchair_idea>


So does WebKit/Safari. Hundreds of automated tests for IndexedDB, in fact.

https://github.com/WebKit/WebKit/tree/main/LayoutTests/stora...


Seems like Safari could just adopt these tests…


Forget automated tests; this is something the most cursory QA would have caught. The fact that they evidently have neither is a reflection not of technical ability but plain neglect.


Remember when Chrome broke audio for everyone, including their own demo pages? [1]

Testing browsers is a daunting task. A modern browser is 10-15 million lines of code with literally thousands of exposed APIs [2]

[1] https://www.pcgamer.com/a-google-chrome-update-breaks-the-au...

[2] https://web-confluence.appspot.com/#!/confluence


QA very probably caught it, did a refresh (thinking that it's a problem with their test setup, as it is frequently the case) and then went about testing.


Apple never test safari very well, I have seen so many bugs that are easy to spot and reproduce.

My favorite one was websites added to the home screen on an iPad would have the clock displayed above the websites if you rotate the iPad after opening a website. It wasn't fixed for years and it may still be there.


It's opening the database _immediately_ after the browser starts that's the problem, which is easily missed given the browser isn't restarted for each test. Provided an IndexedDB test isn't run immediately after any restart, it'll pass.

As with every race condition (cross process, too, so tools like TSAN don't help), testing for the absence of race conditions is hard.


And AppStore rules forbid everyone from distributing/obtaining a browser that doesn't have such problem (and this isn't even one-off for Safari. Anyone who writes web apps can tell you they keep having such bugs).

Apple made it easy for themselves to have zero competition in browser engines.


maybe we need a good monopoly lawsuot since safari is usually the only browser available on the iphone.

im tempted to just x out the safari logo on mine since it likely cant be tested


Better Safari with buggy content blockers than Google blocking adblockers on mobile. Also, Safari has had much better JavaScript performance on iOS devices since at least the days of the A7-A8, looking at JS benchmark results relative to SPEC2006 results.


Firefox supports adblockers on mobile, and the functionality exceeds what Safari content blockers are able to achieve



Right, I mean on platforms other than iOS of course. That's why third party browser engines ought to be allowed, so that vendors like Mozilla would be able to provide those features on iOS too.


Because safari gets to use its own special source and everyother browser on iOS has to use an ios web view, doesn't it?


Safari’s web view is almost identical to the ones that third parties use.


Once the Safari monopoly on iPhone is gone, the web will belong to Chrome.


Once the Safari noncompetitive monopoly is gone, Apple will be motivated to make Safari best-in-class.


For me, Safari is best in-class on OSX.

It has the fastest UI, uses the least memory and uses a fraction of the battery life compared to all other browsers.

And from what we've seen in Monterey they are continuing to invest heavily in improving it.


> And from what we've seen in Monterey they are continuing to invest heavily in improving it.

lol, no. they're not. Safari specially on mobile is a joke and a bad one at it. Their whole strategy is to pull you into there Appstore and monetize every part of it and keep Webapps at a disadvantage


Yeah, I have no idea what people are talking about with Safari being the modern IE when Google is off in a corner trying to push web standards no one is asking for on a browser that makes its RAM consumption look like you’re doing video editing.


I suppose you felt the same way about IE?


I don't know why you're being downvoted, that is actually a fair and surprisingly thoughtful question.

My answer would be that the landscape of the web, advertising and software ecosystems are drastically different today.


Agreed. Apple are dragging their heels and will fight tooth and nail to protect their precious Apple Store revenue powered by the almighty 30% cut.


Which is kinda unnecessary: PWA are so bad that a good strategy would be to allow them (for instance by allowing Chrome with its own rendering engine), then let users decide what they prefer.


Plenty of native apps are terrible, oversized, over reaching in permissions or just plain battery drainers. Nothing stops PWAs being these.

If you're on about features? Ask Apple why they shy away from them on the web? Hard to justify imposing the 30% cut on a website/app.

Hell, Apple could have lead the charge on "web app privacy", implement the specs they've "missed" for web (notifications, background sync etc), and GATE THEM TO PWA/installed web apps, no more news sites asking to notify you when you just go to an article.

Heck, add keys to the web app manifest so as a developer I need an Apple Dev account and the holy $99 entry fee as well as my personal info in Apple's hands to make sites that do these things, so they have recourse to nuke the bad actors.


Nothing excites me more as a mobile user than having every website I use littered with push notifications and background processes that I need to dig through some Debug/Settings screen to discover.

Because web developers can absolutely be trusted to do the right thing.


almost every browser rrquires approvals. youre saying safari is write to have a shityy pwa implementation because the web isnt a walled garden


Pretty much 100% of users would prefer which ever technology solution that solves their problem for the least cost (in terms of money, or storage space on the device, or battery, or time, etc). For most apps that aren't graphically intensive, or require massive amounts of data in memory, or that require a ton of side effects when the user interacts with the UI, a PWA should do the job perfectly adequately even if it's worse than something native.

Being able to deploy a PWA that avoided the 30% cut Apple takes for all digital content would suit many users very, very well.


PWA are indeed limited, but they are particularly so because Safari drags them down.


No, it is because the idea that everything must be build using web tech is dragging them down.


It can only improve as fast as the slowest actor.


I’m fairly certain there are other browsers on iOS. Like Firefox and chrome.


But they use the same engine, they're basically skins for Safari.


Which means they all have exactly the same IndexedDB bugs and no one but apple can do anything about it.


There are other browsers but they’re all forced to use the Apple browser engine, so Chrome on iOS is WebKit-based, for example.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: