Ask HN: Is there still a place for native desktop apps? • Hacker News Board

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

#741

Post by TeMPOraL » Tue, May 19, 2020, 8:42 AM UTC

MivLives wrote: post #730

TeMPOraL wrote: post #655

Earlier quoted context omitted.

It's interesting to compare Ripcord[0] to Slack. Ripcord is a third-party desktop client for Slack and Discord. It has something like 80% of features of the official Slack client and a simpler UI (arguably better, more information-dense), but it's also a good two orders of magnitude lighter and snappier. And it also handles Discord at the same time . -- [0] - https://cancel.fm/ripcord/

I wish so much that 3rd party clients weren't directly against the TOS of Discord. I sorta miss the old days where it seemed like anyone could hook up to MSN/Yahoo/AIM.

I wish that too. More than that, I keep wondering whether there could be a way to force companies to interop, because right now you generally can't, without getting into some sort of business relationship with these companies. That's the problem with services - they take control of interop, and the extent to which interop is allowed is controlled by contracts between service providers.

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

#742

Post by ta17711771 » Tue, May 19, 2020, 8:49 AM UTC

thdrdt wrote: post #542

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…

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…

m.spotify.com..?

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

#743

Post by pjmlp » Tue, May 19, 2020, 8:57 AM UTC

AnIdiotOnTheNet wrote: post #671

pjmlp wrote: post #538

Earlier quoted context omitted.

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.

Has Zig already sorted out the use-after-free story?

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

#744

Post by RMPR » Tue, May 19, 2020, 9:10 AM UTC

eyegor wrote: post #470

outside1234 wrote: post #369

Earlier quoted context omitted.

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

If I recall correctly, Microsoft forked their own version of electron to make vs code feel more snappy. Because normal electron runs like slack.

I don't think so, Microsoft wanted to fork electron in the past to replace Chromium with edgeHTML, but it didn't happen. VSCode is powered by Monaco Editor github.com/microsoft/monaco-editor, and VSCode feels snappier than let's say Atom, probably because of Typescript.

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

#745

Post by RMPR » Tue, May 19, 2020, 9:14 AM UTC

hoseja wrote: post #556

irishcoffee wrote: post #368

Earlier quoted context omitted.

Knowing what I know about Qt and what I've done with it in my day job, it's basically the best kept secret on hn. What they're doing with 6+licensing... I'm not sure how I feel, but from a pure multi-platform framework it really is the bees knees. I've taken c++ qt desktop apps that never had any intention of running on a phone, built them, ran them, everything "just worked. I was impressed.

I just wish it weren't stuck, anisotropically, ~10 years in the past. Maybe Qt6 will be better, but more likely it will be more and more QML.

Since QML uses Javascript it may be their best bet to attract new developers.

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

#746

Post by squiggleblaz » Tue, May 19, 2020, 9:17 AM UTC

hootbootscoot wrote: post #565

hootbootscoot wrote: post #125

Earlier quoted context omitted.

OTOH, if you are using Slack, you probably deserve it :P "The emperor wears no clothes" and all... paying for threaded messaging, hmmm that's up there with To-Do MVC and Hello World in complexity... well, ok it's a bit higher. Not to mention their billing system lol...

not saying you have any choice in the matter of using Slack or not, but I can assure you that Slack software is aware of their bloat and inefficiency and they don't care. The core task Slack is charged with WAS done 2 decades ago with significantly lower resource usage? Why does this matter? because Slack is not your main productivity app (I HOPE) it's just a background process, effectively, most of the time, a commu…

First, you say:

> OTOH, if you are using Slack, you probably deserve it :P

then you say:

> not saying you have any choice in the matter of using Slack or not

Now, I don't actually run Slack nowadays. I run Teams, which sounds like it's efficient since it only uses 600 MiB RAM rather than a full gigabyte.

But the choice between Slack, Teams, and any other product we might use is determined not by the user, but by the company we work for. Companies have a tendency to decide what works without respect to empirical data. Business people are unconcerned with mere technical matters; they optimise for purchase processes.

I think you got downvoted for saying we have any choice in the matter. When you made a valid criticism, your comment fared much better.

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

#747

Post by squiggleblaz » Tue, May 19, 2020, 9:21 AM UTC

smabie wrote: post #325

joshbaptiste wrote: post #251

Earlier quoted context omitted.

Mainly due to them being both more tightly integrated to C++/Python than JS/TS for building desktop apps.

Yeah, but, honest question, why would you want to use JS if you didn't have to? It's like, the worst language possible.

JavaScript is actually not too bad. It lacks static types, but Typescript gives you one of the better type systems. But I'd take JavaScript over PHP or Bash any day of the week and twice on Fridays.

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

#748

Post by bwindels » Tue, May 19, 2020, 9:41 AM UTC

I share the frustration with everything moving to slow and bloaty electron apps.

But wrt to electron apps and using web technology instead of native frameworks, I think it depends a lot as well how well the web code is designed. I've been prototyping a Matrix chat app [1] in a very minimalist way:

- no framework or library used for UI, "state", ... to have complete control on how and when things are updated and rendered.

- use indexeddb optimally to keep as little things in memory as possible.

My 2 main conclusions from this are:

- Web technology can perform very well. The chat client uses only 3.5mb of Javascript VM memory on a 200 room account. It visually outperforms some native apps as an installed PWA on Android on a low-end device. I attribute this to the fact that web browsers are very optimized.

- It takes more time to engineer an app properly like this, even in a language like javascript. I can imagine it's hard to justify the expense, when most people don't know who to blame when their computer is slow.

1: https://github.com/bwindels/brawl-chat

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

#749

Post by Decade » Tue, May 19, 2020, 9:41 AM UTC

acqq wrote: post #739

Decade wrote: post #723

Earlier quoted context omitted.

> That explains your inaccurate perspective. Yep, you really succeeded at empathy, there. /s > reasonable price range The word “reasonable” is doing a lot of work, here. Most Pentium II systems were not running Windows NT. They were running Windows 95 or 98, which had arbitrarily severe limitations and lacked memory protections. So, while it was technically possible to run lots of applications simultaneously on 256 M…

> Most Pentium II systems were not running Windows NT. They were running Windows 95 or 98 Once again: only somebody using a computer not selected for serious development used Windows 95 and 98. No developer who knew what he was doing was using Windows 95 and 98 as his primary development machine. So if you complain about that, you used the wrong tool for your work. Like I've said, it was easy to install Windows NT, a…

I think we’re losing the plot. The ggp post was about doing all sorts of Internet programs at the same time on Pentium II era computers, and now you’re talking about developer tools on a Pentium 4.

Maybe it’s simultaneously true, that you could run many developer tools at the same time on Windows NT with hundreds of dollars of RAM, and attempting to run a bunch of consumer network programs at the same time (especially on consumer Windows) was asking for trouble.

I remember one of the attractions of IE 5 back in the day was how each newly launched window was its own process (not windows opened by the open link in new window menu option), so unlike Mosaic and Netscape, a crash in one copy of IE did not necessarily bring down all the other windows. Multiple windows being useful because surfing with a modem was slow regardless of CDN. Remember when Yahoo was scandalous, because banner ads took so much bandwidth?

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

#750

Post by julosflb » Tue, May 19, 2020, 10:32 AM UTC

One trivial benefit of web app worth to be considered is that they do not require installation. When targeting business users, this can big a big plus as it turns out that installing/running unknown software in corporate environment is usually not permitted. Most users will give up testing if it requires getting IT to install the software.