* Better tech (sqlite3 in this case)
* Super fast
* User owns the data
What struck me is that the advantages of the web are primarily sales and developer advantages and are focused around the novice user experience. Whereas the advantages of the desktop are primarily user-centric and affect the long-term or power users.
I'm not sure this is generalizable to all web apps, but perhaps this distinction is why I always feel unsatisfied with the web app experience. I'm always happy to learn shortcut keys, tweak settings, and otherwise speed up the experience of apps I work with frequently. Basically I like being a power user. Web apps rarely cater to this desire and it feels like being stuck in perpetual "novice" mode.
That mostly is accurate, except for "Super fast", where I've seen many exceptions with slow and crashy desktop apps and extremely fast web apps, and "User owns the data", in which the browser stores the data locally and the desktop app sends back telemetry. In fact it's often easier to determine whether your privacy and data are being respected with a browser app than with a desktop appp.
Bad code can be anywhere. It's definitely the exception for web apps to store data locally in a way that works though. They might try to cache a bunch of stuff, but you always run into problems where 1. the cache is stale or 2. your working through something and it ends up having to hit the network anyway.
But yeah, I definitely agree that it's easier to profile the network activity of a web app. It's pretty cool that you can just open the browser devtools and see all the network requests, and there's no way for a page to "fake" it. I like the web for that reason, and it's also why I leave the devtools on in the electron version on desktop (users could open it and do the same, but it's not as trustworthy, i.e. I could hack electron and fake it)
In addition to understanding what data is being sent back, also the amount of data an application has access to is wildly different between browser and desktop apps. There's basically no asking permission to your files with a desktop app, it just always has access to all of the data on your computer in most cases.
Yesterday I got a call from a tech support scam, claiming to be comcast security. The very first thing they instructed me to do was to download a desktop app, teamviewer. When I refused to do so, there was nothing else they could do besides read my name and address to me.
Native apps are inherently faster, because the browser is much more bloated than the native windowing system (it's millions lines of code on top of that), it's just it's very easy to write slow software in any environment.
I believed the apps will often get optimised for what can be seen as an issue. If you distribute a desktop app, you'll often not see the results of large datasets people accumulate over time, so the permanence sucks. But if you're running a webapp, then the performance directly impacts your costs / availability. You will have to solve those, or pay for more hardware.
The business case for native apps (whether on desktop or mobile) is that it's not just another tab people can X out of. Installing a native app feels like a commitment. The icon is there. It might be sitting in the tray/taskbar. It commands attention. It can push notifications that most users wouldn't turn off.
Most users do not know what a PWA is and won't install it unless it was done for them. Even then a PWA is at the mercy of the host browser's configuration and addons which can degrade the experience. (And on Apple devices it won't even work.)
I've built a few electron apps lately. That's an advantage, but another important one is that you can use node APIs in what is otherwise basically a webapp. The app I'm working on now is an SSH server monitoring thing, which wouldn't be possible in the browser (maybe with wasm, but /shrug).
I should mention though that desktop apps seem to have an order of magnitude conversion rate than web apps... it's been a slog.
“easy deployment” makes bug fixes fast, and the subscription business model gives the developer a financial incentive to make those fixes. I’d say the average Web app is more robust than the average desktop app... even small one-person web apps are usually pretty good. At the very high end from the huge companies like Apple, Microsoft, Spotify, Adobe, Autodesk, etc. the desktop apps are better.
> I’d say the average Web app is more robust than the average desktop app...
Yes, those robust web apps that disappear as soon as the vendor loses interest, unlike those pesky desktop apps that work years after the vendor is dead.
Nothing about the web platform prevents keyboard shortcuts or high levels of customizability. Moving away from these is just a cultural shift in the industry, for better or worse.
It's legitimately hard to make a good keyboard shortcut on the web, especially since there's no interop with native keyboard shortcuts (e.g. no web Undo API). This becomes a death spiral: users don't expect keyboard shortcuts to work, so nobody bothers making them.
I wouldn't say it's hard... I've worked on a web app that had extensive keyboard shortcuts because it was designed for power-users. There are some platform-specific inconveniences like listening for Cmd on Mac vs Ctrl on Windows/Linux, but that's nothing compared to writing an entirely separate application for each platform.
I think they don't get made because of a) a cultural shift, and maybe also b) because the browser itself has some keyboard shortcuts that users may care about more (and don't want overridden). For example Twitter actually has a bunch of shortcuts and I usually invoke them on accident. But if your users are power-users then they probably know what features are available, and of course if you're using electron then the point is moot.
The web makes it much easier to give a button a drop shadow than a keyboard shortcut; that's the sense in which it's hard. The web's origin is documents, not software.
"Users don't want websites to override their keyboard shortcuts" is so right and so telling! We've all been burned by copying a Google search link, or had 'automated link attribution' spam our clipboards. Keyboard shortcuts should not be a "power user" feature but that's where we find ourselves, as the web subverts all user interactions.
> "Users don't want websites to override their keyboard shortcuts" is so right and so telling!
I mean, it's no different from an OS that has shortcuts that applications shouldn't override. The browser is just one more system layer. That may limit some of the specific shortcuts you may want to use (or not! you can override them if you deem that worthwhile to your users), but it doesn't make things "hard". At my company we solved this by adding Shift to every binding, which browsers hardly ever use.
And again, if you're using Electron, you don't even have to worry about that aspect because your user isn't exposed to the UI "as a website", meaning they won't be reloading, going back/forward, opening new tabs, etc which are the most common browser-level keybindings.
To me, the distinction here is not "user-centric" vs. "business centric"—ease of install is also a user-centric value. I think you hit the nail on the head by suggesting it's about power user vs. basic user.
One piece that you didn't add to the "For web" column is "Works almost everywhere". Anywhere you can run a modern web browser the web app will work, so esoteric linux distros, new smartphone platforms and other systems often not thought about by the "native app" folks work just as well as established platforms. That sort of freedom is crucial for me.
I’ll be a bit pedantic, but you totally can do that (hacking dlls and binaries), it’s just the barrier to entry and the amount of effort needed is higher.
We ported our game development software Construct [1] from a Windows desktop app to the browser in 2017, and haven't looked back since - it's been great!
The approach of "local app in the browser" works very well and is underrated IMO. It's the approach we use too - everything is downloaded via a Service Worker for offline support, and it's very responsive as nothing needs to wait on the network, unless the user chooses to (e.g. saving their work to Google Drive).
Chrome 86 also introduces the File System Access API [2] which is the icing on the cake - you can get read/write access to actual local files and folders, bypassing any issues about IndexedDB limits or persistence. I think this is one of the last pieces of the puzzle to make tools like Electron and NW.js more or less redundant, as now you can just do it directly in the browser and not have to ship the whole runtime around to everyone as well.
Electron has always been redundant, the approach daemon + local browser has worked since browsers exist, and then there are web views anyway.
The problem is that those approaches require the developers to actually care about what browser the user has installed instead of pushing Chrome everywhere.
I disagree. I have not seen many applications that take daemon + local browser approach. What are the examples?
Yes, each Electron app ships a copy of node and Chromium engine, but user gets icon on a desktop, ability to manage windows with whatever window manager and utilities, hotkeys, tray icons, dedicated menu etc.
I was thinking about the browser+daemon approach for an application that I maintain, and would also be very interested if someone has done it and has feedback to give.
You do have to be careful to avoid security issues. XSRF could be a problem if your server exposes sensitive APIs. But XSRF is not unique to this approach, and the techniques for defending against it are well known. And Electron has security issues of its own which are probably more serious.
Overall I recommend the daemon + browser approach. The "benefit" to Electron of only having to support one browser is rarely realized in practice because you almost always want a hosted version of your app as well, and that needs to support all browsers anyway. For example Slack and VSCode both have web versions.
Daemon+web results in exactly that, two apps. Electron allows a single app to be developed i.e. you dont have to think about how to ferry the data back and forth (or at least when you do you hace more options than "how can i shove this over http"). IMO that is infibitely more valuable than dealing with browser inconsitencies in 2020.
> Chrome 86 also introduces the File System Access API [2] which is the icing on the cake - you can get read/write access to actual local files and folders, bypassing any issues about IndexedDB limits or persistence.
How likely is this to get deprecated like the file system API, web SQL API and Chrome apps? I'm excited about this too but support is still poor https://caniuse.com/native-filesystem-api.
I'm the main author of sql.js (the wasm compilation and javascript API for sqlite that the author uses). It's nice to see a cool use case like that. Just wanted to mention that the link to the github project is wrong, it should be :
Yes, it's an vicious cycle: google has the wrong URL, so people link to the wrong URL, so google gives more weight to the wrong URL.
Unfortunately we can't remove the old repo because we don't want to break existing github pages links.
As much as it seems the general tone of HN is firmly against having the File System APIs in browsers it really is the bridge that enables truly offline webapps to work. The fact that the only consistent persistence story is to send your data to a server you don’t control makes everything harder.
If we want users to really own their data we have to give webapps somewhere to put it that’s in the user’s control.
I agree, I understand the concerns about the ballooning complexity of browsers. However I think overall an open app ecosystem built on the web using PWAs/wasm/other stuff, is a preferable outcome to all software having to go through an app store.
At this point there's no point in caring about complexity ballooning. That plane has sailed and browsers are already far too complex for anyone to reasonably reimplement them with full functionality.
There is an alternative to web stuff and app stores. I've spent a lot of money on software over the years and very little of it has been through app stores.
There's nothing inherent to Web apps that's forcing the hand of developers to send user data to a server outside the user's control (i.e. opting not to give the choice of sending it to a server the user does control). Keeping user data on servers that the Web app developer controls is a decision that developers make because control over user data is usually an adversarial conflict, and when given to power to do developers go for the choice that works out to their advantage.
Your homepage convinced me to download, the software reminds me a lot of Microsoft Money, which was one of my favorite tools due to its simplicity. Only complaint is no dark mode, but really cool!
Awesome, thank you! You are the first person to ever mention dark mode which is super surprising to me! I bet others have had the thought, just haven't said anything. It will come at some point but it's not a super high priority.
I have a fairly popular app that stores data in IndexedDB. Luckily it's a free app and the data is not critical, so it's not too bad when users lose their data.
How do they lose their data? Three ways, mostly:
1. They clear their browser cache, including data in IndexedDB, without realizing that will delete data from my app.
2. Some internal browser error. An error message pops up somewhere, they reload the page, and all the data is gone.
3. The browser intentionally deletes it because of a quota. In the old days, this was a theoretical concern - allowed by the spec, but browsers never did it. These days, it is a real thing that happens.
Something that helps a bit is the persistent storage API https://web.dev/persistent-storage/ but it's not ideal. Last I did a deep dive (like a year ago) it was not supported at all in Safari, and it was weird in Chrome (the browser would not allow the user to enable persistent storage unless the user had spent some unspecified about of time/activity on the website first).
My point is, overall it's kind of shitty. The data is local, but users are not in control. The browser is in control, and browsers these days seem to almost have contempt for users. The idea that users can manage their own data - preposterous, we must do it automatically in the background and give the user no control!
It's good enough for my app, but I would not want to put my budget data in IndexedDB.
(That being said, I do appreciate your blog post, and your architecture sounds pretty cool!)
If the app lives in full isolation and your focus is data ownership desktop is probably better, but I struggle to understand how it can be better tech for any other use case. I work in a big company so maybe I am biased but 1) every app eventually has to integrate with some other app; 2) every app eventually is used by more than 1 person; in both 1 and 2 desktop pretty much breaks (unless you use version control for 2). In fact we are still dealing with desktop issues as we port this amazing 80's-90's MS era workflow into the cloud and still train users to "save" files.
> 1) every app eventually has to integrate with some other app
I'd expect that desktop apps give you the ability to read files and write programs to transform them into another format (easier if the two formats are fairly open), whereas for cloud storage, you're left at the mercy of the two apps to develop integration.
Ha. Wanted to counter your argument with: Keynote is older. It is, but just by 3 years, (2003 vs 2006).
Depending on the features you use your argument might fall flat though, how do I collaborate on a presentation? How can I easily share a presentation with a set of folks?
I like Keynote a lot, but Slides has it’s use cases as well.
Keynote actually has pretty great real-time collaboration [1], though it does have more friction than GSlides, not least of which because it requires a Mac.
I agree GSlides has its uses. Web apps are good for ephemeral tasks, but I use desktop apps for stuff I care about.
> Keynote is older. It is, but just by 3 years, (2003 vs 2006).
Fun fact: 2003 was Keynote's public unveiling. Before that, it was a bespoke NeXTSTEP app created for Steve Jobs. (I'm not sure how old proto-Keynote is, but IIRC he'd used it publicly since the late 90s.)
The only thing similar is how the budgeting system works, and even that is going to change soon. Soon you'll be able to choose between a zero-based budget or a simpler report-style budget that just shows income vs expense (and provide some features help track things).
There's also the big difference that the app is local and we provide end-to-end encryption.
Sure, but that's all it can do. You could categorize the same payee differently based on dates or notes, and really anything you want to do. In the future it'll create rules to automatically mark recurring transactions, etc.
Are you using the quota API? Looks like you can ask how much space is available, so you could warn the user to free space if it is below some threshold.
Not yet! I plan to but it's not fully supported (I think Safari is the only one missing?) and you still have to handle quota exceeded errors anyway. My first step will be handle the quota errors gracefully and warn users that it's not locally saving changes.
What company I work for did: start a desktop app on a VPS and make it accessible over a web based remote desktop. The app was supposed to run 24/7, so it was additional plus for the customer, because now they could have a computer running outside their house.
Sure it was because he wanted the desktop app to be local, but then he added sync, and now there's an API, etc... Data is already stored on his server.
For web:
For desktop: What struck me is that the advantages of the web are primarily sales and developer advantages and are focused around the novice user experience. Whereas the advantages of the desktop are primarily user-centric and affect the long-term or power users.I'm not sure this is generalizable to all web apps, but perhaps this distinction is why I always feel unsatisfied with the web app experience. I'm always happy to learn shortcut keys, tweak settings, and otherwise speed up the experience of apps I work with frequently. Basically I like being a power user. Web apps rarely cater to this desire and it feels like being stuck in perpetual "novice" mode.
Edit: s/mobile/web