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

321–330 of 515 posts

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

#321

Post by syshax »

flowless wrote: post #309
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 HTML5 video playback on my 3Ghz i7 is so bad that I rarely watch videos in browser. Now it's even worse as all videos play in low quality unless you use DRM enabled "tech". This is what I use instead: mplayer -fixed-vo $( youtube-dl -gf mp4 $* "$link" )

If you have philosophical objections over H.264 because of patents etc., then this won't help.

If you have the HTML player enabled, and if your GPU supports hardware H.264 decoding (most do these days), this plugin may help:

https://github.com/erkserkserks/h264ify

Otherwise Youtube might send VP8, which your CPU has to decode.

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

#322

Post by gedrap »

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.

>>> 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 of maybes. Why risk that if people are used to ads? Ads often come when subscription is not an option.

You can explore other revenue sources (e.g. affiliate) but they are usually not widely applicable. And other than that, there's not much to do. I don't really think there exists a business model which could replace ads (when, again, subscription is not an option).

Yeah. That sucks. But that's the reality.

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

#323

Post by gnaritas »

the8472 wrote: post #85
fizk wrote: 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…

> And yet any media player beats it at its core functionality: video playback.

That isn't its core functionally, it's a social video sharing site, not a video playback site. It's core functionality is social sharing and all that goes with that, comments, related videos, channels, etc.

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

#324

Post by fixermark »

dfield wrote: post #215

The author is correct that modern web applications are hacks all the way down. It's crazy sometimes. But it fucking works! Look at Google Docs, which has changed the way teams collaborate. Look at Unity which recently ported their player to the browser. Look at the Autodesk 123D suite. With technologies like WebGL and Emscripten, we're just starting to see the tip of the "native on web" iceberg. And it's awesome. I k…

And yet Google Docs on a mobile device is a native app, not a web site. The website experience is significantly degraded relative to the native app.

It's awesome on the desktop though, but there are frustratingly good reasons that Google couldn't just run that code on phones and expect it to be anything other than a terrible experience.

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

#325

Post by ethbro »

snowwrestler wrote: post #236
the8472 wrote: post #230

Earlier quoted context omitted.

> What do people say about it? you want to share youtube comments with people? they are a significant value-add to you?

Youtube comments are great for finding out the name of songs in the background of the video.

> Youtube comments are great for finding out the name of songs in the background of the video.

And here I'd concluded the comments section existed to allow pre-teens to practice their ability to make racist remarks.

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

#327

Post by pyre »

piyush_soni wrote: post #299
romaniv wrote: post #289

Earlier quoted context omitted.

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

People had imagined and implemented that long back. They were called plugins. Thank god, media player plugins are dead.

Media player plugins attempted to embed the media player into the browser, which is not what I think is being talked about here.

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

#328

Post by fixermark »

I wonder how many of the issues listed in this article could be addressed if my HTML-based web technologies allowed for a real concept of an "app?"

Right now, we're very much faking it. Every time you go to a website, you're downloading a document that unpacks into code and data in your client. Caching aside (because the cache timeouts are never long enough), you have to do that dance every time you visit. The performance hurdle ppk describes is less about having to go through the DOM to get to your elbow (though that's true) than it is about never being able to precompute and locally cache view logic. That's a performance hurdle that can't be crossed.

In contrast, native apps divide everything quite clearly into "code" and "data." The code is the app you download from the store; it can auto-update, but it isn't trying to pull in a new copy of itself from scratch every time you use it. It can also be pre-optimized for your architecture. The data is only what is needed for the app to present it appropriately to you.

I'd be willing to wager that if a real standard for downloadable client-side cached web apps ever caught on, ironed out the optimization issues, and stuck, quite a few of the performance issues of web vs. native could actually be addressed.

(Of course, we'd still have to deal with the DOM really being the wrong language for a lot of high-interactivity use cases, unfortunately).

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

#329

Post by archagon »

TazeTSchnitzel wrote: post #258
archagon wrote: post #62

It's clear that the web has outgrown its original intent. Instead of just being a simple substrate for linked documents, many (if not most) websites are now trying to emulate applications, platforms, and services using the poor, ill-suited DOM. But I don't think the solution is to give up. Native apps are great, but there's a vast gulf between the binary running on your device and the server you got it from. Download…

What layer can you realistically have below the DOM? If you get rid of it, how can you realistically avoid reimplementing everything? I don't think this makes sense.

I think UIKit (and possibly Android, which I haven't worked with) has the right idea: nested, texture-backed views that can render their own content.

You might argue that canvas and WebGL nodes in the DOM already serve this role, but I disagree. In their current form, these nodes exist inside the document-based world of the web rather than containing it, an inversion of what I see as the proper hierarchy. This arrangement poses a number of problems for designing rich apps, including very poor performance related to content reflow. Some companies[1] are trying to fix this by manually doing all their rendering inside canvas and re-implementing HTML and CSS along the way. Unfortunately, this is a ton of work and results in a web experience that is non-standard in many ways, including for things like accessibility and text selection. The fact that this actually does work to significantly improve the user experience, however, points to the fact that something needs to drastically change for the web to remain healthy, useful, and relevant.

My understanding is that the DOM is already implemented as a series of texture-backed views in many browsers. That would still remain the same — nobody would have to reimplement this functionality. I just think it would be a great idea for us to be able to use those same texture-backed views for custom UI unrelated to HTML and CSS, and to separate the rendering concerns of text and document flow from the design of user interfaces.

[1]: https://news.ycombinator.com/item?id=9029159

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

#330

Post by pjmlp »

ams6110 wrote: post #313
piyush_soni wrote: post #299

Earlier quoted context omitted.

People had imagined and implemented that long back. They were called plugins. Thank god, media player plugins are dead.

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.

That is how Real Player, Windows Media Player and many others work, or used to work back in the early 2000's.
Post reply on HN