Hacker News Reader

Comment by AlexandrB | Hacker News Reader

It was interesting to read the stated advantages of each platform:

For web:

    * Easy deployment
    * Better conversion rates (no installation)
    * Easier login flow, support, a/b testing

For desktop:

    * 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.

Edit: s/mobile/web

View on HN

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)

> where I've seen many exceptions with slow and crashy desktop apps and extremely fast web apps,

Such as? Apps that do exactly the same thing on the desktop version and the web version? desktop using what tech?

I've never seen a desktop application slower than the web application, at worst the desktop version is the web version, as with Electron.

Pinboard is a good example of a fast web solution.

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.

That’s not true on recent versions of macOS. Apps have to ask the first time and you can grant them access to specific folders / services only.

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.

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.

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.)

This is true, and I'd bet it's one of the main value-adds of Electron

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.

I think you meant "For web:" instead of "For mobile:" (I'm talking about desktop for both web and native)

Yep, I think you're right. By default the web sandboxes you into a naive client. I'm hoping to change that with still doing everything locally.

You forgot portability. Web apps by default are cross platform.

I've lost count of how many Windows-only and these days even MacOS-only apps I've seen. Similar story for Android or iOS.

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.

  document.addEventListener("keydown", (e) => {
    if (e.ctrlKey && e.code === "KeyA") {
      console.log("Shortcut pressed!")
    }
  })

I qualify the above as easy.

> "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.

The desktop advantages also apply to Web because this developer allows data export, hasn't deprecated desktop app, and uses a portable data format.

a hidden major advantage of web is for hackability for power users/devs.

i can't hack dlls and local binaries, but i can easily make extensions and hack anything on the web to hell and back

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.

right, I meant "I" as in personally, I don't have the skills, knowledge, or time to do that.

Reply on news.ycombinator.com