The web is still the place

The web is still the place but I think desktop web browsers could help out a bit here to fill in the gap between full-page websites and native clients. I loved Mozilla Prism before it was discontinued. My best alternative is using Chrome in app-mode "C:\..\Google\Chrome\Application\chrome.exe" --app="url://my-todos" but it is still not enough. Chrome now has Growl-style messages that web-apps can use to notify the desktop. Trello uses that wonderfully. IE lets websites add options to the tray context menu. iOS Safari has an 'Add to Home Screen' option that makes web-pages behave more like full-screen apps and provides caching.<p>All of these things are disparate and desperate attempts by browsers to be more useful and desktop-like without any standards or forethought. I would love if the major browsers could agree on some tags/JS to enable (with permission from the user) better integration with the desktop. From taskbar/tray-icon and windows position/size to run-at-startup and multi-monitor support.<p>This way Twitter can just use a slightly different CSS file and a few meta tags to pretty much replace their native app. Browsers are now fast enough for most everything you need a desktop app for but the 'app' experience is lacking. Chrome's apps are not quite cutting it. Web-apps need to be able to break out of the browser without having to use window.open().

Couldn't disagree more. I greatly prefer native clients and will be way more inclined to use a service that offers/allows them. Here's why:<p>1) I don't like having all my eggs in one basket. I have multiple browser windows each with multiple tabs. Things simply get lost in the mix. My OS has always had a better task switching UI than my browser.<p>2) Web browsers crash. So do apps of course but the damage is localized. When a browser goes down hard I lose everything. Doesn't happen very often but definitely more often than a kernel panic.<p>3) Web apps tend to still be slow and clunky. For example I get scrolling lag on the G+ page. I would use it more often if I just had a G+ app available.<p>4) Native apps can be segregated. I don't really trust companies like FaceBook or Google not to spy on every bit of data they can find via my browser. It seems to be totally acceptable to them. Less likely to happen with native apps.<p>5) I want the best integration possible with my OS.

"So why bother with a native client? What’s in it for the user?"<p>Well, if there were nothing in it for the user, no users would be complaining, and we wouldn't be having this conversation in the first place.<p>The author is certainly right that multiple heterogenous development platforms incur an increased headache and expense, and that the web can get you a pretty good experience on lots of platforms. The argument then is that "pretty good" is good enough, and that the decreased support costs dominate the software quality and user experience.<p>Maybe they are, maybe not. But as a software engineer, it's hard to get excited about the prospect of making our software suck more to save money.

There is a gap between native and the web, but it will not last long (have high hopes on FF OS) and it is currently narrow enough not to matter in many applications. Haven't dug deep enough in the code to know if Twitter is one of the apps where it matters. That would be interesting to know.

I agree, but the unfortunate reality is that the thing that makes browsers on desktop so great -- fierce competition -- is virtually non-existent on mobile. It's why vendors can get away with only shipping updates to the browser once per year. And the chances of this changing aren't great. It's widely accepted that for "security reasons", browsers competition can't be allowed.

Mobile Safari is very slow with things like CSS3 transitions even with translate3d, in addition to limitations such as click-delay, so right now things can look the same you are right, but they can't react or perform equally, I have never touched native app development as a basic rule, but things need to improve to feel closer to native. This missing link in experience might be driving the native conflict.

Maybe it's just that OS X is not a big enough market to justify the development costs of a native client. The cost/benefit for native vs web is surely quite different for iOS vs OS X.<p>I think a lot of these native vs web debates tend to be too black and white. The right solution depends a lot on what you're trying to build. If you're building something very content-heavy and broad distribution is more important than optimizing for any single platform than the web is probably the way to go.<p>If you want to present a very interactive, media-rich experience or you want to try to make money directly from the app itself then you should probably go native.<p>Native is going to be important. The web is going to be important. Mobile is obviously growing but the desktop is not going away either.

If everything is to go to the web, then what is the point of an OS at all besides running a browser? If you answer FF OS or Chrome OS, then is it only a matter of time before they too try to distinguish themselves from each other, and face the same issues as native desktop OSes, and another layer of abstraction on top of the browser must be built to achieve the holy grail of "write once run anywhere"?

I still prefer native over the web. Some examples:<p>Gmail on the web feels a bit slow and sluggish vs Apple Mail is fast, all attachments are there, and it just feels better.<p>Google Calendar is a pain to use - again slow and sluggish. iCal is fast and feels like what a calendar should feel like.<p>Address book the same.<p>iPhoto/iTunes as well.<p>I think if Hacker News had a good native client, I'd prefer that over the web.<p>The web is definitely impressive... like Trello. Trello feels fast and it's super versatile. But if Trello had a native app, I'd definitely prefer that (of course it's got to be done well).<p>But I understand the development costs of supporting multiple native platforms. It's also the loss of focus because you need to have your team separated out vs focused on one platform (ie., 37 Signals).

It's really the web platform, aka HTML5, that's write-once, run-anywhere, and Twitter is still keeping The TweetDeck client (for now), which is heavily powered by HTML5. So they will still have desktop presence and will probably converge to TweetDeck being their one official desktop app. I realise it's overly complex for many users, but it seems they've made this decision and will probably work to support a more minimal experience to fit the needs of people coming from the deprecated client.<p>BTW after a long period of lagging behind the old Air client, the new TweetDeck is actually working great imo.

Wasn't it like only one developer that wrote the facebook iPad app way back when. It certainly isn't a team of 30+ developers working it. I don't buy the "cost" of having a native client as the main reason.

This misses the point that the native OS X Twitter client is awesome. It allows you to easily manage multiple accounts. That's not something the Twitter website does.

I absolutely disagree. We're headed into an era of fat native clients. Mobile will dwarf everything, and native is winning in mobile.<p>Of course, everything is a cycle. And the web will come back. But currently, it's taking a backseat.

Aren't notifications a big feature for Twitter? If you have to open a browser or keep it open and keep refreshing or clicking on the "x more tweets" buttons, how is it attractive?