IndexedDB doesn't have full browser support yet (Edge is listed as having "partial support" [2]), but Chrome, Firefox, and recent versions of Safari all support it.

[1] https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...

[2] http://caniuse.com/indexeddb/embed/

You are of course right, but it's always good to surface pathological worst-case scenarios as interesting counterbalances.

IndexedDB has really, really REALLY bad performance. It's like a turtle that's been trapped in molasses. I did some benchmarks on my (old) laptop here: https://stackoverflow.com/questions/42288596/websql-has-incr...

For a particularly rare edge case, I periodically have to SIGKILL Chrome so it doesn't crash (due to failed SQLite assertions) when my disk gets full and I have to shuffle things around to make space. In the last instance of this taking place, / had 820KB free.

(Context would probably be useful here: I have a 15+-year long diskspace issue created by being given many many old computers with tiny hard drives and not having the infrastructure/knowhow (when I was younger) to move/sync active projects between machines. I just need to get a couple large HDDs so I can collect and dedupe everything, but I can't work due to health issues so that's proving... fun. This is also blocking all kinds of things such as getting my first smartphone, so I have nowhere to back it up onto!)

Hmm. If I'm reading right it looks like I'm slightly north of you, in Sydney.

Been meaning to add something to my profile. Done.

I'll endeavor to get in touch soon. This is pretty cool.

I'll try running it on my X220 later.

[1]: http://scaljeri.github.io/indexeddb-vs-websql/v2.0.0/index.h...

Either that specific test (I didn't make it, to clarify) or Chromium has a bug.

Depending on how I fiddle with the browser, the test either takes 134 seconds or 6 (!!!) seconds.

Of course when I ran the test for the first time I did it a few times. I think the repeated tests may have triggered these bugs.

If I go to the test page, click the (i) to the left of the domain, hit Cookies, select the domain (the root of the tree listview) and Remove (to remove the IDB, WebSQL and localStorage bits the page sets up) and then run the test, I consistently get 6 seconds.

My suspicion is that, the page is creating 1000 items in localStorage, THEN adding my 10000 on top of that. That would explain the crazy delays.

However, this does not explain why, when I visited the page for the first time in several months, it completed in 6 seconds without any tinkering required.

Note that the page re-fills localStorage on each load - clearing it after the page has loaded is key.

"Works best with IE 6" is so old now you'd think tech folks would think twice.

The browser ecosystem is much healthier now. If Chrome ceases to innovate there are others ready to take over.

Mutt, Pine, Eudora, and Thunderbird, welcome home.

Apparently it's possible, assuming the device has a sufficiently large storage and, I'm assuming, the user accepts.

"For this reason, the browser version of the email app only works in Google Chrome"

I just made this as a reply in another thread where the user essentially believed you couldn't have a nice GUI (his example was VS Code) with a native toolkit that's also easy to develop in:

https://i.imgur.com/RPr6VMS.png

https://gitlab.com/mixedCase/poc-qml-vscode

We've had the tools for a long time in desktop, let's not pretend we don't.

In meantime, i will just bookmark your comment :)

Install QtCreator, grab the docs and play around in a new project. You can drag and drop components around in design mode and you'll be able to figure out how QML works from there. It's really intuitive.

Also the point of QtQuick as an alternative to Electron is not to look native beyond the menus and dialogs.

And you probably associate Qt with Qt widgets, not QtQuick. Qt widgets actually tries to resemble and behave like native widgets, and it will let you get to that point if you actually care about that.

Most people making cross plat applications don't, which is why popular Qt widgets applications like VirtualBox and VLC don't look native, and QtQuick applications like Telegram for Desktop just ignore the desktop's HIGs completely.

What? Let's not rewrite history. I has been easy and cheap to create desktop UIs for decades, literally. I was using Borland Delphi 1.0 as a 13 year old and could have a basic Windows UI app up and running in ten minutes.

There have been many great cross-platform and platform-specific toolkits that are easy to use. E.g. you can teach someone with some Python knowledge how to make basic Qt desktop applications in one hour or so. It's literally as simple as dragging some widgets to a window and writing some lines of wrapper code.

I recommend anyone who thinks that developing applications using web UIs is easier/cheaper to look at some Delphi 1.0 videos. E.g.:

https://www.youtube.com/watch?v=m_3K_0vjUhk

This was how we developed desktop applications 22 years ago on machines with 4 or 8 MB RAM. And it is still a whole lot easier and more efficient than a web app.

Additionally, Microsoft has their own framework similar to what QML offers: WPF. The problem with it is that it doesn't have cross platform support, something they wanted to have for VSCode.

It's all exhorbitantly easy to use. Cost is not the issue, specially since they already have a lot of really talented people working on VS Code.

I have used quite a few UI toolkits since those days and am yet to agree with the opinion that the Frankenstein mixture of HTML, CSS and JavaScript is a better UI toolkit.

The thing about efficient language wasn't 100% targeted at web technologies alone, but at the general waste of computing resources for something as trivial as a mail client. Just because we have SSDs, gigabytes of RAM and CPUs that do a whole lot of cycles doesn't mean wasting a good portion of it is a good idea.

I was saying that's the right trade-off to choose in a lot of common use cases. Because most UI toolkits are pretty limiting, and the web toolkit can be amazingly powerful and productive. Of course, if you follow the latest fads in the awful js community they are a nightmare, but lets not pretend that's the only way to use the platform when it makes sense to pay the efficiency cost.

no different to having your javascript decryption routines done by a website

Nonetheless you're absolutely correct; i would prefer firefox to chrome.

Right. This is as if Outlook was written in VBA and ran inside Word.

As the other commenter pointed out it's a safe bet for marketing purposes and looks best aesthetically. But the confusion here could be a real problem for early adopters.

think electron app, but without electron, and instead running directly in chrome.

Edit: MS Edge also has 250MB-500MB; they're just always playing catch up, even when their market share has dwindled...

No, that is not a website or webapp, it's a Chrome app.

     "permissions": [ "unlimitedStorage" ] 

*in the near future

https://stackoverflow.com/questions/1921048/limit-of-localst...