Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

161–170 of 515 posts

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

#161
post #5

Unless you're making something that needs really good performance (3D gaming for example) building a hybrid app wins every time. Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app, with about 1/2 of the development time because it's all built with web technology. 90% is easily good enough for most applications. Cordova wraps a uiWebView in some b…

> building a hybrid app wins every time.

Define your criteria for "winning". If I'm truly building a user experience, then I don't know a single hybrid app that has "won" (my definition of winning here is an app I use daily, and I don't know of a single app I use daily that is hybrid)

> 90% is easily good enough for most applications

The problem is most applications (80%) don't really even need a native app to begin with.

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

#162
post #150
post #129

Earlier quoted context omitted.

> Instead, I'm pointing out that the world out there without permission from any savvy HN readers has moved on. The world has not moved on. Part of the world has dug itself into a technological hole. Most of the people who work in it have never seen what's outside it, so they think the solution to all their problems is to keep digging. Edit: crap, I sounded so snarky and aggressive. Sorry about that. It's not somethi…

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

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

#163
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 software protect itself when inevitably someone's install is corrupted or skipped.

Compare that to the web. User opens Chrome; they get the new app. No push. No real notification of any team. Hell, Ops probably doesn't have to be notified if they automated web app deployment to servers. The whole thing is very easy. Even if you have the added complexity of a Chrome-app wrapper, still pretty easy.

Given the ease of deployment and the mitigated risk of data corruption due to version issues of the app, the web looks pretty good. Given the advancement of hardware and software, UX can be close to native. If not native, app-y for lack of a better word.

If it lacks UX for native, don't target native. Target app-y. This is between native and document. It might become complex to manage local state, but that shouldn't be a deterrent.

Tangentially related, to the general question: does the user want to have a link to your product on their desktop? The answer is probably no. They want easy access to your product, but the link conflates how this occurs with a sense of permanence. Your app is not the product. Your app is tool to get the product: information. UX and installation are both just means to the end.

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

#164
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…

I read that Appcelerator Titanium and NativeScript are a much better way.

You can use much of your JavaScript skills and still get to go native.

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

#165
post #122

Earlier quoted context omitted.

I never saw anyone with one in Germany, besides computer stores trying to get rid of them with massive discounts and still they gather dust.

Amazon's best selling laptops - http://www.amazon.com/Best-Sellers-Computers-Accessories-Lap...

On the US market.

Additionally how many of those laptops are actually running ChromeOS, instead of being replaced by a proper Linux distribution?

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

#166
post #155

Earlier quoted context omitted.

> It also benefits hugely from urls, which allow users to share what they've found. how about http://some.storage.service.tld/path/to/video.mkv or even rtmp://some.streaming.service.tld/path/to/stream ? For sharing that would be sufficient. Of course there are some business realities (ads, copyright, paying for storage) that make direct, free access to videos unlikely. But that's basically arguing that the web is a s…

I would like to complement that native youtube(the one used on mobile) is far better at playback while keeping nearly every other advantage that it has on the web.

> that native youtube(the one used on mobile) is far better at playback.

No, it is not. Playback would get stuck, sound would go away for no rhyme or reason and what not. Better experience? - no - quite the opposite.

I got rid [1] of the native nuisance completely. And the experience of search, comment and history on native was simply terrible. Much lesser control on ad-blocking too, and really the ads on YT are sometimes seriously irritating.

[1] Evidence: https://twitter.com/marvindanig/status/598701509963083777

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

#167
post #136
post #131

Earlier quoted context omitted.

Users don't care about networking protocols as long as the Dropbox application is able to synchronize their documents.

Exactly! The "web" as in Tim Berners-Lee(TBL) "world wide web" is http+html which is " documents ". Saying TBL-web is "best as a document platform" makes perfect sense. It was defined that way therefore, use it that way. It's tautology. Back in 1993, if we want to say "X is best though of as a network app platform" we'd have to use the word "internet" instead of "web" for "X" to be conceptually pure and technically c…

Dropbox can throw away HTTP and replace it with TCP, UDP or any other IP based protocol and it will keep on working.

This is they beauty of the network communication protocols.

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

#168
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…

It's interesting that you mention YouTube, because the thing that finally convinced me that a 'web app' could be indistinguishable from a native app was YouTube's Leanback interface (YouTube TV). Check it out: https://www.youtube.com/tv Video player functionality aside (I understand the complaints), that thing full-screened just feels like a native app.

> YouTube on TV is not supported on this device?

Is it only for mobile? I didn't see any "mob" or something in the URL. Anyway, with regards to being indistinguishable from native, I guess there is nothing quite like being reminded that you are "native" than an app complaining that you are on the wrong native device. :-)

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

#169
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…

I think it is possible that a news app done well could provide a slightly better mobile UX than a browser (better navigation and pagination), I would want the content to be mirrored on the web, and it should be easy to get at and share the web links.

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

#170
The best argument I've ever seen is that it's ridiculous to think that there will be an app for every business, website and device.

Instead, I see a future, like we're starting to see with devices such as the Synology NAS where the interface is a website served on the device.

Things like the ESP8266 make it possible to add Wifi capability to pretty much any device.

The future isn't about an app store nor about search, it's about discovery.

Post reply on HN