Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Porting a 100% local app to the web

actualbudget.com

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Porting a 100% local app to the web

#61

Post by purplecats »

AlexandrB wrote: post #2

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…

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

Re: Porting a 100% local app to the web

#62

Post by zamadatix »

pjmlp wrote: post #21
AshleysBrain wrote: post #8

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…

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.

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.

Re: Porting a 100% local app to the web

#63

Post by slmjkdbtl »

colordrops wrote: post #13
AlexandrB wrote: post #2

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.

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.

Re: Porting a 100% local app to the web

#64

Post by millstone »

brundolf wrote: post #58
AlexandrB wrote: post #2

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…

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.

Re: Porting a 100% local app to the web

#66

Post by brundolf »

millstone wrote: post #64
brundolf wrote: post #58

Earlier quoted context omitted.

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.

Re: Porting a 100% local app to the web

#67

Post by bsagdiyev »

purplecats wrote: post #61
AlexandrB wrote: post #2

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…

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.

Re: Porting a 100% local app to the web

#68

Post by streptomycin »

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

Re: Porting a 100% local app to the web

#69

Post by tonyedgecombe »

mojzu wrote: post #17
Spivak wrote: post #4

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.

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.

Re: Porting a 100% local app to the web

#70

Post by modeless »

mynegation wrote: post #27
pjmlp wrote: 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.

Web apps can now have an icon on the desktop, their own top level windows, etc. That's what PWAs are all about.

A few years ago I wrote a framework for daemon-based native/browser apps: https://github.com/jdarpinian/web-ui-skeleton. I used it for a benchmark that I wrote: https://google.github.io/latency-benchmark/ This approach is underused for sure.

Post reply on HN