Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

671–680 of 777 posts

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

#671

Post by AnIdiotOnTheNet »

pjmlp wrote: post #538
roca wrote: post #481

Earlier quoted context omitted.

Go achieves those low pause times by allocating 2x memory to the heap than it's actually using. There's no free lunch with GC.

Same applies with manually memory management, you get instead slower allocators unless you replace the standard library with something else, and the joy of tracking down double frees and memory leaks.

I don't think that's as hard as you make it out to be. Notably, Zig does not have a default allocator and its standard library is written accordingly, making it trivial to ensure the use of the appropriate allocation strategy for any given task, including using a debug allocator that tracks double-free and memory leaks.

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

#672

Post by arvinsim »

gindely wrote: post #660
thdrdt wrote: post #542

Earlier quoted context omitted.

I recently had to upgrade my RAM because I have Spotify and Slack open all the time. Today RAM is cheap but it is crazy those programs take up so much resources. Another program I use a lot is Blender (3D software). Compared to Spotify and Slack it is a crazy complicated program with loads of complicated functionalities. But it starts in a blink and only uses resources when it needs to (calculations and your 3D model…

> But now I had to upgrade my RAM. But I can't. My ram is soldered on. How many tons of carbon dioxide should I emit so that you can use React? There are ways to do declarative ui/state management without dom...

If carbon footprint is that important to you, maybe you should find ways to encourage companies not to solder on RAM instead.

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

#673

Post by arvinsim »

TeMPOraL wrote: post #657
quietbritishjim wrote: post #638

Earlier quoted context omitted.

> I also think it has to do with the fact that older programmers now more about the cost of resources than younger programmers do. I'm not convinced it's the programmers driving these decisions. Assuming that it takes less developer effort - even just a little - to implement an inefficient desktop application, it comes down to a business decision (assuming these are programs created by businesses, which Spotify and S…

> In other words, so long as consumers prioritise functionality over the efficiency of the program, it makes good business sense for you to prioritise that too. And the kicker is, consumers don't have a say in this process anyway. I don't know of anyone who chose Slack. It's universally handed down onto you from somewhere above you in the corporate, and you're forced to use it. Sure, a factor in this is that it works…

> And the kicker is, consumers don't have a say in this process anyway. I don't know of anyone who chose Slack. It's universally handed down onto you from somewhere above you in the corporate, and you're forced to use it.

The consumer here is the business itself, not their employees.

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

#674

Post by TeMPOraL »

arvinsim wrote: post #673
TeMPOraL wrote: post #657

Earlier quoted context omitted.

> In other words, so long as consumers prioritise functionality over the efficiency of the program, it makes good business sense for you to prioritise that too. And the kicker is, consumers don't have a say in this process anyway. I don't know of anyone who chose Slack. It's universally handed down onto you from somewhere above you in the corporate, and you're forced to use it. Sure, a factor in this is that it works…

> And the kicker is, consumers don't have a say in this process anyway. I don't know of anyone who chose Slack. It's universally handed down onto you from somewhere above you in the corporate, and you're forced to use it. The consumer here is the business itself, not their employees.

Technically yes (well, the customers, not consumers), but that's the problem itself: the feedback pipeline between end-users and producers is broken because the end-users aren't the customers.

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

#675

Post by oneplane »

userbinator wrote: post #396

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…

While true, it also had plenty of limitation. You have to keep carrying around a huge legacy, you're locked in to the APIs, SDKs and operating systems of a single vendor, often locked themselves to a single type of hardware.

The win32 code doesn't run anywhere, except on Windows, but most of the compute devices are mobile (non-laptop) systems and those don't come with Windows.

Running your native apps now takes both less work and more work: you can write (Somewhat) universal code but the frameworks and layers required to get it to build and run on Windows, macOS, Linux, iOS, Android, and any other system the market you target relies on now comes in as a dependency.

It used to be that the context you worked in was all you needed to know, and delivery and access was highly top-down oriented meaning you'd have to get the system (OS, hardware) to run the product (desktop app). That is no longer the case as people already have a system and will select the product (app) based on availability. If you're not there, that market segment will simply ignore you.

That is not to say that desktop apps have no place, or that CEF is the solution to all the cross-platform native woes (it's not, it's the reason things have gotten worse), but the very optimised and optimistic way to writing software from the 90's is not really broadly applicable anymore.

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

#676

Post by KaoruAoiShiho »

boardwaalk wrote: post #294
KaoruAoiShiho wrote: post #219

Earlier quoted context omitted.

VS Code is slow at basic things like having characters show up on screen after hitting the key. It's good at everything else though so that lag doesn't matter as much.

It probably depends on your hardware. I have an "older" (several years at least) Windows work laptop with iGPU that is quite sluggish with VS Code when hooked up to an external 4K display. However, it's snappy compared to Microsoft Teams in the same situation. Meanwhile, my similar era MacBook with dGPU hooked up to the same screen is very snappy and I honestly would probably not be able to tell the difference in a b…

I'm using a 5K iMac with Radeon Pro 580 8 GB. I'm making the comparison vs Sublime Text which has no lag and is my standard.

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

#677

Post by KaoruAoiShiho »

slightwinder wrote: post #611
KaoruAoiShiho wrote: post #219

Earlier quoted context omitted.

VS Code is slow at basic things like having characters show up on screen after hitting the key. It's good at everything else though so that lag doesn't matter as much.

On a real system or just in some syntetic benchmark? Because for me it looks quite fast in barfing out characters. At least in base-mode. It can becoming slower when the IDE-features kicks in and autocomplete needs some time to meditate about the stae of it's world. But this also scales with size of your active sourcecode, the codebase and used language. Also, this is some problem of all IDEs, not exclusive with VS C…

I'm using a 5K iMac with Radeon Pro 580 8 GB. I'm making the comparison vs Sublime Text which has no lag and is my standard. This is based on my experience, not benchmarking, just try it side by side and you'll see.

My Sublime Text is decked out in plugins and so on too, there are instances where it slows down but only when it's obviously doing some processing. The basic rendering is fast, totally unlike vscode. But like I said vscode is still "fine" just uncomfortable.

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

#678

Post by gindely »

quantummkv wrote: post #631
alexchamberlain wrote: post #557

Earlier quoted context omitted.

I guess the question becomes: what is the native ecosystem missing that means devs are choosing to deliver memory/CPU hungry apps, rather than small efficient ones?

HTML, CSS and Javascript. Most of these electron apps are basically wrappers around actual websites to give a place in the dock and show notifications and access the filesystem.

But that isn't what's missing. It's a restatement of the problem. DOM based apps are much more resource intensive than native. What is missing from native that makes business choose DOM?

If there was some modern tool like WxWidgets that supported modern apis like DOM, Android and UWP, would we see more use of native? Electron would therefore become pointless.

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

#679

Post by dmitrybrant »

_bxg1 wrote: post #505
dmitrybrant wrote: post #217

I specialize in data recovery / digital forensics tools, which require very low-level disk access to be able to read physical media at the block level. I doubt there will ever be an HTML5 standard for low-level disk access. But aside from my particular specialty, I also prefer any other software I use to be fully native. I'm surprised that's such a controversial thing to ask for these days. All I ask is so precious l…

> I doubt there will ever be an HTML5 standard for low-level disk access. It's clear you've never worked with Electron; nothing about its system-level access has anything to do with HTML5 or related standards. All of that lives in NodeJS, which offers reasonably low-level APIs for accessing system resources. For cases where that's not enough Node can easily call out to logic written in other languages, either directl…

I don't mean to hate on any particular groups of people, I'm simply a proponent of using the right tools for the job.

I can only speak from my own experience, but I have never dealt with an Electron app that wasn't noticeably slower than other apps, to the point of standing out like a sore thumb.

Or, put another way, when I notice an app performing especially slowly, I think to myself, "that's probably an Electron app", and I'm usually right.

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

#680

Post by openfuture »

sbergot wrote: post #529
ridiculous_fish wrote: post #519

I will come at this from a different, philosophical perspective: Web apps come from a tradition of engaging the user. This means (first order) to keep people using the app, often with user-hostile strategies: distraction, introducing friction, etc. Native desktop apps come from a tradition of empowering the user. This means enabling the user to accomplish something faster, or with much higher quality. If your app dis…

What a perfect HN reply. Webapp bad. Native good. No justification. Just a bunch of generalizations. Gmail empowers me. Wikipedia empowers me. Github empowers me. Of course native application are important. You don't need to rely on those moralistic justifications.

Worst thing that ever happened to HN was self-awareness, now your comment is worse than if it had just focused on what he was saying rather than where he said it and my comment is also worse because I included this paragraph. We should probably ban mentioning that this is HN on HN.

He said something like "OS apps have the quality of being windows, you can open different windows into the same data" (okay he literally said "bringing knowledge from one app to another" but it can be re-framed as bringing different apps to the same knowledge - which I argue is more characteristic of the "local experience").

Your "refutation" was to list a few web apps that are considered useful.

A more sane way to refute his argument is to talk about open APIs and how you can bring your data into different contexts using these tools as well as GUI web tools like these things for converting file types, making small adjustments to PDFs, GSuite or other tools.

However that refutation falls on its face when you want the window quality; i.e. looking at the same data with different perspectives. The reason is that the computers running these web systems are foreign and disjoint so you are dealing with a distributed system, sometimes you are lucky enough that it was designed to function how you are using it (google suite is this to some extent), however most of the time you have to bring your data to them to use these utilities and then things float out of sync as you move between tools and your Downloads folder fills up with intermediate artefacts.

We are moving back to the local system, and Electron (and those browser APIs for local storage and persistence) are steps in the conversion process. Eventually we will abandon browsers (read: Chrome) altogether in favor of "package management"; something like nix-shell (except secure) has a much more user-friendly social contract while being pretty much the same UI as a browser (but still much much much worse UX). That's where we will end up (some evidence: NLNet is funding the nix-packaging of all the projects they support).

Post reply on HN