Live data from Hacker News

Porting a 100% local app to the web

actualbudget.com

41–50 of 81 posts

Re: Porting a 100% local app to the web

#41

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…

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.

Re: Porting a 100% local app to the web

#42
post #21

Earlier quoted context omitted.

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.

CUPS admin console, SharePoint admin console for example.

Same can be done with web widgets, or a couple of utility daemons.

Well, at the end of the day don't complain about Google owning the Web.

Re: Porting a 100% local app to the web

#43

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…

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.

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.

Re: Porting a 100% local app to the web

#44

Earlier quoted context omitted.

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.

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

Re: Porting a 100% local app to the web

#45
post #42

Earlier quoted context omitted.

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.

CUPS admin console, SharePoint admin console for example. Same can be done with web widgets, or a couple of utility daemons. Well, at the end of the day don't complain about Google owning the Web.

... are there any people on earth who prefer to use the CUPS web console rather than their DE's printer settings ?

Re: Porting a 100% local app to the web

#46
post #42

Earlier quoted context omitted.

CUPS admin console, SharePoint admin console for example. Same can be done with web widgets, or a couple of utility daemons. Well, at the end of the day don't complain about Google owning the Web.

... are there any people on earth who prefer to use the CUPS web console rather than their DE's printer settings ?

An example was provided, I wasn't asked to provide a Mona Lisa of the ultimate UI/UX design experience.

Re: Porting a 100% local app to the web

#47
post #26

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…

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

Re: Porting a 100% local app to the web

#48
post #23

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…

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

Re: Porting a 100% local app to the web

#49
post #21

Earlier quoted context omitted.

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.

[deleted]

Re: Porting a 100% local app to the web

#50

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 choo…

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

Post reply on HN