The web is still the place | Hacker News Reader

The web is still the place

raganwald.posterous.com

77 pointsfogus35 comments

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.

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.

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

https://github.com/rogerwang/node-webkit

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:

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.

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.

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.

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.

5) I want the best integration possible with my OS.

Couldn't disagree more with what? The part where I say that Facebook have decided that a native app is good business sense and I trust that they're right?

At no time do I say it makes zero sense to develop a native app, ever. Just that sometimes it doesn't, that it's business, not a whim or a slight, and that over time those apps that can run in a browser, will.

Lots of room for debate over what constitutes an app that "can run in a browser," of course. But despite the title, I don't think what I wrote suggests that native apps are some kind of evil.

Couldn't disagree more neither.

1. OSes have poorer ways to manage more than 7 windows; things get lost quickly.

2. Native apps crash often. In Chrome, you usually just lose the current tab and reload and go to another functionality of the page easily.

3. Native apps tend to be slow and clunky especially when dealing with online data especially when you are mobile.

4. Native apps are definitely a bigger threat to privacy; They have more access to your hardware and OS.

5. I want the best integration possible with the Web.

In addition, (6) Different inconsistent releases across different OSes, (7) Native apps are usually poorer in functionality than web counterparts (8) Native apps are poorer in integration (sharing, social integration, pinning) (9) Native apps can't link (10) Native apps can't be searched and indexed - they are opaque silos (11) Native apps don't make their developers any money as of 2012 (12) Native apps are terrible way to allocate company resources for most online businesses - supporting min 3 releases on Apple, some on Android, WP, BB.. (13) Native apps get mainly coded by retarded development tools - Objective C, Java, C# - It is a hack to code with Ruby, Python, Haskell, or anything more pleasant - though some options exist (RubyMotion, rhodes) (14) ...

Isn't the browser a native app on every platform? So obviously a native app can do all the things that you say it can't do.

Could this discussion not degenerate into FUD and mudslinging, please?

Items 1,2,and 4 are solved by running an app in its dedicated browser instance. There are simple tools for making containers like this.

4 is completely backwards. A native app has far more ability to spy on you, even to mutate data across your system, than a browser-sandboxed web app.

Also, you have no idea whether native apps are sending your data securely (without using something like Wireshark). With Web apps its trivial to check for HTTPS.

"So why bother with a native client? What’s in it for the user?"

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.

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.

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.

That's only true on iOS. There is real competition in the browser space on Android and the Mozilla Betas are actually very good browsers. But of course that's kind of a moot point because the mobile web is only as good as the lowest common denominator.

But to give Apple credit mobile Safari is a better browser than any but the most recent alternatives.

They're good, but I don't think Firefox Android has grabbed much market share.

No but it's not because competition isn't allowed, but because users are no more likely to manually switch browsers on their phones than they are on the desktop. Google's emphasis on Chrome in recent versions of Android is certainly a step in the right direction here but it will likely be another two years before the majority of Android users are running a really first-class browser thanks to the slow uptake of Android updates.

But I really think the discoverability advantages people cite for the app stores is highly overrated. If you can squeeze your way into the top twenty then maybe there's some real benefit but for most apps the app store is just an opaque box with primitive SEO and analytics.

Because it's not good yet. I've tried it and it does some things better, but is slightly slower and much buggier (2 lockups of the tablet -- which I consider to be an Android problem too)

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.

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.

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.

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.

> not a big enough market to justify the development costs of a native client

If only 3rd party developers could develop them for free...

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"?

"Write once" is nice, but the real advantage of web apps is that the author has complete control over their product.

Domain seizures, server outages, flaky browser support for standards, client side javascript execution, text rendering engine differences... web pages give developers different control over their product - whether or not it is more or less control than native apps, who knows.

The native vs. web arms race reminds me of Movies vs. Television. To attract people into theatres, the movie people made movies wider, added stereo sound, &c. &c., always trying to keep the theatre experience better than the TV experience.

But TV wins for convenience, cost to develop, and ubiquity, so there's plenty of content developed directly for television.

It's not a perfect simile, but there's enough of a resemblance that thinking the Movie/TV history through stimulates my thinking about native/Web.

JM2(anecdotal and inexpert)C

Interesting analogy. Here is where it breaks down for me:

Assuming (Movies : Apps :: Theater : Operating System), then (Television : Web), makes some sense, but doesn't fully work. The browser (the current medium for interacting with the web), exists on top of the Operating System, but Televisions are not tied to movie theaters in any such way.

On the other hand one obvious thing TV and the web do have in common is ads, versus up front cost of admission with native apps and movie tickets.

I might be old fashioned, but I see native apps as tools. Sturdy things that you can count on to do a task well. Browsers are one such tool used for communicating over the web. I see the web as a medium of communication rather than a tool. I suppose this mental model is why web apps feel wrong to me.

Yes, the biggest problem that "write once , run anywhere" has always had is that platform vendors don't want it. It's only an advantage to underdog platforms, this is why Sun wanted it so badly but MS did everything they could to stop it in it's tracks.

It's a lot more difficult to justify the purchase of a $2000 Mac if 100% of the software can be run on a generic Linux box for half the price.

At least with FF and Chrome being open source and gratis rather than directly commercial some of this motivation is alleviated. It's also more difficult to put up a barrier to entry for a new incompatible feature if your competitor can look at your code base and re-implement it from there.

FF and Chrome[0] are both built to service the web, so they have no need to distinguish themselves from each other.

[0] Except that a bunch of people at Google have forgotten this fact (or never learned it when they jumped over from Microsoft), and re-implemented the spiritual successors of ActiveX and JScript under new names.

I still prefer native over the web. Some examples:

Gmail on the web feels a bit slow and sluggish vs Apple Mail is fast, all attachments are there, and it just feels better.

Google Calendar is a pain to use - again slow and sluggish. iCal is fast and feels like what a calendar should feel like.

Address book the same.

iPhoto/iTunes as well.

I think if Hacker News had a good native client, I'd prefer that over the web.

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

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

I agree with all of your points except GMail. I often use Apple Mail, but if I need to find something, I have yet to be happy with its search. I use GMail directly for search, and then I often stay there to write my reply.

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.

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.

Even if it's a single developer building the client (I doubt it is anymore) that's likely at least $100,000 per year. Not to mention the extra support and QA you'll have to deal with as well.

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.

All native clients are better than web clients in some way. But if managing multiple accounts was awesome in a way that mattered to Twitter, I suspect that they'd release a multiple accounts on the web feature.

That doesn't strike me as a web vs. native issue, but rather a product management issue.

Sort of. The browser security model makes multiple-accounts in a website a pain. Google has been struggling for years to sort out.

I absolutely disagree. We're headed into an era of fat native clients. Mobile will dwarf everything, and native is winning in mobile.

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?

Reply on news.ycombinator.com