Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

291–300 of 515 posts

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

#291
post #265
post #168

Earlier quoted context omitted.

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

Works in Chromium on Linux for me. In Firefox (my default br.) the message is: "Youtube on TV is not supported on this device, for more info go to: www.youtube.com/devicepartners" which is unclickable and unselectable. Modern web...

Might require MSE support (Firefox Nightly) or something.

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

#292
post #57

To me the worst side-effect of naively chasing "native" is permission prompts. The web platform wants to have powerful features that are dangerous and/or easy to abuse, but haven't found a good way to allow them safely. The "solution" we've settled for is to blame the user for clicking "OK" on permission prompts that have unclear consequences to non-technical users.

The web platform wants to have powerful features that are dangerous and/or easy to abuse, but haven't found a good way to allow them safely.

The same problem exists on native.

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

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

You seem to be under the misunderstanding that video playback is YouTube's core function. No, the core functionality is to drive traffic to Google-owned sites, to be monetized as they see fit.

Remember, on the web, you are the product.

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

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

The problem is two-fold: it sucks for web developers who end up having to learn a new shitty framework every day, dogshit tools to even work with CSS and JS, endless preprocessor and transpilers, perverted markup and tag hell to support said shitty frameworks and having to deploy massive fuuckton heavy sites for a simple blog post. It also sucks hard for the end users : they can see their whole months mobile data all…

I keep hearing this argument touted, but if you view source on the HN home page it uses tables and a tag.

You do not have to learn a new framework to do things on the web. The browsers all seem to support stuff that's worked for years.

The problem is that web developers feel the need to learn new things because they fear getting out of date. "oh, dude, I learned React this weekend. It's hot stuff! You need to learn this."

No, you really don't. You have a plethera of choices, and one of those choices is to rock it like it's 1999.

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

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

[deleted]

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

#296

Earlier quoted context omitted.

> yet I can't even turn off premultiplied colors What are those? If you're talking about alpha, that can be bypassed. > server sockets? udp? no dice. The web platform doesn't allow protocols which bypass its security model, sure. But you do have other ways to communicate, WebSocket (over TCP) and WebRTC (over UDP). > But can I grant a website access to some cordoned-off subtree of the filesystem? Not yet, but you do…

> But you do have other ways to communicate, WebSocket (over TCP) and WebRTC (over UDP). which brings us back to the crippled versions of the native APIs.

Well, there are some security restrictions, yes. But for most web applications they are not an issue.

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

#297

Earlier quoted context omitted.

To modify the Fight Club rules to ensure X (whatever topic you mention) does not get discussed: 1. There is no X. 2. There are no comments about X. 3. There are no comments about comments about X. 4. (recur away) Oh, wait. This sounds like censorship.

Or just get down voted to where no one can see the comments.

Now I am conflicted do I down vote or upvote? Hmm.. what a dilemma.

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

#298
Telling mobile devs not to use web tech is an example of where this argument (request? demand?) falls down. There are a lot of advantages to using web tech (cross-platform, easier to develop, easier to push updates), and the result is not necessarily worse; it may be better. CSS is a very expressive and powerful layout language, for all its rough edges. Apple uses WebViews in their own apps (like the mobile App Store app).

The rough edges of web tech will only get smoother over time.

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

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

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

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

#300
post #235

Earlier quoted context omitted.

> "run a pretty limited OS" This is only true right now and only if browsers were not working to make more low level stuff available. There is very little limiting about being in a browser these days. Drivers, perhaps. Kernel stuff, perhaps. But as far as a game is concerned? Or an email application? Or anything in the context of this discussion? Not too much limiting them.

This is only true right now It will always be true forever, or at least for as long as a web browser is a program run within an actual operating system. It's not a competition. Pick the right tools for the job. If the job is getting your eMail or playing a relatively simple game, and a web browser abstracting as an OS can support your needs, knock yourself out. If the job is something a bit bigger than that, use a mo…

Take a look at what's currently available in desktop web browsers: maps, document and spreadsheet editing, highly interactive charts, video conferencing etc. (things previously thought impossible/impractical for a web browser to do) If you need huge amounts of data to even run your application, the argument to go native makes some sense, but the browser (even on mobile) isn't as inherently limited as the article describes.

Lets not try to limit the web, but try to make it better and then let the users decide which they would prefer to use.

Post reply on HN