Live data from Hacker News

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

news.ycombinator.com

761–770 of 777 posts

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

#761

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.

Where in the terms of service does it say that third party clients are disallowed?

(It doesn’t.)

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

#763

Earlier quoted context omitted.

Current tech is C++/WinRT, for this year, but last year it was WPF and five years ago it was XAML, then previously it was MFC/ATL, and original Win32 somewhere back in the old days. And Linux isn't better. I think OSX is the only desktop OS that has an idea of what an app should look like.

MacOS used to have a choice between Carbon and Cocoa, didn't it? Maybe still does. C++/WinRT uses XAML. But XAML isn't a control library/toolkit. You can tell because it isn't called the Extensible Application Control Library. I'd say it shouldn't be included in your list, but MFC/ATL is just a way of accessing Win32 via C++ -- it makes the same function calls -- so it's not clear that your purpose was to make a fair…

Let's go with a file picker dialog, a simple OS-provided component. Windows provides three versions of this dialog (the "app" view, the tree-view, and the explorer-in-your-app view) depending on which API you use. You see this pattern repeated. It being the same calls "underneath" is true, but it's also irrelevant, as the user experience noticeably changes depending on which API is invoked.

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

#764
post #718

Earlier quoted context omitted.

What do you consider as a specialty business? There are hundreds of millions of professionals - scientists, engineers, accountants, animators, content creators, visual artists, chip design folks, folks writing drivers for equipment, photographers, musicians, manufacturing folks, etc who simply cannot earn a living without native apps. Sure, maybe when those people go home, they don't always need native apps, but IMHO…

You name several that are speciality businesses and are part of that 10%. But there are definitely examples within Accountants, Animators, and Musicians where Phones, Tablets, and Chromebooks (not specialty desktop apps) have taken over the essential day to days. For animators; the Ipad VS. Surface face off is a great example -- also where they offload concepts to "the cloud" to render instead of a Mac Pro.

Well, I am not talking about examples, I'm talking about entire industries. For e.g., There is absolutely no way for my industry (vaccine r&d) to any work without native apps. Even for animators, no native apps = no pixar. Maybe you were thinking of some other kinds of animation. I don't disagree that you can find small examples here and there of people not needing native apps in any industry.

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

#765
post #761

Earlier quoted context omitted.

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.

Where in the terms of service does it say that third party clients are disallowed? (It doesn’t.)

While it does not explicitly state that, it does say:

"(ii) copy, adapt, modify, prepare derivative works based upon, distribute, license, sell, transfer, publicly display, publicly perform, transmit, stream, broadcast, attempt to discover any source code, reverse engineer, decompile, disassemble, or otherwise exploit the Service or any portion of the Service, except as expressly permitted in these Terms;" [1]

Given that the API is not public if you are not using a bot key, I would think that using it with a third party client would take some form of reverse engineering.

The devs also stated that other client modifications like betterDiscord are against the TOS.

[1]https://discord.com/terms (Under Right To Use The Service)

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

#766

Earlier quoted context omitted.

You have to do it anyway if you're using Electron

That's not a web app then.

Isn't it? The UI is rendered using web technologies inside a specialized browser and it's written in a web-specific language. I might consider an electron app an hybrid app (that leans heavily towards the web side), but for sure not a native app

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

#767

Earlier quoted context omitted.

Do you distribute Python with your application too then? How well does that work?

It sounds like a macOS app, and python is distributed with the OS already. Just watch out for Apple trying to take away scripting language support in the future. There's also an upcoming Python version change in macOS 10.16 to look out for.

I actually use py2app to bundle the whole virtualenv into an .app file. Worked pretty much out of the box after fiddling a bit with pyenv (you have to build your python version with framework support).

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

#768
post #654

Earlier quoted context omitted.

It really surprised me when I downloaded Godot only to get a 32MB binary. Snappy as hell. Web apps masquerading as desktop apps are terribly slow and it's a surprise we've got so used to it. My slack client takes a few seconds to launch, then it has a loading screen, and quite often it will refresh itself (blanking out the screen and doing a full-blown re-render) without warning. This is before it starts spinning the…

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/

ripcord is amazing. I bought it right away because in its current form, it's already worth the money

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

#769

Earlier quoted context omitted.

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.

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

foobar2000?

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

#770
post #553

Earlier quoted context omitted.

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.

I still use Winamp for offline music. Nothing else is faster.

I did use foobar2000 for a while and it was quite snappy.
Post reply on HN