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

441–450 of 515 posts

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

#441

Post by baddox »

dubrocks wrote: post #429
baddox wrote: post #373

Earlier quoted context omitted.

YouTube's video playback problems might have nothing to do with the web. Despite having an iPad app that is otherwise mostly great, their iPad video player itself is abysmal. It's just flat-out broken, and they're presumably not going to fix it. If you start playing a video, the timeline at the bottom will start turning grey from left to right to indicate the part of the video that is buffered. But if you scrub to a…

Been like this for months for me. I've found the way to fix it is to manually select a video resolution.

Yes, that is my workaround as well. I also sometimes use the jailbreak utility VideoPane to extract the iOS-native video from the YouTube app and play it in a popup. You get the native video player and controls, and funny enough, it works wonderfully.

https://rpetri.ch/cydia/videopane/

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

#442

Post by meesterdude »

I'm a web developer with a side project. I don't have the time/energy/knowledge/bandwidth to implement native apps for IOS and android. But I CAN make it work well enough in a mobile browser.

And lets not forget: developing for android is hard. You have a variety of models, with varying versions of android, running on different carriers; i've read some horror stories, and no thanks.

I'm quite quite happy developing for the web and keeping it on the web. I don't have to answer to any gate keeper or ask for permission for a new release. I don't have to share 30% of my profits, or be careful about implementing native functionality.

They just need a browser that can render HTML/JS/CSS. That browser will only get more optimized over the years, the network will only get faster, and the technologies to optimize the web for mobile will only increase.

I say more web, not less.

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

#443

Post by simoncion »

haberman wrote: post #413
coldtea wrote: post #390

Earlier quoted context omitted.

> What are you even talking about? If you click on a YouTube link, a video your computer has never seen before is playing in less than five seconds, streaming over the internet. Nothing about this is "web" specific. That's just "streaming over the internet" as you said. Lots of native apps do it too (for both music and video, internet radio, iTunes video rentals, etc.). The reason we didn't have this as widespread be…

> Nothing about this is "web" specific. Moving the goalposts. You were saying that YouTube is a slower and clunkier version of a 2000 native app. Now you're comparing 2015 native vs web. > native is a superset of what functionality is available in a web sandbox Web sandboxes have a killer advantage over native: no install. And if we're talking about native desktop, there's another killer advantage of the web: you don…

> You were saying that YouTube is a slower and clunkier version of a 2000 native app.

You said: "Nothing in 2000 had a remotely similar feature set."

Not that Winamp 3 (released in 2002) was a svelte piece of software[0], but it could do realtime pitch/speed shifting and stream audio and video from the Internet. With a sufficiently fast connection, three seconds from link click to video stream start would be quite doable.

Streaming and decoding audio and video isn't anything new. The two new things that The Web brings us are "zero-install" and a the benefits of the large amount of sandboxing work that's been put into the major browsers.

[0] WA3 was slow because of the UI code, not because of the media stream and decode code. :)

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

#444

Post by mattLummus »

the8472 wrote: post #361
nostrademons wrote: post #344

Earlier quoted context omitted.

Netscape could do this back in 1995. One of its preference settings let you associate external applications with certain MIME types; when you clicked on a link pointing to a resource of that type, it would automatically open the external program to view the file, as if you had double-clicked on it. Similarly, you can do this right now on Android. When you click on a link, it fires off an Intent with the URL. Apps can…

> It turns out that for certain types of content, users really, really don't like to wait for external programs to load. And yet they click through full page ads, wait for "loading showcase" animations, scroll past parallax scrolling banner images and also wait for the ads on youtube videos and for the video to switch from 360p to HD. Users are strange creatures. I think if some effort were put into streamlining the…

Ads exist in Native apps as well. At least in the web I have the option of browser extensions to provide a more customizable UX. With adBlock I don't get Youtube ads on Chrome so that point is null.

As for the last point, Spotify has some version of this. My native (mobile) Spotify app knows when I'm playing on my computer and vice-versa.

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

#445

Post by mattLummus »

baddox wrote: post #373
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…

YouTube's video playback problems might have nothing to do with the web. Despite having an iPad app that is otherwise mostly great, their iPad video player itself is abysmal. It's just flat-out broken, and they're presumably not going to fix it. If you start playing a video, the timeline at the bottom will start turning grey from left to right to indicate the part of the video that is buffered. But if you scrub to a…

Correct, YT issues are more often caused by server/network latency rather than the client.

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

#446

Post by mattLummus »

briandear wrote: post #437
monsterix wrote: post #166

Earlier quoted context omitted.

> 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 som…

If you block the ads, how does the site make money to support your viewing habits?

That is irrelevant. I prefer to not have ads and Google is generally kind of to comply and suggest developers respect ad-blockers as well, even though the vast majority of Google's revenue comes from ads. To suggest going native to provide revenue over UX only benefits the provider, not the user.

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

#447

Post by mattLummus »

omouse wrote: post #232
nkuttler wrote: post #49

Earlier quoted context omitted.

> After 25 years, why do web designers need to create their own page transition mechanics for long-form articles Why do you need page transitions for articles at all? The only reason I can think of is for more ad displays. Ok, if you have, say, a long manual with multiple chapters that would be several hundred pages when printed it can be nice to break it up, but that's probably not what you meant. > photo galleries…

It looks like you've brought up the most important point: the design of a page is altered based on advertising revenue. 90% of the JS being loaded is for tracking to increase advertising revenue. Much of the styling for a site that has no advertising can be fairly light. If we focused less on revenue generation we'd have a much much smoother web experience that would run quickly on mobile devices.

Agreed. Ads are a significant liability for both User experience and security.

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

#449

Post by mattLummus »

gedrap wrote: post #322
omouse wrote: post #232

Earlier quoted context omitted.

It looks like you've brought up the most important point: the design of a page is altered based on advertising revenue. 90% of the JS being loaded is for tracking to increase advertising revenue. Much of the styling for a site that has no advertising can be fairly light. If we focused less on revenue generation we'd have a much much smoother web experience that would run quickly on mobile devices.

>>> If we focused less on revenue generation we'd have a much much smoother web experience But then rather than poor content, there would be next to no content (for the masses) because business have expenses ;) Speaking seriously, yeah I see what you mean. Maybe reducing ads and improving speed would result in better UX, which would lead to better user retention, which would leave to more ad clicks. But that's a lot…

On a related note, I think depending on ad revenues is not such a sustainable practice. Its a feast or famine strategy and eventually a lot of businesses are going to realize that. Targeted marketing improves this, but the greater the noise, the more our brains learn to ignore it. Subscription or sponsorship models are a tougher sell but provide more loyalty and consistency for free content.

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

#450

Post by joeyspn »

pavlov wrote: 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…

> For developers, Cordova/PhoneGap-style tools are not a panacea either. It's easy to get an 80% solution done, but then you run into problems with mobile browser performance.

That is a thing of the past. At the current rate of smartphone/phablet specs growth the differences with desktop are laughable (you can currently get 64bit octacore@1.7Ghz mobile devices with 3Gb of RAM for around $100) [0]. And this will only continue to grow. 16core and 32cores will be here in 2-3 years [1].

IMO, hybrid apps are already the present. The difficult times when we didn't have the required performance in our pockets are long gone... and frameworks like Ionic are really convenient for certain use cases.

> browser differences between devices (even Android devices with the same base OS can have very different web view browser engines)

That has been already solved with xwalk [2]... but again, this will be irrelevant in a couple of years.

[0] http://www.gearbest.com/cell-phones/pp_152602.html

[1] http://www.xbitlabs.com/news/cpu/display/20130304235830_Pres...

[2] https://crosswalk-project.org/

Post reply on HN