See, everyone likes to complain about electron but when I did a market study asking “would you pay for a full-featured native Slack app that was lightweight and designed with functionality in mind” the answer I got was mainly “yeah but no.” As best as I can figure, it was mainly feeling they were entitled to it for free as it’s what Slack should have developed, so they were not about to pay to correct a mistake they’…
Ask HN: Is there still a place for native desktop apps?
111–120 of 777 posts
Re: Ask HN: Is there still a place for native desktop apps?
#112Yes.
Re: Ask HN: Is there still a place for native desktop apps?
#113Not having a real native desktop player is why I won't subscribe to Spotify. When I'm going to use something more than lightly, I hate using applications that feel like web tech. But I realize I'm in the minority.
Reads comment. Cocks head, curiously. Closes eyes, listens to the music coming from his computer. Opens eyes, alt-tabs to the Spotify app. Closes all web browsers. Music continues, uninterrupted except by ads. Shrugs, goes on with his day.
Re: Ask HN: Is there still a place for native desktop apps?
#114Every single app that I use, I try and make sure it is native. I shun electron apps at all cost. It's because people who put in effort to use the native APIs put in a lot more effort in the app in general based on my anecdotal evidence. It is also more performant and smaller in size, things that I cherish. It also pays homage to limits and striving to come up with new ways of overcoming them, which hackers would have…
Slack desktop app is almost 1 gig in size. On a whim I just checked how big the copy of Adium still lingering in my Mac is: 60 megs. And Ripcord (a native discord/slack client) is a mere 40.
How big is Spotify now?
Re: Ask HN: Is there still a place for native desktop apps?
#115The app code is delivered by a web server and runs entirely in the user's browser and with service workers configured it runs offline too.
Personally, I think it would be cool to have a sort of secure "runtime engine" on the client side that could manage permissions to system functions for client side web apps.
Re: Ask HN: Is there still a place for native desktop apps?
#116Earlier quoted context omitted.
Speed in relative terms means that JavaScript in the browser is not fast. The language runs on top of just about as many abstraction layers as possible and I do not envy this world you describe. I wish we’d move away from it.
But it's fast enough . JIT compilation means algorithms run decently fast, and when it deals with the DOM it's fast enough for everyday interface tasks. Nobody's saying it's elegant. But it's cross-platform and it's a standard that lots of people know. Wishing we move away from it seems like a lost battle at this point -- at least unless we somehow invent a brand-new computing paradigm that replaces browsers, the way…
Re: Ask HN: Is there still a place for native desktop apps?
#117Every single app that I use, I try and make sure it is native. I shun electron apps at all cost. It's because people who put in effort to use the native APIs put in a lot more effort in the app in general based on my anecdotal evidence. It is also more performant and smaller in size, things that I cherish. It also pays homage to limits and striving to come up with new ways of overcoming them, which hackers would have…
It is true that there is a a correlation between lower level programming and better programming in general. You probably won't see someone writing asm but creating crazy O^2 algorithms that run on every frame with memory allocations that run in the inner loop. At the same time a native win32 program can pack significant functionality into a 20KB exe. Put these together and you have a program where everything is insta…
Yes, lower-level languages allow for programs with good performance, small executables, and so forth. There are many domains where they are clearly the way to go.
But higher-level languages allow for better safety, tremendous productivity, portability, exploration, and flexibility.
If you keep your data in an SQL database and you can easily query and update it in any number of ways that you didn't initially realize you wanted. If you instead keep it in hand-crafted C structs, you can probably provide awesome performance. for whatever you originally thought you needed. Once your needs go outside of that box, you'll have to spend significant development effort.
The correct choice depends almost entirely on the domain.
Re: Ask HN: Is there still a place for native desktop apps?
#118Earlier quoted context omitted.
Slack desktop app is almost 1 gig in size. On a whim I just checked how big the copy of Adium still lingering in my Mac is: 60 megs. And Ripcord (a native discord/slack client) is a mere 40.
And Winamp is 4MB (after removing the stock plugins that I don’t need, like modern skins and the long-broken media library internet lookup stuff). How big is Spotify now?
$ pacman -Qi spotify
Name : spotify
Version : 1:1.1.10.546-4
Description : A proprietary music streaming service
Architecture : x86_64
...
Installed Size : 272.79 MiB
So at least it's smaller than Slack.Re: Ask HN: Is there still a place for native desktop apps?
#119I prefer well-designed desktop applications to web applications for most things that don't naturally involve the web: * Email clients (I use Thunderbird) * Office suites * Music and media players * Maps * Information managers (e.g., password managers) * Development tools * Personal productivity tools (e.g., to-do lists) * Games As Windows starts on-boarding their unified Electron model (I can't recall what they have…
Thunderbird isn't a native app, for the record. It's a web application similar to an Electron application, but with extra steps.
Re: Ask HN: Is there still a place for native desktop apps?
#120We're building POS applications for major retailers, and for this kind of software, native is king and will stay for the foreseeable future (with a few exceptions confirming the rule, of course). These applications need tight integration with exotic hardware, must satisfy weird fiscal requirements often written with native applications in mind, must run rock-solid 24/7 with daily usage and predictable response times…