Live data from Hacker News

Why we maintain desktop apps for OS X, Windows, and a web application

medium.com

71–80 of 95 posts

Re: Why we maintain desktop apps for OS X, Windows, and a web application

#71

Considering the performance of Atom, is it a good idea to build desktop apps with Node.js?

Atom's performance problems are not because of Node, they're because they render with HTML, loading your whole text documents into the DOM as hundreds of thousands of separate elements. Using Node JS as the backend to a proper native rendering system would work fine, and in fact if the application was written to properly handle everything asynchronously, it may well be faster than an app written entirely in the nativ…

> it may well be faster than an app written entirely in the native language of the system.

So nodejs is now faster than C/C++? I guess Javascript really can do everything.

Re: Why we maintain desktop apps for OS X, Windows, and a web application

#72

What I don't like is WebView distributed as a "native app". It's not native app and it's not something I want to install, don't cheat me. Webpages should stay in browser. I expect native app to be written with Objective C (OS X/iOS user here), having very low memory usage, fast startup and offline usage. Also I expect as much integration with the system, as possible, native controls (not that buggy emulation without…

This is what I hate about Slack. It feels like a webapp inside of a very thin wrapper.

This is not problem of slack in webview. This is problem of slack. Actually interface in OSX is slower that web view. If you compare optimized Web app and OSX Native app, you will spot difference. Slack is just not optimized.

You can to check our own messaging to it's speed at our old hacker news thread: https://news.ycombinator.com/item?id=9757243 It is faster than native apps.

Re: Why we maintain desktop apps for OS X, Windows, and a web application

#73

The alt-tab argument is a strong reminder for me that as good as tabbed browsing is compared to the old IE6 hell, tabs are an absolutely shit paradigm for window management, better than the windows task bar when you have 100 tabs open, but it is about time someone sat down and did real and serious UI research on how to deal with having 100s of windows open at the same time, because my solution of having 32 virtual de…

are you using Windows 10? I'm wondering if the virtual desktops feature was going to make my life easier managing tons of windows. Your comment doesn't sound very encouraging.

Re: Why we maintain desktop apps for OS X, Windows, and a web application

#74
post #70

Earlier quoted context omitted.

So, you don't use any browser apps? That must be pretty hard to do. I think going without a browser+javascript would be pretty primative... I mean, I pay my bills, send emails, hell view the site I'm on as browser applications. I remember being online in 1993 (vga, bbsing, dialup ftw), it wasn't nearly as diverse or capable as today.

> So, you don't use any browser apps? That's not at all what they said. Some of us use browsers that are not chrome. That would mean having to run 2 browser runtimes to get a thin wrapper with chrome.

I believe Firefox has, or used to have the ability to launch a standalone browser without extra chrome for a specific site (maybe not via the UI)... IIRC IE on Windows 7+ offers the same functionality.

If you're using Opera or Safari, I have no idea.

Re: Why we maintain desktop apps for OS X, Windows, and a web application

#75

What I don't like is WebView distributed as a "native app". It's not native app and it's not something I want to install, don't cheat me. Webpages should stay in browser. I expect native app to be written with Objective C (OS X/iOS user here), having very low memory usage, fast startup and offline usage. Also I expect as much integration with the system, as possible, native controls (not that buggy emulation without…

Chrome packaged apps do what your last paragraph is calling for

Thanks, that's an interesting technology. Too bad that it's specific to Chrome and I can't expect any user to run Chrome or install Chrome. But that's a good direction, I only hope that major browser vendors will consider to adapt it or similar standard in the future. It shouldn't take too much resources to implement it, I suppose.

Re: Why we maintain desktop apps for OS X, Windows, and a web application

#76
post #41
post #16

Earlier quoted context omitted.

The desktop application for Slack is basically the same thing as having a dedicated browser window anyway, except probably even heavier-weight, at least in the OS X version. IIRC they use the same JS-on-the-desktop toolkit as Atom, so it's not a desktop application so much as it is a "desktop application". It eats ~400MB(!!!!) of RAM on my laptop at all times and I'm sure the only reason it isn't painfully unresponsi…

V8 has an odd habit of not releasing memory back to the OS after mark-and-sweeps. It's a minor performance boost to let it roll up memory and it isn't uncommon for it to hog up as much memory until a heuristic (or an OS signal) tells it to knock it off.

Apparently "hey, I'm trying to use this 4GB machine for actual work with a couple VMs running and you're driving me in to swap hell" didn't come through as "knock it off".

And that's the story of why I have an 8GB machine now :-/

Re: Why we maintain desktop apps for OS X, Windows, and a web application

#77

What I don't like is WebView distributed as a "native app". It's not native app and it's not something I want to install, don't cheat me. Webpages should stay in browser. I expect native app to be written with Objective C (OS X/iOS user here), having very low memory usage, fast startup and offline usage. Also I expect as much integration with the system, as possible, native controls (not that buggy emulation without…

This is what I hate about Slack. It feels like a webapp inside of a very thin wrapper.

I have to say though, for a webapp packaged in a wrapper it's a very good one.

Re: Why we maintain desktop apps for OS X, Windows, and a web application

#78

Considering the performance of Atom, is it a good idea to build desktop apps with Node.js?

Atom's performance problems are not because of Node, they're because they render with HTML, loading your whole text documents into the DOM as hundreds of thousands of separate elements. Using Node JS as the backend to a proper native rendering system would work fine, and in fact if the application was written to properly handle everything asynchronously, it may well be faster than an app written entirely in the nativ…

Honestly, I've never had a problem with Atom's performance.

The only time it comes up is when one opens an extremely long file which contains one extremely long line of code.

Re: Why we maintain desktop apps for OS X, Windows, and a web application

#79
post #71

Earlier quoted context omitted.

Atom's performance problems are not because of Node, they're because they render with HTML, loading your whole text documents into the DOM as hundreds of thousands of separate elements. Using Node JS as the backend to a proper native rendering system would work fine, and in fact if the application was written to properly handle everything asynchronously, it may well be faster than an app written entirely in the nativ…

> it may well be faster than an app written entirely in the native language of the system. So nodejs is now faster than C/C++? I guess Javascript really can do everything.

No. I said it "may well be", because a naive implementation using a native language may block while doing IO and be less responsive, unable to do other things while waiting for external stuff to happen.

Perhaps I should have said "may well be more responsive than".

Re: Why we maintain desktop apps for OS X, Windows, and a web application

#80
Wow, there's a lot of hybrid hating here.

Consider this though:

• You have an app that doesn't need to perform actions in sub 10-milliseconds. 11 milliseconds is just fine.

• You don't require access to a whole host of system processes, but maybe access to the file system, or the clipboard, would be a big help to your users.

• Your users are not super technical and won't even know what a hybrid app or native app means.

• You want to get your app to market on multiple platforms in days/weeks, not months, and without spending a ton of money.

I think hybrid might be a good option there. Not the ultimate best ever piece of software ever I know, but compromises and all that.

Post reply on HN