Porting a 100% local app to the web | Hacker News Reader

Porting a 100% local app to the web

actualbudget.com

162 pointsjlongster79 comments

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

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.

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.

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.

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

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

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.

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.

[1] https://www.construct.net [2] https://web.dev/file-system-access/

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.

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.

I do. The DE's printer settings rarely work. CUPS on the other hand always has some way of successfully configuring a printer.

And whatever its problems are, not being an Electron app is not one of them.

At least one!

> I have not seen many applications that take daemon + local browser approach. What are the examples?

Jupyter Notebooks.

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.

I made a framework for it a few years ago: https://github.com/jdarpinian/web-ui-skeleton

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.

It is insane for a browser to be a runtime for every desktop app. This is why people complain about 16 GB memory being too little.

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.

Webviews are the answer there.

As I keep saying don't complain about Web == ChromeOS, when you push Electron everywhere.

> 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 taught some summer game development classes for middle schoolers using Construct on the browser. It was a breeze.

Looks awesome!

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 :

https://github.com/sql-js/sql.js

we also have a website with a cool URL

https://sql.js.org

(Unfortunately the old repo URL is still the first result for "sql.js" on google)

oh, thanks! just fixed it. yeah, I googled real quick and grabbed the first link. Thanks for all the work!

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.

Desktop apps can reach higher quality. Compare e.g. Apple Keynote to Google Slides, the difference is obvious.

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.

1: https://support.apple.com/guide/keynote/intro-to-collaborati...

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

More here: https://apple.fandom.com/wiki/Keynote

I've been a very happy user of Actual for almost two years now; kudos to jlongster for the fantastic product and wonderful support!

Thank you!

Interesting app, how does it compare to YNAB?

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.

An example of a feature that YNAB doesn't have at all is custom rules: https://actualbudget.com/docs/other/rules/

https://docs.youneedabudget.com/article/611-manage-payees#ca...

It seems like, at least the first mentioned use case in Actual's documentation, is covered by YNAB already.

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.

https://web.dev/storage-for-the-web/#check

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.

The best example I would say for similar software is PhotoPea. Just check out how powerful it is and it completely runs locally on browser.

https://sql.js.org/#/

Synthesis: native mobile app

WASM sqlite3 in the browser because of complex SQL queries? Why not just use PostgreSQL and refactor to make API calls with GraphQL or something?

I feel this simple app is too over engineered.

I think you misunderstood what they were doing here, because that would violate the entire purpose of storing the data locally.

Come back in a couple of years, when people are running postgres in WASM...

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.

I believe this design enables end-to-end encryption.

https://actualbudget.com/docs/overview/syncing-across-device...

Reply on news.ycombinator.com