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

71–80 of 81 posts

Re: Porting a 100% local app to the web

#71

Post by modeless »

lovasoa wrote: post #31
mynegation wrote: post #27

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.

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.

Re: Porting a 100% local app to the web

#72

Post by purplecats »

bsagdiyev wrote: post #67
purplecats wrote: post #61

Earlier quoted context omitted.

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.

Re: Porting a 100% local app to the web

#73

Post by pjmlp »

zamadatix wrote: post #62
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.

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.

Re: Porting a 100% local app to the web

#74

Post by slykar »

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.

Re: Porting a 100% local app to the web

#75

Post by millstone »

brundolf wrote: post #66
millstone wrote: post #64

Earlier quoted context omitted.

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

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.

Re: Porting a 100% local app to the web

#76

Post by yakubin »

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.

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

Jupyter Notebooks.

Re: Porting a 100% local app to the web

#77

Post by yakubin »

jcelerier wrote: post #45
pjmlp wrote: 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 ?

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.

Re: Porting a 100% local app to the web

#78

Post by oblio »

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…

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.

Re: Porting a 100% local app to the web

#79

Post by willyt »

koube wrote: post #19
colordrops wrote: post #13

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.

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

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.

Re: Porting a 100% local app to the web

#80

Post by SahAssar »

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…

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