19 ms·

Porting a 100% local app to the web

162 points by jlongster 6y ago

AlexandrB 6y ago
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
- jlongster 6y ago
  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.
- colordrops 6y ago
  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.
  - jlongster 6y ago
    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)
  - throw_m239339 6y ago
    > 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?
    - MaxBarraclough 6y ago
      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.
  - koube 6y ago
    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.
    - willyt 6y ago
      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.
  - viraptor 6y ago
    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.
  - slmjkdbtl 6y ago
    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.
- forgotmypw17 6y ago
  The desktop advantages also apply to Web because this developer allows data export, hasn't deprecated desktop app, and uses a portable data format.
- ponker 6y ago
  “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.
  - tpxl 6y ago
    > 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.
- kbuchanan 6y ago
  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.
- zelly 6y ago
  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.)
  - brundolf 6y ago
    This is true, and I'd bet it's one of the main value-adds of Electron
    - bkanber 6y ago
      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.
- brundolf 6y ago
  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.
  - millstone 6y ago
    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.
    - brundolf 6y ago
      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.
      - millstone 6y ago
        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.
        6y ago
- purplecats 6y ago
  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
  - bsagdiyev 6y ago
    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.
    - purplecats 6y ago
      right, I meant "I" as in personally, I don't have the skills, knowledge, or time to do that.
- oblio 6y ago
  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.
- SahAssar 6y ago
  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.
amun-ra 6y ago
Interesting app, how does it compare to YNAB?
- jlongster 6y ago
  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://actualbudget.com/docs/other/rules/
  - aphit 6y ago
    https://docs.youneedabudget.com/article/611-manage-payees#categorize 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.
    - jlongster 6y ago
      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.
Spivak 6y ago
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.
- mojzu 6y ago
  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.
  - AnIdiotOnTheNet 6y ago
    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.
  - tonyedgecombe 6y ago
    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.
- cxr 6y ago
  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.
joshmanders 6y ago
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.
- jaywalk 6y ago
  I think you misunderstood what they were doing here, because that would violate the entire purpose of storing the data locally.
  - WanderPanda 6y ago
    Come back in a couple of years, when people are running postgres in WASM...
  - joshmanders 6y ago
    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.
    - sdeframond 6y ago
      I believe this design enables end-to-end encryption. https://actualbudget.com/docs/overview/syncing-across-devices/#end-to-end-encryption https://actualbudget.com/docs/overview/syncing-across-device...
AshleysBrain 6y ago
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 https://www.construct.net [2] https://web.dev/file-system-access/ https://web.dev/file-system-access/
- jlongster 6y ago
  Looks awesome!
- pjmlp 6y ago
  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.
  - mynegation 6y ago
    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.
    - lovasoa 6y ago
      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.
Cldfire 6y ago
I've been a very happy user of Actual for almost two years now; kudos to jlongster for the fantastic product and wonderful support!
- jlongster 6y ago
  Thank you!
emmanueloga_ 6y ago
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 https://web.dev/storage-for-the-web/#check
- jlongster 6y ago
  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.
blntechie 6y ago
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.
kfk 6y ago
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.
- millstone 6y ago
  Desktop apps can reach higher quality. Compare e.g. Apple Keynote to Google Slides, the difference is obvious.
  - leipert 6y ago
    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.
    - millstone 6y ago
      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-collaboration-tan4e89e275c/mac https://support.apple.com/guide/keynote/intro-to-collaborati...
    - CharlesW 6y ago
      > 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 https://apple.fandom.com/wiki/Keynote
lovasoa 6y ago
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 https://github.com/sql-js/sql.js we also have a website with a cool URL https://sql.js.org https://sql.js.org (Unfortunately the old repo URL is still the first result for "sql.js" on google)
- jlongster 6y ago
  oh, thanks! just fixed it. yeah, I googled real quick and grabbed the first link. Thanks for all the work!
  - lovasoa 6y ago
    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.
PaulBGD_ 6y ago
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!
- jlongster 6y ago
  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.
zelly 6y ago
Synthesis: native mobile app
villgax 6y ago
https://sql.js.org/#/ https://sql.js.org/#/
streptomycin 6y ago
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/ 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!)
slykar 6y ago
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.

162 points by jlongster 6y ago

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

jlongster 6y ago
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.
colordrops 6y ago
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.
- jlongster 6y ago
  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)
- throw_m239339 6y ago
  > 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?
  - MaxBarraclough 6y ago
    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.
- koube 6y ago
  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.
  - willyt 6y ago
    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.
- viraptor 6y ago
  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.
- slmjkdbtl 6y ago
  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.
forgotmypw17 6y ago
The desktop advantages also apply to Web because this developer allows data export, hasn't deprecated desktop app, and uses a portable data format.
ponker 6y ago
“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.
- tpxl 6y ago
  > 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.
kbuchanan 6y ago
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.
zelly 6y ago
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.)
- brundolf 6y ago
  This is true, and I'd bet it's one of the main value-adds of Electron
  - bkanber 6y ago
    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.
brundolf 6y ago
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.
- millstone 6y ago
  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.
  - brundolf 6y ago
    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.
    - millstone 6y ago
      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.
      - 6y ago
purplecats 6y ago
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
- bsagdiyev 6y ago
  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.
  - purplecats 6y ago
    right, I meant "I" as in personally, I don't have the skills, knowledge, or time to do that.
oblio 6y ago
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.
SahAssar 6y ago
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.

amun-ra 6y ago

Interesting app, how does it compare to YNAB?

jlongster 6y ago
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://actualbudget.com/docs/other/rules/
- aphit 6y ago
  https://docs.youneedabudget.com/article/611-manage-payees#categorize 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.
  - jlongster 6y ago
    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.

Spivak 6y ago

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.

mojzu 6y ago
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.
- AnIdiotOnTheNet 6y ago
  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.
- tonyedgecombe 6y ago
  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.
cxr 6y ago
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.

joshmanders 6y ago

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.

jaywalk 6y ago
I think you misunderstood what they were doing here, because that would violate the entire purpose of storing the data locally.
- WanderPanda 6y ago
  Come back in a couple of years, when people are running postgres in WASM...
- joshmanders 6y ago
  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.
  - sdeframond 6y ago
    I believe this design enables end-to-end encryption. https://actualbudget.com/docs/overview/syncing-across-devices/#end-to-end-encryption https://actualbudget.com/docs/overview/syncing-across-device...

AshleysBrain 6y ago

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 https://www.construct.net [2] https://web.dev/file-system-access/ https://web.dev/file-system-access/

jlongster 6y ago
Looks awesome!
pjmlp 6y ago
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.
- mynegation 6y ago
  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.
  - lovasoa 6y ago
    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.

Cldfire 6y ago

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

jlongster 6y ago
Thank you!

emmanueloga_ 6y ago

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 https://web.dev/storage-for-the-web/#check

jlongster 6y ago
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.

blntechie 6y ago

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.

kfk 6y ago

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.

millstone 6y ago
Desktop apps can reach higher quality. Compare e.g. Apple Keynote to Google Slides, the difference is obvious.
- leipert 6y ago
  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.
  - millstone 6y ago
    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-collaboration-tan4e89e275c/mac https://support.apple.com/guide/keynote/intro-to-collaborati...
  - CharlesW 6y ago
    > 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 https://apple.fandom.com/wiki/Keynote

lovasoa 6y ago

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 https://github.com/sql-js/sql.js we also have a website with a cool URL https://sql.js.org https://sql.js.org (Unfortunately the old repo URL is still the first result for "sql.js" on google)

jlongster 6y ago
oh, thanks! just fixed it. yeah, I googled real quick and grabbed the first link. Thanks for all the work!
- lovasoa 6y ago
  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.

PaulBGD_ 6y ago

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!

jlongster 6y ago
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.

zelly 6y ago

Synthesis: native mobile app

villgax 6y ago

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

streptomycin 6y ago

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

slykar 6y ago

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.