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

You can launch chrome with

  google-chrome --app="http://app.com"

And get a frameless window.

Firefox used to have something like this, but it doesn't appear to work anymore. You can do

  firefox -chrome "file:///some/local/file.html" 

But obviously that's not quite the same, and I believe is limited to local files.

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

In chrome I can create application shortcuts... and with browser notifications it pretty much just works. I usually have pandora and slack as application shortcuts that run in their own windows... it really doesn't bug me that they run in a browser... they work as I expect them to (though not in osx iirc). I agree that the thin wrappers are a little annoying...

On the flip side, though I really appreciate that I can create more feature rich applications with the likes of nwjs or electron. There's a lot of things you can do that go a fair bit beyond just web applications in a thin shell... though most of the better ones are app centric first, and web instance second.

I do wish someone would build a nice mail client for Chrome/ChromeOS though... That part really sucks imho. I mean there's a browser based SSH client for chrome, so it's entirely possible to do.

I use the Fluid SSB [1] for the latter. It sandboxes websites that I need to use but are not willing to allow access to my primary browser history/cookie store. It's a little clunky, but it gets the job mostly done.

[1] http://fluidapp.com

Like "Create application shortcuts" in Chrome?

Windows 10 will allow for installable web apps that behave like native (admittedly not much use to an audience that tends heavily toward OS X)

vbehezar what if only the view layer was in HTML/CSS/JS?

How is that different from using gtk or some other gui toolkit?

Chrome packaged apps do what your last paragraph is calling for

Also, correlation/causation.

It could be that the people who download the desktop app are already the heavy users.

You're making the assumption that the people accomplish the same time in the desktop version and the web version.

Given that the desktop version and the web versions are the same, the assumption is that both are at least similarly productive. Therefore the desktop version is actually helping people accomplish more (or it's more useful for high-usage people? Or it's just correlation)

I don't know that the exact opposite metric would be useful but I agree their metric doesn't sound useful either.

Press alt twice and type in the title for a partial match of the window title. That is all I ask for.

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.

> 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.

I'm pretty happy with the approach of common x-plat core and then bindings to the native UI framework (Cocoa, WPF, etc.) on each platform. I'll bite the bullet of rewriting the UI layer for each platform if it means an absolutely great experience, you still save plenty from having that common core. Also, there's the nice side-effect that you end up learning the particulars of each platform, and by necessity end up with a really good architecture.

I do this with C#, not sure how many other languages support this approach. I wish it was all of them.

Sadly 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.

Funny, 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."

Just one click through and you arrive at the README: 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.

Atom/Electron stuff from github also allows you to package a HTML5 application as a native desktop app : http://electron.atom.io/

kinda like cordova/phonegap for desktop

Node-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/V1Fhvfa...

[2] https://en.wikipedia.org/wiki/Fluid_%28web_browser%29

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 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]

Even the Slack native app is (or at least used to be) a webview wrapped in a native container

One anecdote from a power user is rather uncompelling.

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

Why? This is cumulative, across everything in your app. Why are you spending the user's resources on yourself?

> 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.

Native integration is a lot more than access to the clipboard and file system. Drag and drop. Editing key shortcuts. Consistent components.

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

You don't need to be a professional chef to tell the difference between home baked cookies and chips-a-hoy, and you don't need to be highly technical to know that an "hybrid" application doesn't work as well as any of your other well-written apps.

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

Blah. So we'll ship things that suck because it's a better product for us, the person making it? What if shipping genuinely good applications is actually integral to your success?

Remember: MVP is all about reducing the risk to VCs by decreasing the costs to get a product to market, by increasing the risk of a "false negative" market failure due to your shipping a poor product.

If you're that false negative, MVP hasn't done you any good.

> 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.

Flipkart'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.

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 native language of the system.

My 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.

If 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.

Ok, we changed the title to a representative sentence from the article.

Was thinking the same. Even when ajax was getting big, i still recall using a lot of the same programs i did then. A text editor/ide, a browser, desktop games, ms word, etc.