Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

361–370 of 515 posts

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

#361

Earlier quoted context omitted.

I don't recall plugins ever offering much choice. "Please install Flash to view this content" is what I remember. If I could stream directly to VLC or a player of my choice I'd be happy with that.

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 native web boundary then users would be quite happy with it.

> This is how the official YouTube/Google Maps/G+ apps work.

The question is, could this be standardized further? Basically a web standard that browsers agree to when it comes to talking to native apps that might offer specific services.

At the risk of getting stoned to death for this: WebD-Bus?

Although I think anything like that isn't going to happen. Browser vendors put security over everything else. Talking to native apps which already have access to the system would probably be construed as some sort of security risk, even if the user had to opt-in.

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

#362
post #85
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…

> 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 used to be better before at video playback, not as good as VLC but much better than what it is today. I think they have to deliberately hamper the user experience in order to save bandwidth, just imagine how much bandwidth youtube must cost with the amounts of users they have. Even their native android app isn't exactly the greatest which makes the web vs native comparison a bit easier.

Examples of this hampering is that they only stream 20sec ahead instead of the whole clip in one shot. There are many other annoyances like this, like not giving you the HD version even though it says the video is HD and you've selected HD, or when it re-streams the movie when you switch from windowed to fullscreen, probably because the windowed version was too low quality.

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

#363

Earlier quoted context omitted.

>business realities make direct, free, downloadable videos impossible at scale And yet it's existed for years using p2p/torrents. So they're more like business fictions

Do you feel you made a point by listing services that exist only by breaking the law to exist as somehow related to business reality? Making your money by trampling the rights of others isn't exactly sustainable. The only way you have a point is to be rampantly intellectually dishonest, or ignorant of reality. Neither option is great, so charitably, it's best to assume you know this stuff and you're just trolling. Al…

>Making your money by trampling the rights of others isn't exactly sustainable

Well said, you should tell this to Disney, MPAA, and MAFIAA so they'll stop trampling the rights of the commons by extending the length of copyrights everytime something profitable to them is about to expire. https://en.wikipedia.org/wiki/Copyright_Term_Extension_Act

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

#364
post #124

Earlier quoted context omitted.

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.

Imagine YouTube that hosts everything it hosts now, but when you click "play", opens your video player of choice and streams the video.

You mean, being able to set media type handlers for your web browser?

I seem to remember being able to do that two decades ago. I imagine you still can (assuming you're up-to-speed with the configuration UI of the week for your browser), but it's not something people seem to do a lot.

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

#365
post #340
post #124

Earlier quoted context omitted.

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.

I would compare and contrast the experience you are describing with a podcast player like pocketcast. Synchronized play state and playlists on all the devices. Offline handling of the media files with streaming as an option. Feed subscription but also podcast repository and ranking/trending screens. All media files are by definition in independant feeds, and sharing a file URL is supported. It brings a hugely better…

Huh, I suspect we have very different consumption habits. I could predict ahead of time perhaps 5% of the youtube videos that I end up watching.

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

#366
post #343

Earlier quoted context omitted.

I don't recall plugins ever offering much choice. "Please install Flash to view this content" is what I remember. If I could stream directly to VLC or a player of my choice I'd be happy with that.

Before flash could play video, links that open in the media player of your choice were very common. It was a nightmare. Each media player would try to hijack every link type it knew about each time it ran. But there wasn't full compatibility. So you'd click a link, RealPlayer would try to open it, and the player would crash. The major players actively fought open standards, because they each had dreams of controlling…

I wouldn't say "initially"; Flash is still notorious for severe performance issues. That said, so are most native media players nowadays.

With that said, I'd be more optimistic of a kind of "media plugin renaissance" like what's being discussed in this day and age than I would be back in the 90's, what with all the insistence on standards-compliance and all that jazz. Eventually, with platforms like the .NET CLR / Mono catching on and becoming increasingly popular for cross-platform "native" (not quite native, but much more native than web-based) development, the chance of successfully reaching the goal that Java tried (and - arguably - failed) to reach back in the 90's is much higher nowadays.

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

#367
post #137

Sure it's just me anecdotally, but I don't care about native apps versus web apps. I care about where the ship takes me not the arrangement of its deck chairs. I'll use the command line...or the address/search box...if it gets me what I want. Good user interaction and great functionality subsume widget chrome and when it comes to native versus web experience please feel free to do something else on my behalf whenever…

There's a big market for ships with nice deck chair arrangements.

Yes, of course and too many lifeboats might scare the passengers. That's why one can find work in the deck chair arranging industry, attend deck chair arranging conferences, and engage in debates over whether it is best to arrange deck chairs using tabs or spaces.

Yet somehow, users manage to navigate the web despite Apple's app store gatekeepers not setting policy. And really the debate about emulating native exists because of app store policy, not because the native standards are inherently better than what someone might invent left to their own devices...or even that they are necessarily better than the command line.

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

#368

The web already won. When was the last time someone told you about an app idea and you had any vision of a Win32 (or WPF) app? The web is the defacto app platform for desktop today. Sure, there are some legacy and niche apps that are native on desktop, but mostly everything new is web based on desktop. Mobile is a different story, but I think its due mostly to the fact that mobile HW is still changing rapidly. New se…

When was the last time someone told you about an app idea and you had any vision of a Win32 (or WPF) app? What does a specific widget toolkit have to do with native applications in general? Sure, there are some legacy and niche apps that are native on desktop People still use office suites, raster and vector graphics editors, CAD, 3D modelers, meshing and texturing tools, media players, P2P clients, text editors, var…

You went on to list a bunch of niche app classes except for two:

1) Office suites --> Largely a legacy app suite... and web use is increasing for both Office and due to Google Apps.

2) Media Players -- Playing local media is done by native apps, but that is becoming an increasing niche scenario. I posit that Netflix, Pandora, and YouTube dominate other media players.

The most important native app that most people use is their web browser. :-)

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

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

Both Android Studio and XCode will give you usable iOS and Android code from visual layouts. I've found that usually the easiest way to prototype an interface is just to build it for real - it's faster than Photoshop, even.

The hard part about X-platform mobile development is that oftentimes you need different product concepts on Android & iOS, because the idioms, best practices, device capabilities, and user expectations are different on each platform. So your client generally has to be ground-up development by an experienced expert in the platform, you can't just take the same layout and make it run on both.

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

#370
post #124

Earlier quoted context omitted.

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.

Using flash to deliver video on web was a chore and nobody was doing it right.
Post reply on HN