Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

Post reply on HN
Print view View original

181–190 of 515 posts

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

#181

Post by frik »

eloisant wrote: post #172
virmundi wrote: post #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 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…

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.

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

#182

Post by leoedin »

Margh wrote: post #146
pjc50 wrote: 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…

> It's hard to deep-link into an app. Disagree. Case in point: steam://friends https://www.iana.org/assignments/uri-schemes/prov/steam /s/ steam for news://home or news://business/26-05-2015-oil-prices The content could (and definitely should) still be html, obviously not everybody you link to is going to want to install the news app and it should fall back to opening in a browser, but if you want to wrap a fancy int…

They didn't say it was impossible, they said it was hard. And it is. Deep linking into an app requires a link handling implementation and knowledge of the operating system's procedures for registering that you can handle certain protocols. The web gives it to you for free.

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

#183

Post by shwetank »

adamc wrote: post #124
the8472 wrote: 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…

I think media playback is only part of the core functionality. The other key piece is discoverability, and on that front, YouTube is far, far better than a native media player. It also benefits hugely from urls, which allow users to share what they've found. So, arguably, YouTube's success is more about what the web does well than about it's media playback -- it just has to be "good enough" on that front.

Also the fact that you can embed youtube videos in other web pages.

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

#184

Post by UUMMUU »

This is probably going to be an unpopular opinion but I think the current push to make native feelings apps in JS is awesome. Playing with an app like Untappd and then realizing it's written by (at least originally) 2 people and still feels fluid is incredible. I've also never heard anyone except developers complain that it's not app-y enough. True things like games shouldn't be written in phonegap or react-native but I think to say that we should completely stop trying to build any native-feeling apps is wrong. I actively push anyone interested in turning their app idea into a working prototype use Meteor or React-Native or just straight up phonegap and if they get traction they can do what facebook did and rewrite.

I know this flies in the face of this article but I just don't think we should stop trying.

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

#185

Post by duncanawoods »

tragic wrote: post #32
pjc50 wrote: 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…

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 feeds, audio, pictures and embedded digital content from other services like twitter created by both journalists and amateur eye-witnesses. These are not just value-less decoration like cute animations on landing pages but real content from the event being reported.

When news is data like election results, tax changes etc. interactive data visualiations are essential for digesting it. Interactivity lets us understand the impact of the news to us personally instead of single homogeneous national agenda. We expect all this and for it to be real-time and provide ways for us to be notified about changes, to share it and discuss it with friends and strangers.

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

#186

Post by virmundi »

gwbas1c wrote: post #175
virmundi wrote: post #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 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…

I've heard plenty of people on HN bemoan the process of pushing updates out via Apple. You can have a critical bug (yes, yes better testing), but it can take the store up to a week to review, approve and deploy your app. Sure there are ways to expedite that, but should you have to be so concerned?

To me there should be a bit of a feeling when to use native vs web on mobile. If you're making a fairly static, pretty booklet app, I'd use web. Cordova makes this simple and clean. If your moving much beyond that, from personal experience, I'd go native. I've tried all of the free-to-type hybrids. The tools try to smooth over the issues of complex API centralize business logic in JS while having multiple views to target different OSs. Sadly, most only really support iOS. For example, Ionic tries to support Android, but it's general appearance is iOS. Appcelerator is the same.

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

#187

Post by felipeerias »

karl42 wrote: post #159
felipeerias wrote: post #100

Earlier quoted context omitted.

Have you tried to disable pagination in reading apps like iBooks or Instapaper? Long articles and books are more comfortable to read if they are paginated: one small tap, one pageful of new stuff. Far more convenient and less prone to losing your place than scrolling.

Using pages to display text is fine. I regularly use space to scroll a page down when reading a long text in the browser because it is more pleasant than constantly scrolling. But fixed pages should not be part of the document markup in most cases. Reading a PDF on my phone is not a pleasure just because I can't just flow the text to fit my device.

I do most of my long-form reading on devices that don't have a space key.

I am not talking about fixed pages or clickbait websites where you have to scroll anyway and then click a "Next" button, but about having a flexible way to enable pagination of content.

That pagination is one of the reasons why for me the best way to read something like the stories in http://longreads.com/ is on Instapaper (or a similar tool).

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

#188

Post by Thiz »

Html is for documents served thru http.

What we need is a language to build apps natively and serve them securely thru the browser using an app:// protocol.

Working with html to build apps is a nightmare. Google, Apple and Mozilla should take the best from android and ios and work on something universal and truly disrupting. No, not java. No, not obj-c. Perhaps swift, go, nim or something better. Remember the hobbyists.

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

#189

Post by pinaceae »

as long as you use a markup language plus styling language built for documents to somehow emulate app interfaces, the web will lose against native.

the www is great for content. wikipedia. awesome.

but it just sucks for apps. the constraints it puts on UI and hacks needed to get around them is staggering. let's center something on the screen with CSS.

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

#190

Post by jasode »

pjmlp wrote: post #167
jasode wrote: post #136

Earlier quoted context omitted.

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.

Dropbox without using http_port_80 would only work in a laboratory. One big reason Dropbox is valued at $1+ billion dollars is that it uses http so everyone can use it easily. Web browsers didn't require radical changes. Corporate firewall rules didn't have to change. That's how they got quick adoption and millions of users.
Post reply on HN