Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

171–180 of 515 posts

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

#171
post #53

The web works best as a document platform. All the UI tricks that web developers work on all end up managing something related to just browsing/reading a document. It's amazing that modern browsers/HTML just don't have this basic user experience down. Why is it virtually impossible to read long articles on a web browser? After 25 years, why do web designers need to create their own page transition mechanics for long-…

>The web works best as a document platform. This is only true if you constrain the "web" to mean the Tim Berners-Lee document-centric HTML and its http hyperlinks. The "web" also means the whole internet stack, TCPIP, DNS routing, etc. In that case, the web is a foundational tool for anything that connects people or Internet Of Things. To say the "web works best as a document platform" is like saying "the electricity…

> The "web" also means the whole internet stack, TCPIP, DNS routing, etc.

I'm pretty sure there are different protocols for email, torrent, etc. And I don't see how that is a bad thing, or why The Web has to be a frontend to everything that comes from The Internet (desktop email application for instance).

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

#172

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

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

#173

Earlier quoted context omitted.

> Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app People always go on about Cordova etc, but I've never used one of these that wasn't a clunky, slow non-native looking mess. Do you have any examples of Cordova apps which aren't noticeably more crap than, say, an average-quality iOS app?

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 not the platform standard action bar

* The touch drag on the navigation drawer lags behind the finger position more than it should

* Non-native map has really bad pinch-zoom-pan gestures

As an Android developer I'm sure I'm consciously noticing things that lots of other users might not, but if this is the best Cordova still has to offer... :/

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

#174
post #57

To me the worst side-effect of naively chasing "native" is permission prompts. The web platform wants to have powerful features that are dangerous and/or easy to abuse, but haven't found a good way to allow them safely. The "solution" we've settled for is to blame the user for clicking "OK" on permission prompts that have unclear consequences to non-technical users.

That's exactly the same as iOS native permissions, isn't it?

Similar, but the key difference is that Apple can kick the worst abusers out of the walled garden.

The Free Web can't do that (and I strongly prefer it to remain Free with low barrier to entry), so it needs a better approach, or needs to give up on having dangerous features available.

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

#175

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…

Ever hear of these things called "app stores?" I hear they make pushing apps quite seamless.

Apparently, these things called "app stores" are so good, that on these new things called "mobile devices," native apps are more popular than web applications!

Sorry for being a pedantic. Updating applications is quite painless on every platform except for Windows. (On Mac, you can use the app store or include Sparkle in your application.) It's only Windows that makes updating difficult; and this is the fundamental weakness of the operating system.

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

#176

Earlier quoted context omitted.

> Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app People always go on about Cordova etc, but I've never used one of these that wasn't a clunky, slow non-native looking mess. Do you have any examples of Cordova apps which aren't noticeably more crap than, say, an average-quality iOS app?

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

Great hybrid app but I can definitely tell it is not native. The animations stutter quite a bit on my nexus 6. I'd imagine it would be much worse on low to mid level android devices. Then there is that slight delay on all tap actions. Perhaps your average user wouldn't pick up on these things, but as a developer I definitely can spot a html app immediately and find them unpleasant to use in most cases.

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

#177
post #9

Four points: a) Tooling: yes, it's still much easier to debug a native app than a pseudo-native app. b) "Emulating native leads to bad UX": this section is absolutely right. Stop hijacking scrolling and building in cruft. c) "Hassle-free web": absolutely right. You don't need an app for that. Just give us the information and let us have the basic interaction we want. No, you shouldn't present your menu as a PDF eithe…

> a) Tooling: yes, it's still much easier to debug a native app than a pseudo-native app.

It's not much easier to debug multiple versions of multiple native apps than it is to debug one web site.

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

#178
post #162
post #150

Earlier quoted context omitted.

>The world has not moved on. To clarify, I'm not saying "moved on" as an objective measure of superior technical progress. The "moved on" is referencing a descriptive (not prescriptive) state of affairs with how the world now defines "the web". The existence of sliding around map tiles in maps.google.com, syncing folders in Dropbox, etc is evidence that the world does not think of "web" the way Tim Berners-Lee though…

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 enlarged perception is unavoidable. We could ask the world at large to *not" call it "web" but that's like asking us to quit calling "machine calculator" a "computer". Sometimes we invent a new word, but many times we don't.

Yes, a person uses a "web" browser to read a "document" on New York Times. But they can also use that same browser to play a Sudoku game that's not a document at all. To the layman, both actions are "surfing the web".

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

#179
I prefer the experience of native mobile apps (and native desktop clients, too!), but I prefer the privacy and sandboxability of pure-HTML apps. If a site is going to add so much JavaScript that it's unusable without whitelisting it all, then I almost might as well just use a native app.

If Android had ever-so-slightly better permissions, then the clear answer would be to stick with native apps, period.

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

#180
post #85

Earlier quoted context omitted.

> Look at a site like YouTube today. And yet any media player beats it at its core functionality: video playback. Often I find myself using youtube-dl to fetch a youtube video and just play it in a regular media player because it just works better than what browsers have to offer. There even are addons to export YT playlists to VLC and stream them. pdfjs is great. but every 3rd scientific paper I read tends to be som…

> And yet any media player beats it at its core functionality: video playback. And at it's core, BetMax is better than VHS. HD-DVD is better than Blu-Ray. Often, it's not about what is "better". It's about who has the most moment, is easier, less encumbered by DRM, etc. Sometimes it's better to download Youtube... more often than not, Youtube "just works".

How is HD DVD better than Blu-Ray?
Post reply on HN