Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

311–320 of 515 posts

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

#311
post #124
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.

> It also benefits hugely from urls

What about URLs mean that a native player can't use them?

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

#312
post #47

The web works best as a document platform. All the UI tricks that web developers work on all end up managing something related to just browsing/reading a document. It's amazing that modern browsers/HTML just don't have this basic user experience down. Why is it virtually impossible to read long articles on a web browser? After 25 years, why do web designers need to create their own page transition mechanics for long-…

There's an answer to your questions. It is documented here: http://motherfuckingwebsite.com/

That is beautiful. Perfectly expresses how I feel about the web today...

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

#313

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.

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.

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

#314
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 sensors and other capabilities to tap into, where a standards web has to catch up. But I think this gap too will go away as mobile HW matures.

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

#315

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…

>>> There are a lot of advantages to using web tech (cross-platform, easier to develop, easier to push updates)

Yeah. This shouldn't be overlooked. In some cases (solo founder, bootstrapped, etc) a hybrid app might be a great choice for v1.0. Sure, it won't be fast on the phone... But it probably will be pretty fast to develop and release on multiple platforms. Especially if you don't have experience in iOS/Android dev but plenty of background in Web. Sure, if it gets traction you should rewrite it in mobile at some point. But as a prototype, I am totally cool with hybrids.

I'd guess these are not the cases that the OP meant, but still I wouldn't say that the web lost. It has fair share of use cases.

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

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

Indeed, that's why I think it's a mistake to copy native with problems plaguing it (when we don't know how to add these features without the downsides).

I'd prefer the Web to stay safe and hassle-free, and use native apps—with the risk of letting malware in—only when I really need more powerful features.

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

#317
I've always felt that (with respect to desktop work specifically), the reason we're in the web-app world we are today was in part due to the stagnation of window management in the 90's - 00's Windows era. Tabbed browsing for web browsers was created pretty much to overcome having a gluttonous and unusable taskbar after opening just a few applications. From then on, I feel users were primed to want an alternative, which web apps ultimately gave.

Further, to talk about the speed hit associated with web apps, laptops and desktops are still primarily sold with old-school hard disk drives instead of solid state (unless you pay a big premium, which most people don't want to do). Frankly, opening a native application on an older machine (and for most users, one which hasn't been defragmented even once) was an awful waste of time. But Google Docs? Heck, you didn't even need to be on the same computer to access those files. Not to mention trying to update these apps being a massive chore on these slow machines. Heck, most people didn't ever update their browsers until Mozilla and Google imposed it upon users.

While I'd like a world where the browser is not an abstraction layer for an OS, I do recognize that these web apps exist for a reason.

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

#318

Earlier quoted context omitted.

Why is it being tied to the browser a problem?

I think he's saying "local file access" in a very strange way, i.e. he wants out of the browser sandbox.

When did having my own data stored in regular files become "strange"?

If the data is tied to a browser, how do I back it up/save a copy of it? How do I persist it when the browsers local settings/cache are cleared (either by clearing or eg. when the OS is installed)?

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

#319

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.

Ah, the golden era of RealPlayer.

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

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

Maybe I'm misunderstanding something here, but I don't think the argument is to cede the web to documents, but I also don't think the idea is to cede all functionality to apps.

I think the problem is the hype about native apps and everyone wanting an app without understanding their purposes, utility, and unique characteristics. There are situations where a web app / site is the exceedingly more appropriate solution, but there are other uses where a native app is equally exceedingly more appropriate. The problem is that people are having a difficult time discerning the two and the appropriateness of each.

I don't agree with this article and the sentiment about the critical question being whether people want your icon on their homescreen as being the differentiating characteristic. What is not discussed is the possibility for putting the icon on the home screen as a link to a web view that can function the way a native app can function. It even addresses a question regarding distribution if you simply ask your user whether they want to "install" or add an icon to their homescreen to install your "app" / web app / site. It can be designed in such a fashion that it is indistinguishable from a native app of a certain type that has rather narrow requirements.

Post reply on HN