"Unlike most browser-based email, which is server-based, Superhuman can store and index gigabytes of email in the web browser itself."
Did I miss something, or what technology can store gigabytes in a web browser?! Unless they are compressing email aggressively (possible) and storing in SessionStorage/LocalStorage, decompressing on the fly... then this sounds like marketing fluff, or just written poorly.
IndexedDB can store a huge amount of data — your browser will allow up to 50% of the free space on your machine to be used. [1] In most cases that would be gigabytes.
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.
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!)
You've got no contact details in your profile but in the very small chance that you're in Australia, I've got a number of spare hard drives I could give you.
I just re-ran your test suite[1], and I got 1.325s insertion time with 10k items on IndexedDB on Chromium on GNU/Linux (with lots of tabs open). I'm on a fairly modest 8-core 16GB box. It's still 1 order of magnitude slower than the others, but not as bad as your old results.
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 in IE 6" wasn't dumb at the time. It was the best browser available. What was bad is those sites continued to work only in IE6 long after it ceased to be the best browser.
The browser ecosystem is much healthier now. If Chrome ceases to innovate there are others ready to take over.
Yeah, except the way I read OP's comment is he thought the whole implementation (server, storage, etc) was all local in the browser. But this is NOT the case (I thought that was the case too initially).
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:
Nice.. Though one small niggle: I wanted to bookmark this for later reference, but the git page has no screenshots, and the screenshot has no title or link to the gitpage..
Don't bother with Qt widgets, learn QtQuick and QML.
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.
Microsoft has tremendous resources, it's definitely costlier to build a great desktop UI than a great Web UI (but the great
Eat desktop UIs are always better).
Microsoft has tremendous resources, it's definitely costlier to build a great desktop UI than a great Web UI
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.:
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.
Only if your measure for great is "looks and behaves in a bug-compatible manner exactly like the native toolkit". Otherwise, no, I'd very much disagree.
danieldk's response sums it up quite nicely. I will add that around the same age I found Microsoft's own Visual Basic 6 and was doing stuff with it.
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 been doing native GUI development starting with Turbo Vision in Turbo Pascal 6 and started with Web development in about 1997.
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.
A lot of people think the earth is flat and landing on the moon is fake. Call me a misanthropist, but I generally have little faith in 'a lot of people' ;-)
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 wasn't saying it was good because it was popular, not making an argument from popularity, since I also think most people are stupid.
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.
I have found Chromium to be a nice alternative to keep local browser apps working as it freezes the browser version instead of automatic upgrades, which have regularly broken web based line of business applications I have been around the past few years.
Most PSD templates for screenshots are Macbook screens + Safari. Having designed a number of landing pages for startups I'm really not surprised that the designer they hired for their website chose to use that (without considering the current browser support).
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.
Designer here. This is accurate. The long story is, this site was mocked a bit before all the final technical details were scoped out for the project. It's in need of a visual refresh to more accurately represent the platforms we use.
I don't know whether Superhuman will be a plugin or not, but there's no reason it would have to be; IndexedDB can provide gigabytes of space, and it's standardized, and current versions of Chrome, FF, and Safari all support it.
Depends if you consider IE and Mobile Safari as a required target. They have 250MB and 50MB limits, respectively. But yes, if these can be omitted then IndexedDB API seems fine nowadays.
Edit: MS Edge also has 250MB-500MB; they're just always playing catch up, even when their market share has dwindled...
in the manifest.json then "The size of unlimited storage is limited only by the availability of space in the user's hard drive." Not quite sure if that's how they do it.
Did I miss something, or what technology can store gigabytes in a web browser?! Unless they are compressing email aggressively (possible) and storing in SessionStorage/LocalStorage, decompressing on the fly... then this sounds like marketing fluff, or just written poorly.