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

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

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

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-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) 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!

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.

Now your apps is resembling a native app, but a whole lot more complicated.

> Cordova makes it easy to build bridges through plugins.

Everyone I've talked to who went down this path regretted it.

> Moreover this promotes proper separation of concerns which lets you use the SAME view layer on different platforms, changing only the "client api bindings".

Except views are ultimately platform dependent. You've created a leaky abstraction.

> Business reality you say? Well at least for mobile, it's this: http://blog.venturepact.com/8-high-performance-apps-you-neve....

That article lists Twitter, which is wrong. I was the tech lead.

(It's also wrong about half the other apps on the list)

How big is the iOS team at Twitter? This is old picture (https://pbs.twimg.com/media/BYBiL8MCUAAiB7r.jpg)