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?

#581

Post by [deleted] » Mon, May 18, 2020, 8:20 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…

[deleted]

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

#582

Post by soapdog » Mon, May 18, 2020, 8:23 AM UTC

In my opinion, I suspect that many people shipping electron-based apps would gladly switch to a native toolkit if there was a dead easy way to develop cross-platform GUIs.

In the 90s and early 00s, there were many easy language products like Delphi, VB, and others who were much easier to use than C++ and friends. Cross-platform could be done with REBOL, REALBasic (aka Xojo), Runtime Revolution (aka LiveCode) and many other languages. Users didn't expected fancy flat animated user interfaces made of 100% custom controls, people were fine with normal native standard stuff as long as the app worked.

Now, there is no easy way to build cross-platform apps that is easier than electron. Languages like modern C++ and Rust are extremely powerful but they require more experienced developer to be used effectively. GUI toolkits like Qt and wx, are good but a ton of UX professionals now are trained to ship UIs in tools like figma, skewing all the native controls and creating beautiful masterpieces that are easier to do with HTML/CSS than implement with a native toolkit.

Native apps got harder to do not because we don't have access to the tech we had, but because of added friction. It is like death by a thousand paper cuts. You make the professionals designing the UX/UI create interfaces that are harder to reproduce with native technology, then you select a GUI toolkit such as Qt/wx and try to reimplement that using whatever language is best. It takes longer than developing an electron app, requires more expensive developers. Don't get me wrong, it will be a better product, but it will take longer, be more expensive, and will need to be done with more care. And after the app is done, there is the need to deal with all the sandboxes and crazy stuff that Apple requires these days if you're shipping a native mac app. Many electron apps sidestep a lot of this by simply being thin clients for some SaaS company and doing the hard stuff on a server (which also opens an opportunity for mining the data for our capitalists overlords).

The barrier for entry for developing an electron app is so low. JS is an easy language to start. There are so many ready made UI kits. You can have a small app running before a new developer can understand how the new pointer stuff work on modern C++.

All that text is to say that I think we need easier languages and toolkits that target native experiences. Something like Lazarus, LiveCode, are all steps in the right direction for me.

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

#583

Post by kristiandupont » Mon, May 18, 2020, 8:27 AM UTC

camccar wrote: post #246

psds2 wrote: post #212

Earlier quoted context omitted.

VSCode, because of electron, doesn't allow you to have multiple windows that share state while working on a project. This makes it terrible with multiple screens.

It’s not because of electron. They could have multiple windows but it would be a massive over haul of the architecture . So they say just use another instance

I would argue that it is, because Electron doesn't allow you to share a js context across windows. So while it is not impossible, it is much more involved than it would be in most other frameworks. In fact, this is my only gripe with Electron where I think the normal HN objections about performance, bloat and lack of native UI elements are overstated and not something that bothers me.

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

#584

Post by kristiandupont » Mon, May 18, 2020, 8:28 AM UTC

KaoruAoiShiho wrote: post #219

ZoomZoomZoom wrote: post #144

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…

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.

That lag matters to me, but in my experience it's no worse than, say, VIM with the number of plugins that I normally run. Fully bare-bones I imagine vscode is performant as well.

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

#585

Post by thu2111 » Mon, May 18, 2020, 8:29 AM UTC

tjoff wrote: post #539

mlwiese wrote: post #445

Earlier quoted context omitted.

There is movement away from stop-the-world GC, but not to reference counting. The movement is towards better GC. The language Go has sub millisecond GC with multi-GB heaps since 2018. See https://blog.golang.org/ismmkeynote Java is also making good progress on low latency GC. Reference counting can be slower than GC if you are using thread safe refcounts which have to be updated atomically. I don't want to have to th…

Yet we still read articles and threads about how bad the Go GC is and the tradeoffs that it forces upon you. I get the feeling that the industry is finally starting to realize that GC has been a massive mistake. Memory management is a very important part of an application, if you outsource that to a GC you stop to think about it. And if you don't think about memory management you are guaranteed to end up with a slow…

The Go GC isn't that great, it's true. It sacrifices huge amounts of throughput to get low latency: basically a marketing optimised collector.

The new JVM GCs (ZGC and Shenandoah) are more sensibly designed. They sacrifice a bit of throughput, but not much, and you get pauseless GC. It still makes sense to select a throughput oriented collector if your job is a batch job as it'll go faster but something like ZGC isn't a bad default.

GC is sufficiently powerful these days that it doesn't make sense to force developers to think about memory management for the vast bulk of apps. And definitely not Rust! That's one reason web apps beat desktop apps to begin with - web apps were from the start mostly written in [pseudo] GCd languages like Perl, Python, Java, etc.

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

#586

Post by monadgonad » Mon, May 18, 2020, 8:30 AM UTC

riquito wrote: post #552

smileysteve wrote: post #494

Earlier quoted context omitted.

95% of a market that has shrunk nearly 50% over the last decade. In many ways, the consumer and non specialty business are post desktop. Turns out documents, email, and other communication apps cover 90% of use cases. Anything that requires major performance gets rendered in a cloud and delivered by these other apps.

You live in a bubble, Windows still dominates desktop (obviously, most people can't afford a Mac and the year of Linux on desktop has not come yet) https://gs.statcounter.com/os-market-share/desktop/worldwide

They're not refuting that. They agreed that it's "95% of the market." Their point is that the overall desktop has shrunk, regardless of Windows's share of that.

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

#587

Post by jtwigg » Mon, May 18, 2020, 8:32 AM UTC

God I hope not. Web apps have come a long way. Some SPAs I've used feel native and provide just as good as an experience as any desktop app. Having said that, I feel that (IMO) a well designed desktop app is just more pleasant to use than any web site. I've written software for both scenarios and I enjoy developing native desktop apps over websites so I am probably biased in that respect.

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

#588

Post by kristiandupont » Mon, May 18, 2020, 8:33 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.

I would pick writing JS over C++ any day. Of course, that's just my opinion. I am sure yours differs.

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

#589

Post by inapis » Mon, May 18, 2020, 8:33 AM UTC

meritt wrote: post #503

outside1234 wrote: post #369

Earlier quoted context omitted.

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

Try opening a moderately large (even 2MB) .json file in VSCode, and then do the same in sublime. VSCode very quickly freezes because it cannot handle a file that size. Sublime not only opens it but syntax highlights immediately.

This is something with your configuration. OOB VSCode will immediately show you the file but disable tokenization and certain other features. I regularly open JSON files upto 10 MB in size without any problem. You probably have plugins which impede this process.

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

#590

Post by innocenat » Mon, May 18, 2020, 8:33 AM UTC

jotm wrote: post #551

Decade wrote: 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…

Most of those have nothing to do with OP's point, which is that some software uses way too much processing power than it should. While on the topic, let's remember the speech recognition software available for Windows (and some for Android 2.x) that was completely offline and could be voice activated with, gasp , any command! Google with its massive data centers can only do "OK/Hey Google". Riiight. I can't believe t…

What was the software name, if I may ask? I remember speech recognition pre-CNN to be quite terrible.