Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

201–210 of 515 posts

Re: Web vs. native: let’s concede defeat

#201
post #181

Earlier quoted context omitted.

To be honest, Google takes care of all the complexity to have apps updated on Android. It's even better, because you can do a stage rollout really easily (i.e. just deploy to 10% of users, then 20%, then 50%, etc.). It's possible to do on a web app but you'll have to do it manually. You still have to push the apk and stay alert for the feedback, but you have to be careful with web apps update too anyway. I'm not sure…

Auto-updates are great except in the rare cases where they aren't at all. Picking up my phone in the morning to recognize that it lost half its battery in the night due an extensive auto update and being left in the cold with a 10% battery (instead of 60%) isn't that great. Beside that I think virmundi above has his points, and I agree with him. App updates are not instantaneous.

i think the default setting for new android releases is only update on wifi and plugged in.

Re: Web vs. native: let’s concede defeat

#202
post #181

Earlier quoted context omitted.

To be honest, Google takes care of all the complexity to have apps updated on Android. It's even better, because you can do a stage rollout really easily (i.e. just deploy to 10% of users, then 20%, then 50%, etc.). It's possible to do on a web app but you'll have to do it manually. You still have to push the apk and stay alert for the feedback, but you have to be careful with web apps update too anyway. I'm not sure…

Auto-updates are great except in the rare cases where they aren't at all. Picking up my phone in the morning to recognize that it lost half its battery in the night due an extensive auto update and being left in the cold with a 10% battery (instead of 60%) isn't that great. Beside that I think virmundi above has his points, and I agree with him. App updates are not instantaneous.

As of iOS 8, apps will only update automatically when the phone is plugged in to charge and connected to WiFi.

Re: Web vs. native: let’s concede defeat

#203
post #28

I feel we’ve gone too far in emulating native apps. Conceding defeat will force us to rethink the web’s purpose and unique strengths — and that’s long overdue. This, a million times. Mobile websites and mobile apps have completely different strengths. The current trend is to develop them both with the same HTML-based toolchains and make them as similar as possible, which ends up being to the detriment of both. Users…

"With all that, the last 20% of a Cordova app may well take 80% of development time, and that's rarely been budgeted in." To be fair, that could be said about most software projects. "80% done, now the last 80% remains." Not that I disagree with you, I had the same experience trying to make an Android app in Phonegap. It's lacking, like most cross-platform frameworks (for most types of apps, but typically not games)…

side comment: the rule is called the 90-90 rule [https://en.wikipedia.org/wiki/Ninety-ninety_rule]

Re: Web vs. native: let’s concede defeat

#204

What about the benefit that the web brings to updating the user's install? I know that it is technically possible to push a new Java or .NET app out to users. I've done it. The one thing it requires is a lot of coordination. Notify the users to keep their equipment on the network from time X to Y. Notify the infrastructure team to schedule a push. Have the dev team on standby in case the push goes bad. Have the softw…

To be honest, Google takes care of all the complexity to have apps updated on Android. It's even better, because you can do a stage rollout really easily (i.e. just deploy to 10% of users, then 20%, then 50%, etc.). It's possible to do on a web app but you'll have to do it manually. You still have to push the apk and stay alert for the feedback, but you have to be careful with web apps update too anyway. I'm not sure…

> I'm not sure about Apple because it appears the auto-update process is not that smooth and people don't upgrade their app as often as Android users.

The auto-update process on iOS is basically the same as recent versions of Android: check a box for completely automatic background updates or see a notification with the available update count and an “Update everything” button. The main difference is for things like games which hit the legacy 100MB cellular transfer limit which Apple added back when AT&T had grossly underprovisioned their network.

Re: Web vs. native: let’s concede defeat

#205
post #173

Earlier quoted context omitted.

The best example I know of is http://snowbuddyhq.com/ ... It's pretty much impossible to tell that it's not a native app, it's fantastically well designed, and it works really well. There's a good article about it on Digital Arts: http://www.digitalartsonline.co.uk/news/interactive-design/w...

Installing this on Android, it's pretty obvious this isn't native: * the very first animation (a slide transition to the left) was janky * The app was unable to get my GPS location (it's being shared properly, and I have intermittent GPS signal, but if it was using the native fused location provider this would work perfectly) * Buttons have no touch feedback. * It's not the platform standard navigation drawer * It's…

> As an Android developer I'm sure I'm consciously noticing things that lots of other users might not

Having talked to a lot of users, they do notice. They may not be able to articulate it, but all the things you mentioned give them the feeling that the app is not as good as some other app.

Re: Web vs. native: let’s concede defeat

#206
What's appalling is how many of the mobile app-related comments here are about cross-platform panaceas.

Just don't. Well, OK, if you have an enterprise shop full of C# coders, you should evaluate Xamarin.

But unless that's your story, and unless your tool is as well-engineered and well-funded as Xamarin, trying to get one code-base across Android and iOS is going end in pain and regret.

It's back to a future of multiple platforms with fairly strong differentiation in features and toolchains. Deal with it.

Re: Web vs. native: let’s concede defeat

#207
I really don't know anyone who carries on these kinds of arguments. In my experience, we code for the web most of the time, because it works and is usable by most people on most devices. Once in a while, we have a compelling reason not to. When that reason comes along, we code a native app.

It isn't a competition between platforms, and we aren't trying to make them look and act the same. We just pick the platform that offers the simplest workable solution.

Maybe I just run in a more pragmatic crowd...

Re: Web vs. native: let’s concede defeat

#208
post #32

Earlier quoted context omitted.

Disclosure: I work on the website of a blue-chip dead-tree newspaper. But I agree. As someone else said in another comment, the basic requirements of a news site is, let's be honest, Web 0.5 stuff. Look, some text about stuff that happened! A picture of stuff happening! These are, shall we say, solved problems. If there's anything where you wouldn't expect significant value-add from the native or pseudo-native experi…

>> If there's anything where you wouldn't expect significant >> value-add from the native or pseudo-native experience, it would >> be news I strongly disagree. I see "the news" is a perfect counter example because technology has changed what news is . Its not daily static content anymore, its now real-time, multi-media, interactive and interconnected. The types of media on a news page include: recorded video, live fe…

.. but all of that is already being presented quite well in web pages?

Re: Web vs. native: let’s concede defeat

#209
post #42

Remember Flash? Narrow the gap, add a bit of Steve Jobs and Boom! The web Won. Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible. If we've just given up 10 years ago, saying to ourselves that the web should only be for documents, then we would be missing out big time right now. It’s not for every site to try and…

Youtube is the first thing I point to apps on my mobile devices... Why would you ask your phone to dl megs of crap everytime instead of having instant video load?

Over the chain of ownership of any website I would say starting out trying to mimic a native experience will inevitably lead to a bad UX. Maybe not at first but it will. Part of the reason I use HN as a web site on my phone/tab is because it doesn't try to get fancy and just gives me a great web experience. Shocker.

Re: Web vs. native: let’s concede defeat

#210
post #178
post #162

Earlier quoted context omitted.

Yes, but whatever that is should not be called "web", just like we call "cars"... "cars", not "carriages", though they may look like it. "The web" is defined by a set of traits (hyperlinks etc.). When whatever we're doing stops having those traits, it's no longer the web. Continuing to call it "the web" is not some form of philosophical awareness, it's just ignorance.

But "computer" used to mean a " person who calculates" and not a " machine that calculates". All of us call modern day devices with CPUs a "computer" even though it lost the essence of "human". The usage of words evolve. I 100% agree that ""The web" is defined by a set of traits (hyperlinks etc.)". I'm also adding that "web" also now includes expanded perceptions by everyone else beyond "hyperlinks+http" and that enl…

By the time electronic computers became widespread, very few non-electronic computers remained -- and few of them were human. The term was easy to repurpose.

But the World Wide Web is very much here and very present.

> To the layman, both actions are "surfing the web".

To the layman, a server and a computer are the same thing, and yet calling Apache a computer is incorrect.

Post reply on HN