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 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.
This type of app really bites us (users) in the ass when we try things real Mac apps have done literally for decades - drag and drop. Drag a file expecting it to be accepted as an upload, but oh wait no, the web view navigated to view that file. And I have no back button so I have to quit the app.
Maybe I miss your meaning but on OS X/chrome: cmd-shift-T to reopen the last window with all tabs. Works even after a chrome restart. Saves me when 40 tabs open and I Cmd-Q for too long instead of Cmd-W.
Yes, I'm aware of this, but it pretty much means the pinned tab behaves like "any other tab". If I closed those 40 tabs, the pinned tab should move elsewhere or persist. Otherwise, I'll have to manually re-pin it all the time.
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.
The recent update is the first one that starts to feel like software to me because the download interface is much less "webby" (and faster for grabbing multiple files from someone.)
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.
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.
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.
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.
I love fluid because of the thing the article mentions about Alt/Cmd + Tab... it's hard-wired into my brain to mean "task switch", so I have several web apps that I use all the time (GCal, Pivotal Tracker, Asana to name a few) with Fluid apps so I can quickly change to them.
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.
> 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...
In 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.
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 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).
For 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.
Hence why I qualified my statement to "a tool designed...", as that is what the article is discussing (the wording of your comment makes me wonder if you read it at all ;P). FEIW, I also question whether "engagement" is good metric for social tools as well: you up engagement by making things critically need harder to use, which is a perverse incentive.
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 desktops can't be it.
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.
I 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.
> 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.
Qt? 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).
Whoa, 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.
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.
The 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.
On 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.
"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.
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."
I 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.
I'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/ site certainly doesn't have much info on how it can help for this use case.
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.
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
I'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.
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]
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 :-/
• 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.
> 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.
Except 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.
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:
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!
> You can cache all files in the app bundle with Cordova so the download happens during the install.
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.
A 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!
This 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.
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.
I'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.
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.
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".
So, 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.)
Slack, 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.
I'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.
There 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.
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.
In 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.
It'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.
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.
Bad 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.
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.
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.