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

21–30 of 81 posts

Re: Porting a 100% local app to the web

#21

Post by pjmlp »

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.

Re: Porting a 100% local app to the web

#22

Post by forgotmypw17 »

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…

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

Re: Porting a 100% local app to the web

#23

Post by kfk »

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.

Re: Porting a 100% local app to the web

#24

Post by AnIdiotOnTheNet »

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.

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.

Re: Porting a 100% local app to the web

#25

Post by olnluis »

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…

I taught some summer game development classes for middle schoolers using Construct on the browser. It was a breeze.

Re: Porting a 100% local app to the web

#26

Post by ponker »

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…

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

Re: Porting a 100% local app to the web

#27

Post by mynegation »

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.

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.

Re: Porting a 100% local app to the web

#28

Post by lovasoa »

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)

Re: Porting a 100% local app to the web

#29

Post by jlongster »

lovasoa wrote: post #28

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!

Re: Porting a 100% local app to the web

#30

Post by lovasoa »

jlongster wrote: post #29
lovasoa wrote: post #28

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.
Post reply on HN