Live data from Hacker News

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

news.ycombinator.com

451–460 of 777 posts

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

#451

Earlier quoted context omitted.

Qt may not 'look' native, but it has native performance, whereas Electron really doesn't.

VSCode is indistinguishable from native, so not sure its Electron that's at fault here.

On Mac, VSCode does a better job than many apps at emulating the Cocoa text input systems but, like every electron app, it misses some of the obscure corners of cocoa text input system that I use frequently.

If we’re going to use JavaScript to write native apps, I’d really like to see things like React Native take off: with a good set of components implemented, it would be a first class environment.

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

#452

As a long-time Win32 developer, my only answer to that question is "of course there is!" The efficiency difference between native and "modern" web stuff is easily several orders of magnitude; you can write very useful applications that are only a few KB in size, a single binary, and that same binary will work across 25 years of OS versions. Yes, computers have gotten faster and memory and disks much larger. That does…

> As a long-time Win32 developer, my only answer to that question is "of course there is!"

As a long-time Linux user, that's what I say as well.

And as a privacy activist, that's what I routinely use.

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

#453
post #415

Earlier quoted context omitted.

The first clue is a text editor that uses 180mb of ram :)

For comparison, I just opened up an org-mode file in Aquamacs (Emacs with macOS native GUI) and it weighs in at 105MB, which is actually lower than I would have guessed.

I am running Emacs on macOS, and it only takes 43 MB barebones, and my regular setup takes about 81 MB. Both opening the same org-mode file. Point being that it really depends on what you choose to run on Emacs, and it does not have to be about 100 MB.

Just to add to that, I don't think anyone should be concerned about their text editor taking 200 MB anymore. I doubt it is worth worrying about.

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

#454
post #427

Earlier quoted context omitted.

You are looking back at the past with rosy goggles. What I remember from the time was how you couldn’t run that many things simultaneously. Back when the Pentium II was first released, I even had to close applications, not because the computer ran out of RAM, but because the TCP/IP stack that came with Windows 95 didn’t allow very many simultaneous connections. My web browser and my chat were causing each other to er…

FWIW i do not remember having issues like that, i had mIRC practically always open, a web browser, email application, etc and i do not remember ever having networking issues. Internet was slow but that was largely because for the most part of the 90s i was stuck with a very slow 2400 baud modem - i got to appreciate the option that browsers had to not download images by default :-P. But in general i do not remember b…

Me neither, I'm not going to lie and say that I had 40 applications opened, but I DID have 5-10 apps using the web with 0 issues (A browser+IRC App + Email Client+MICQ+MSN Messenger+Kazaam/Napster+Winamp in stream mode).

Very very few of the web and desktop applications of today are as snappy and user-friendly as classic Winamp.

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

#455
post #406

Earlier quoted context omitted.

What is a desktop-class app?

One that can read and write files and directories among other things. (Not an electron fan, but web pages are still pages, not real apps.)

There's a web API for that! https://web.dev/native-file-system/

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

#456

Native desktop apps are great. The reason that people don't write them is because users aren't on "the desktop". "The desktop" is split between OS X and Windows, and your Windows-app-compiled-for-Mac is going to annoy Mac users and your Mac-app-compiled-for-Windows is going to annoy Windows users. Then you realize that most users of computing devices actually just use their phone for everything, and your desktop app…

Or you could use languages that allow you to share code, so you have 6 thin native UI layers on top of a shared cross-platform core with all the business logic and most interactions with the external world.

You can do it today with C# and https://www.mvvmcross.com/

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

#457

Earlier quoted context omitted.

So you are telling me that I can easily exchange development time which I would have to pay for end-user resources, which I would not have to pay? Sounds like a great deal.

In a fair society it should be taxed as an externality. There is a real environmental cost associated with software bloat.

In a fair society closed software would be illegal and people wouldn’t tolerate this kind of stupidity.

No need to hack it with taxes.

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

#458
Native applications will always have an edge, because they can do several things that are difficult or impossible in a browser:

1) Rich key combo support. When running your app inside a browser, many key combos are reserved by the OS (and they differ by OS), and many are reserved by the Browser (and they differ by browser). As a result, your app has to avoid a huge number of key combos, because some OS or browser uses those.

2) Latency. It's not impossible to make a fast web app, but you're already at a disadvantage, due to the inherent overhead of the browser and JS runtime. Put it this way: making a user experience that feels slow and sluggish in a native app requires a lot more mistakes than doing the same thing in a webapp.

3) Filesystem support. It's just better with native. Especially on Windows where you can fully customize the file-open dialog box with app-specific business rules and warnings.

4) Hardware. You'll always be at the mercy of the underlying browser's support for hardware. Need to allow the user to switch between sound devices? This is easy with a native app, but it may require going to the browser control panel if you're a webapp.

5) Leaky abstractions. As a user, I want to open an app and do everything inside of that app. When using a webapp, I may have to fiddle with browser settings, key combos may break me out of the immersion as I accidentally open some browser toolbar or help feature, and the browser toolbars and window is always there to distract me.

6) Updates. With a desktop app, it can show me an alert when it's time to update, and I can choose to update now, or do so later. With a webapp, the updates are normally locked to a browser refresh (I need to refresh the page to get the update, and the update will happen whether I want it or not once I reload). Sometimes, the app decides it's time to update and just force-reloads itself (in the case of an app window I've left open for too long - days or so, while working on something important).

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

#460
post #150

Earlier quoted context omitted.

As an Electron hater, I’m constantly surprised at just how much VS Code doesn’t suck.

My personal evolution has gone from Sublime Text 3 to Atom to VS Code to Sublime Text 3. I've never been a heavy plugin user, mainly sticking to code highlighting. The thing I really like is speed. Sublime Text rarely chokes on me. I love being able to type `cat some_one_gigabyte_file | subl` and getting it to open up with little difficulty. VS Code chokes on files of non-trivial size, and that was the thing I liked…

>> VS Code chokes on files of non-trivial size

VS Code isn't really designed as a general purpose text editor. It's meant as a development environment.

If MS choose to optimise the experience of 99% of the use cases (i.e. editing source code, which should never even approach 1GB), then that's the correct call IMO.

>> For anyone wondering why I'd open up a 1 GB file in a text editor, I guess the answer is largely because it's convenient.

I can completely appreciate the use of a text editor to open a massive log file, etc, I just don't think that's something VS Code is designed for. You can always use Sublime or Atom to open those files; while getting the nicer (IMO) dev experience with VS Code.

Post reply on HN