9 ms·
Why we maintain desktop apps for OS X, Windows, and a web application
- i_am_so_hungry 11y agoI have just rediscovered the fantastic FreePascal/Lazarus, and have been thinking up desktop app projects to build. Cross-compile to Windows, Linux and OSX with native UI.
- unimpressive 11y agoBad article title. Doesn't even attempt to show a statistical trend that they're 'coming back' (I would argue with the existence of app stores and the like that they never really left). Does talk about the authors experience of offering a desktop app which is very interesting.
- deleted 11y ago[deleted]
- akurilin 11y agoI've been using slack just fine in the browser, haven't had much of a need for a desktop version of it. I can just make a separate chrome instance for it and move it into its own xmonad workspace and switch to it much more conveniently than through alt-tab.
- dharma1 11y agoEven the Slack native app is (or at least used to be) a webview wrapped in a native container
- ashark 11y agoThe 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 unresponsive is because modern machines have enormous amounts of processing power. Totally unreasonable for what it does. Even at that, it's still not as rough on system resources as a browser tab with Asana loaded and left open for a couple days, and all of Google's "applications" are hogs of course. Web Apps: the way of the future! [gag, gag, vomit]
- tlinton 11y agoV8 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.
- ashark 11y agoApparently "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 :-/
- pbreit 11y agoOne anecdote from a power user is rather uncompelling.
- saurik 11y ago> At Front for example, people using the desktop app spend on average 34% more time on the app that those using the web version. ...maybe I'm crazy, but the primary metric I would evaluate a tool designed to increase business productivity is not how much time I spend using it, and in fact would normally be summarized as the exact opposite of this metric...
- gberger 11y agoAlso, correlation/causation. It could be that the people who download the desktop app are already the heavy users.
- prof_hobart 11y agoIn this case, I'm not sure that's an important distinction. Whether it's the desktop app driving increased usage or it's heavy users preferring the desktop app, it suggests that one way or another, the desktop app is better for heavy usage.
- BinaryIdiot 11y agoI don't know that the exact opposite metric would be useful but I agree their metric doesn't sound useful either.
- saurik 11y agoI think the normal summary would be "the new version of our tool has streamlined numerous features, allowing you to spend less time using our app; testing already reports people spend 30% less time"; the implication, though, left out of the summary, is "and accomplish the same things" (which is why it is only summarized as the exact opposite, but the metric, I agree, is not the exact opposite).
- netheril96 11y agoFor entertainment apps such as social networking, games and music, there are no specific goals to achieve, and more time spent the better. I don't know whether that applies to the app in this article, though.
- nsgi 11y agoInstallable webapps cover at least the first two points.
- adrusi 11y agoIf you distribute your app for desktop, users will install it no matter what, but with installable webapps users won't install it until it's already part of their routine. Of course, users are more likely to try out your app if they don't have to go through an installation process first, so it's a tradeoff.
- jayvanguard 11y agoThe bottom line is that if you care about your users and their experience you'll make a native app for them. Everything else is a tradeoff. There are definitely many application areas where the web is effectively their "native" home so that is all you need but I thought this article did a good job of laying out when that isn't good enough.
- DrScump 11y ago"Your users don’t need an authorization to" ... what?
- superfad 11y agoMy guess is she means they don't need authorization to install it if it is a web app, where as a desktop app may need company sign off to install software.
- hobarrera 11y agoIn any case, if a company is using an app like theirs (FrontApp), it would be stupid for IT not to authorize employees to install it. The particular point really doesn't apply to this sort of tools.
- cwyers 11y agoIt's more friction. Instead of waiting for IT to approve something when they get around to it, if in fact they do approve it at all, you can start using it now.
- BinaryIdiot 11y agoI love it when companies make software that I use on my mobile phone and it syncs with a desktop application as well. As a web developer I appreciate web applications but the experience is almost always better in a native application (at least I've found very few exceptions). So I'm happy companies like this still provide desktop applications. It would be great if it were more of a trend but I'm not sure that it is yet. If there were better frameworks to use that would allow code reuse across all platforms it would certainly make this easier.
- gluxon 11y ago> If there were better frameworks to use that would allow code reuse across all platforms it would certainly make this easier. I feel that this is exactly what web applications try to solve in the first place.
- BinaryIdiot 11y ago> I feel that this is exactly what web applications try to solve in the first place. Yeah I think so too but I don't think it really did. Native apps are almost always so much better. The biggest issue is discovery and installation of native applications that make the web more approachable. I'd love to see some better development frameworks that let me use native UI components to build an application that can share business login across iOS, Android, Windows, Mac OS X and even Linux. It's kind of a hard problem though.
- hobarrera 11y agoQt? It's your best shot for native win32/osx/*nix apps, and you can reuse lots of code for the android/ios versions (though you'll have to rewrite the views, of course).
- BinaryIdiot 11y agoWhoa, I've used Qt an very, very long time ago so I knew of its existence but I had no idea they had iOS and Android ports. I'm going to have to look into that. Thanks! Yeah I expect re-writing of views. Honestly I think that's unavoidable and perfectly fine it would just be nice to keep the business logic everywhere I go.
- thoman23 11y agoI'd like to hear a little more about how this "recent technology" that she linked to helps me deploy web apps to the desktop. The http://nwjs.io/ http://nwjs.io/ site certainly doesn't have much info on how it can help for this use case.
- xixixao 11y agoJust one click through and you arrive at the README: https://github.com/nwjs/nw.js https://github.com/nwjs/nw.js (the website is clearly, unfortunately, geared towards people in the know). nwjs (node-webkit formerly) is a Chromium wrapper that lets you deploy web apps as desktop apps, simple as that.
- aroch 11y agoNode-webkit was renamed to nw.js[1], if that helps ring any bells. Its a chromeless browser that you can run your node webapp in, that acts like a application. Similar to Fluid SSBs[2] of yester-year [1] https://groups.google.com/forum/#!topic/nwjs-general/V1FhvfaFIzQ https://groups.google.com/forum/#!topic/nwjs-general/V1Fhvfa... [2] https://en.wikipedia.org/wiki/Fluid_%28web_browser%29 https://en.wikipedia.org/wiki/Fluid_%28web_browser%29
- mohaps 11y agoAtom/Electron stuff from github also allows you to package a HTML5 application as a native desktop app : http://electron.atom.io/ http://electron.atom.io/ kinda like cordova/phonegap for desktop
- codezero 11y agoI've been using Front since February and I love it. The desktop app was one of the key reasons I went with it because it is really fast compared to web interfaces of other apps I tried out.
- vbezhenar 11y agoWhat 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 my favorite emacs-like keybindings) and native behavior. Probably we miss an important piece of technology: installable web-apps. Website opened in the frameless browser window, identifiable as a different application which could be easily pinned to Launchpad. With all advantages that "separate webview" has, but with some important difference: sandboxing. So I can feel safe when I launch this application, because I don't need to trust all my files, passwords and system to another application. I've seen that kind of technology in the iOS: website bookmark could be pinned as a desktop icon, but it's just a bookmark.
- vinkelhake 11y agoLike "Create application shortcuts" in Chrome?
- TD-Linux 11y agoOr app manifests in Firefox?
- r618 11y agoYou mean something like http://fluidapp.com/ http://fluidapp.com/ ?
- zippergz 11y agoThis is what I hate about Slack. It feels like a webapp inside of a very thin wrapper.
- grimgrin 11y agoSlack feels like it should be in the browser for me, as a pinned tab. So at my job that's how I use it.
- hobarrera 11y agoOn the other end, as a user, I greatly prefer desktop apps, because I don't "lose" them as much. It's easy to lose a chat tab between lots of browser windows+tabs. A single IM window is harder to lose. And then there's the integration: both look&feel and functionality can make a huge difference.
- incompatible 11y agoI'd say it surely depends on what the "app" is supposed to do. I like to run Firefox natively rather than as a web app. On the other hand I'll be thrilled when the local tax office convert their Windows/MacOS software to a web app so that I can use it on Linux.
- incompatible 11y ago"Once they find their place in the Windows Start menu or the Mac OS Dock, they are always visible." I don't think this is true anymore in Windows 8+. From my limited experience in using it, once you install something it disappears into a mass of icons and is never seen again. If you can remember the name you may be able to search for it.
- tracker1 11y agoFunny, but on windows/osx/ubuntu I tend to have a half dozen regularly used programs docked on the taskbar... anything else meta/win then type, and click on what I want in the list... so having apps disappear isn't so bad, except maybe for branding, and when I can't find "that app with the stupid name that does X, that I only need twice a year."
- titanix2 11y agoSadly the search is also broken. Not only it often opens too slow so the first letters of the search are not taked in account (the start menu was blazing fast in comparison) but to add insult to injury even Windows builtin programs aren't always displayed in the result search (eg. Powershell ISE). So if you don't know the program exists and don't know its the path, good luck finding it.
- hyperion2010 11y agoThe 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 desktops can't be it.
- batou 11y agoPress alt twice and type in the title for a partial match of the window title. That is all I ask for.
- pknight 11y agoare 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.
- hyperion2010 11y agoNah, fluxbox with custom control scripts.
- alagappanr 11y agoThis approach is probably in complete contrast to what Flipkart/Myntra have been doing in India. Both are widely used e-commerce websites that are going complete mobile-app only by killing even their desktop and mobile websites. Two moves in completely different directions. Would be interesting to see the results down the line.
- ramkalari 11y agoFlipkart's customer base is completely different. A large percentage of their customers will probably never own a desktop let alone access their application on one. Front is an app targeted for business where the users still use desktops where it may make sense to have a desktop app.
- Wintamute 11y agoSlack, Spotify, Atom, React Native ... I think desktop/native apps implemented using web tech have come on leaps and bounds recently. They started off clunky, but are now starting to feel like native software imo.
- rhaps0dy 11y agoA nice insight at the end of the article that I'd never realized (it might be obvious to you). >as long as you browse the web, you keep coming back to google.com to navigate efficiently. This is why Google wants you to spend time in a browser. This is why they offer Gmail for free, Chrome for free, Chromebooks at a loss, or why they fund their own competition!
- avinassh 11y agoConsidering the performance of Atom, is it a good idea to build desktop apps with Node.js?
- BillinghamJ 11y agoAtom'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 native language of the system.
- Tiksi 11y ago> 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.
- BillinghamJ 11y agoNo. 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".
- hollerith 11y agoSo, you don't actually know anything about whether native apps block on IO? (I doubt they do on any modern version of Windows, OS X, Linux, Android, iOS or Windows Phone.)
- BillinghamJ 11y agoDepends entirely on the developer. Most APIs support both non-blocking and blocking.
- jblok 11y agoWow, 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.
- sandofsky 11y ago> You have an app that doesn't need to perform actions in sub 10-milliseconds. 11 milliseconds is just fine. Except you're looking at 3 seconds to power up your cell radio, before you can actually download the HTML. > 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. Until you need more, at which points you're spending all your time extending your hybrid framework. > Your users are not super technical and won't even know what a hybrid app or native app means. They do know "it's slow," in the case of Facebook. > You want to get your app to market on multiple platforms in days/weeks, not months, and without spending a ton of money. Until you spend six months rewriting all your apps. Hybrid apps, on mobile, trade short term gains for long term maintenance nightmares. On the desktop, with a high bandwidth connection, and lots of power, they're less bad. With a well written model layer on an iOS app, maintaining a desktop UI for most apps is the work of one or two developers. Sadly, desktop usage isn't worth it for most consumer facing startups. I've accepted that business reality.
- EGreg 11y agoExcept you're looking at 3 seconds to power up your cell radio, before you can actually download the HTML. You can cache all files in the app bundle with Cordova so the download happens during the install. Until you need more, at which points you're spending all your time extending your hybrid framework. Cordova makes it easy to build bridges through plugins. Moreover this promotes proper separation of concerns which lets you use the SAME view layer on different platforms, changing only the "client api bindings". It lets you truly think through a crossplatform system design AND the business logic of whether you'd like your invited users to start on the web experience and download the app for that + expanded functionality. So it informs your business model as well. They do know "it's slow," in the case of Facebook. When Zuck said that HTML5 was a mistake, Sencha made fastbook demo three years ago to show that facebook could have been sped up and was slow for a different reason. Since then it's been three years and two generations of phones. Things are even better now. https://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/ https://www.sencha.com/blog/the-making-of-fastbook-an-html5-... Until you spend six months rewriting all your apps. Hybrid apps, on mobile, trade short term gains for long term maintenance nightmares. On the desktop, with a high bandwidth connection, and lots of power, they're less bad. With a well written model layer on an iOS app, maintaining a desktop UI for most apps is the work of one or two developers. Sadly, desktop usage isn't worth it for most consumer facing startups. I've accepted that business reality. Business reality you say? Well at least for mobile, it's this: http://blog.venturepact.com/8-high-performance-apps-you-never-knew-were-hybrid/ http://blog.venturepact.com/8-high-performance-apps-you-neve... Hybrid apps have 20% HIGHER RATINGS in the app store than native. Many top companies heavily use WebViews. MacGap is getting better and this will become standard for the desktop, too. Take our own Calendar app for example. It has over 60,000 active users in any given month (http://qbix.com/calendar http://qbix.com/calendar) and having WebViews would SIMPLIFY our port to iOS and Android. Here is what we wouldn't have to rewrite and additionally maintain: 1) The view layer incl all reusable components 2) Caching of view models 3) The server side communication, incl websockets and realtime And we get one more bonus: 4) Invited users can click a link and instantly get an account on the web, after which we can send them transactional notifications until they sign up. As opposed to being taken to an app store with a description, pictures and some ratings. Higher virality for the win!
- itsmillertime4u 11y agoThere are many iOS apps that I wish had equivalent apps on OSX, but sadly they don't. Ones that come to mind are Netflix, HBO Go, Amazon Video, Amazon Music, etc.