Live data from Hacker News

Ask HN: Is there still a place for native desktop apps?

news.ycombinator.com

161–170 of 777 posts

Re: Ask HN: Is there still a place for native desktop apps?

#161

Earlier quoted context omitted.

I admire your words here. I am on the other side, building electron apps, I appreciate the flexibility and ease because I would rather iterate on ideas then learn three different OS-hooks. I do agree that memory usage is too high on these types of apps and we as developers can be lax about performance.

I agree too, and your average user is not going to care about the fact you've used Electron, or even know. It's a big win for development.

I disagree. I mean they may literally not know that your app uses Electron, but they'll certainly have the feeling of, "Oh, that janky app that doesn't quite work correctly and makes my system slow."

Re: Ask HN: Is there still a place for native desktop apps?

#162
post #88

IMO desktop apps aren’t quite equivalent to native apps. Native apps look and behave in a consistent way. They have • Familiar UI primitives: - Controls and chrome are in the same place - Font sizes are the same across apps - Consistent icons and button shapes • Support standard keyboard shortcuts (including obscure ones that developers re-implementing these UIs might not know about) - All the Emacs-style keybindings…

I don't agree with the first two points. Native applications aren't consistent in this way. There are dozens of cross-platform GUI kits and they all behave slightly different, just like Electron apps. If you want consistency, you need to build multiple apps, one for each OS with their respective toolkits. Ain't nobody got time for that when you can easily build on Electron and target browsers, macOS, Windows, and Lin…

Native implies that you are building for each OS and their native toolkit. On macOS, you write Cocoa. On Linux you write GNOME or KDE or CDE. On Windows you write...I dunno. Win32 probably.

Re: Ask HN: Is there still a place for native desktop apps?

#163
post #118

Earlier quoted context omitted.

And Winamp is 4MB (after removing the stock plugins that I don’t need, like modern skins and the long-broken media library internet lookup stuff). How big is Spotify now?

Spotify is 273MB (on Linux at least), 70MB for the binary and 137MB for Chrome, plus some other bits and bobs. $ pacman -Qi spotify Name : spotify Version : 1:1.1.10.546-4 Description : A proprietary music streaming service Architecture : x86_64 ... Installed Size : 272.79 MiB So at least it's smaller than Slack.

I have a noob question, but how do proprietary apps (IE: Slack) make it onto the AUR without having an official binary?

Re: Ask HN: Is there still a place for native desktop apps?

#164
post #49

Earlier quoted context omitted.

I think he is saying that because with webapps you have - control over your software and updates - no one can pirate your software/service

How do you have more "control over your software" with a web app? With a native app, I can do virtually anything. With a web app, I can really only do what (Google ∩ Apple ∩ Microsoft)'s web browser teams decided to prioritize, and allow, and optimize. As for 'pirating', is that a serious concern these days? I've only ever heard about it being an issue at big companies selling software to other big companies, where i…

>> How do you have more "control over your software" with a web app?

It means they can break a program I'm using at any moment they wish, even after I paid for it.

Re: Ask HN: Is there still a place for native desktop apps?

#165
post #116

Earlier quoted context omitted.

It’s not though. Not even close. And I know this partially a matter of taste but I have one of the fastest computers you can buy and I can’t even participate in text chats without input lag and delays in interaction. It’s not a good user experience for me at least but that’s ok, we’ll keep stacking more cpu power until it’s all in the cloud anyways.

That just sounds like server latency to me or some kind of bad programming like relying on polling. Obviously if you build a chat client in the browser and communicate between windows then it's instantaneous. Faster than human perception. Certainly doesn't seem to be a CPU issue to me. I mean, we run videochat in the browser which works fine. Obviously text chat can be instant.

I’m talking about the native slack app. I used to use the irc gateway and now go back and forth between desktop and unofficial gateways. I use keyboard shortcuts to navigate between chat windows and nothing about it is instantaneous...even when there’s nothing but text. Same thing applies to discord, and less so with WhatsApp and signal. Messages on the other hand is silky smooth, and terminal irc couldn’t get any faster.

Re: Ask HN: Is there still a place for native desktop apps?

#166
post #163
post #118

Earlier quoted context omitted.

Spotify is 273MB (on Linux at least), 70MB for the binary and 137MB for Chrome, plus some other bits and bobs. $ pacman -Qi spotify Name : spotify Version : 1:1.1.10.546-4 Description : A proprietary music streaming service Architecture : x86_64 ... Installed Size : 272.79 MiB So at least it's smaller than Slack.

I have a noob question, but how do proprietary apps (IE: Slack) make it onto the AUR without having an official binary?

Both Slack and Spotify do provide Linux versions, even if not/less supported officially.

Re: Ask HN: Is there still a place for native desktop apps?

#167
post #95

Native desktop apps already are one of those fields that very few people can master. Such niche will probably become super lucrative in the upcoming years.

They're not that hard. They're just unfamiliar to Unix command line users. A lot of people managed to write desktop apps in Delphi, Cocoa, and Win32 for many years.

Re: Ask HN: Is there still a place for native desktop apps?

#168

I'm going to be slammed for using these two words, but for any real work you need to have as few layers of indirection between the user and the machine as possible, and this includes the UX, in the sense that it is tailored to the fastest and most comfortable data entry and process monitoring. I don't see any `web first` or Electron solution replacing Reaper or Blender in a foreseeable future. One exception I'm intri…

Blender in the browser. Ugh.

Re: Ask HN: Is there still a place for native desktop apps?

#169

I'm going to be slammed for using these two words, but for any real work you need to have as few layers of indirection between the user and the machine as possible, and this includes the UX, in the sense that it is tailored to the fastest and most comfortable data entry and process monitoring. I don't see any `web first` or Electron solution replacing Reaper or Blender in a foreseeable future. One exception I'm intri…

VSCode uses a C++ backend to get that performance.

I think you're confusing Atom and VS Code.

Re: Ask HN: Is there still a place for native desktop apps?

#170

I make a living developing software only available on Windows and macOS. That said, if I didn't need to interact so much with the operating system, I'd be making a web app. It all depends on what you want to make though. Video editing software? Native app. CRUD app? Web app. You may also want to consider pricing implications of both. Desktop software can usually be sold for a higher up front cost, but it's tough sell…

I understand the concept of making a native app to include using the native UI platforms. What you described is hardly more native than electron, which is basically a web app at heart. Or maybe there needs to be a consensus on terms. Do people consider electron apps to be native? I would put them in some weird middle ground, but definitely closer to web technologies than native development.

From a capabilities point of view, they're native. You can access the OS api just like any other native app.

From a developer side, it looks like developing a webapp without the usual limitations of API access, albeit at an extra cost of marshaling or build-complexity.

There really is no reason to think of HTML/CSS/JS as Web only though.

Post reply on HN