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

481–490 of 515 posts

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

#481

Post by kwijibob »

Too wrote: post #371
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…

Google docs is a great example of an app that should not be web. Especially google sheets, brrhgh, i get shivers just thinking about it. Even Excel 98 on a pentium 3 has better performance.

Maybe for an advanced use you hit speed issues.

But Google Sheets has transformed many collaborative functions in our organisation. Especially at budget time.

The ability to have concurrent access to the latest version always is wonderful. No more emailing attachments.

Also being able to sit down at a budget meeting and everyone can view the work-in-progress as it develops on their own device.

In all of this we've never had any one bothered by lack of speed.

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

#482

Post by wpietri »

yellowapple wrote: post #346
wpietri wrote: post #193

Earlier quoted context omitted.

That's certainly not what I want to share. One of the things that good video sites provide is context. E.g.: Who made this? What else have they done? How can I find them? Has this been widely seen? What do people say about it? Raw streaming urls don't get me any of that. URLs aren't just pointers to bytestreams. From a user sharing perspective, they're humans pointing to a unique thing. And what they're pointing to i…

You could easily address those concerns without turning what should be a simple video into a clusterfsck of Javascript. For example: https://mytube.com/$username/my_first_video.ogg With such a scheme, you immediately know who made it - $username - and (if this hypothetical mytube.com built a proper website) navigating to mytube.com/$username would return a list of videos (maybe with some additional routes for playlis…

When most people ask, "Who made this" they aren't looking for a character string that matches /[a-zA-Z_0-9]{3,12}/.

They're asking: what person or persons did this, what might I know them for, what do they look like, how popular are they, do they have a logo I might recognize? YouTube and Vimeo provide that information right next to the video, which is where people want it.

If a native app really is preferable, then I'm sure we'll see YouTube wind down their web interface once everybody stops using it. But my guess is that they'll still have an HTML version long after you and I are both in the ground.

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

#483

Post by tw04 »

adamc wrote: post #124
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…

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.

So why shouldn't youtube just be an index of videos that then launch in a native local application?

The only reason youtube is better on that front is because google.

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

#484

Post by hrktb »

rictic wrote: post #365
hrktb wrote: post #340

Earlier quoted context omitted.

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.

I think youtube is on your side, as it's heavily biased toward random one offs video watching.

I'm always baffled by the suggestions when watching videos from some common series. There would be mostly accurate suggestions, and consistently two or three videos completely unrelated taken from my viewing history. For instance there would be 'Howto repair your dishwasher' in the middle of all the videos of a math channel.

I tend to massively subscribe to channels and watch in batches, so I have (and want to have) a very good idea of what's coming next in my queue.

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

#485

Post by e12e »

ucaetano wrote: post #357
drostie wrote: post #283

Earlier quoted context omitted.

The violation of IP is a similar problem for torrents and YouTube alike. The "4th option" is that you've got the causality completely backwards in your head: it just happens to be the case that the cultures where distributed tooling became important were the ones where it was necessary to promote an "all information is free" mindset, not that it's necessarily a part of distributed tooling that you take that mindset.…

> The violation of IP is a similar problem for torrents and YouTube alike. Not at all, YT solved it many years ago with ContentID. Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.

>> The violation of IP is a similar problem for torrents and YouTube alike. > > Not at all, YT solved it many years ago with ContentID.

I'm not sure I understand. AFAIK youtube currently makes money (from ads) and much of what people view is copyrighted music that isn't properly licensed, and which yt doesn't pay for.

Sure, some, music is taken off yt, and some content is properly licensed -- but are you seriously claiming that yt isn't (any more) making money from copyright infringement?

There's some digital content distributed via p2p legally -- and it'd not be a stretch that yt owes it's current market dominance to "flaunting copyright law" as the copyright lobby might put it.

If one relegated content (video, meta-data, comments) to torrents/magnet-links (there is an issue of loops in the links in content-addressed systems -- but with a pretty modest central server (cluster) serving up a few lists of magnet-links should be affordable)) -- I think it would be quite feasible to distribute digital media in way which the consumers shared in the meagre cost of distribution through mostly donating bandwidth.

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

#486

Post by flurp »

_joev wrote: post #409
mike_hearn wrote: post #399

Earlier quoted context omitted.

Yeah? Spotify, Skype, Google Earth, any developer tool, iTunes, Sonos, Keynote, MS Office, Photoshop, any video game ..... there are plenty of popular native desktop apps out there. I'd say there'd be more too, if the industry made them more frequently. But all we churn out are web apps these days - not because that's what users demand but for all sorts of other reasons.

"Native desktop" spotify is just a web app wrapped into an embedded Chromium browser.

"just" a browser with a lot of native technology baked in to enhance the experience. Playlist caching for one.

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

#487

Post by swhipple »

yellowapple wrote: post #478
swhipple wrote: post #465

Earlier quoted context omitted.

I'm a bit less optimistic. Having different programs for each content type would restrict the developers' control into how they can interact with the users. Simple playback of video? Not so bad. But if you want to swap the source of the video to your 240p version if the video is buffering 'too slowly'? YouTube-like annotations? Show suggested videos after? Developers aren't going to want to support all environment co…

> But if you want to swap the source of the video to your 240p version if the video is buffering 'too slowly'? This sounds like something that should be a feature of the protocol used for streaming (in fact, I'd be surprised if most streaming protocols didn't support such functionality). Even without, this should be possible to do even with a native media player, and many streaming providers offer streams with differ…

I agree that those are all methods of solving each issue -- but I think expecting each player to implement them (and correctly!) is the real problem. And when the standards don't support the feature they want, many developers would fall back to the web. It's hard to compete with a full-featured layout, style, and scripting implementation when it comes to customization.

Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0.

There are web standards now, but, in practice, when you're supporting multiple environments, you're also testing against them. For webapps, fortunately, this usually just entails testing the top 5 browsers for a few versions, and mobile devices if you support them.

If the user comes to support saying something is broken with the video on their native app, trying to troubleshoot their native environment can be difficult, and telling them that their environment might be configured wrong often doesn't solve their problem. Which is why I suspect each site would support specific players.. not being a real improvement over the Gecko or WebKit , in my mind..

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

#488

Post by millstone »

kenjackson wrote: post #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 se…

The last time is probably Photos for OS X (though of course that's not Win32). I doubt that a web app can manage the same number of photos as well.

I think the biggest change is that people have mostly stopped paying for desktop apps, outside of professional tools. I have yet to buy a program written in HTML and JavaScript, though I have paid for content and services provided through such apps.

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

#489

Post by e12e »

thekingshorses wrote: post #288
pavlov wrote: post #254

Earlier quoted context omitted.

I don't see the point of comparing HN apps. HN is a website and doesn't do anything meaningful as an app. Android 5.x has less than 10% marketshare, and 4.x seems quite resilient in low-end devices. It's going to take a while until you can build hybrid apps exclusively for Lollipop. If you don't think mobile browsers have performance issues, you must use high-end devices exclusively.

What is meaningful app? Twitter is list of stories with notifications. For me its more like HN app. HN has list of stories, Twitter has 140 characters tweet. When you click on the HN story, you get list of comments or article. When you click on the tweet, you get replies and retweets and so on. Facebook is a same thing with pictures and videos. Try this http://reddit.premii.com/#/r/pics - enable pictures view from to…

Well, lets see, I use Droidlight but that's by Motorola LLC, so maybe ColorLights. ConnectBot (ssh client). Barcode Scanner (I'm not actually sure if this qualifies as 100% native -- but I think it does). Open Camera. K9 (email - there are others, with different strength/use cases). ChatSecure.

Now, these are all Android apps, and few (if any) have iOS versions. But they all have iOS equivalents -- and I don't think most of them would've been as good, as non-native apps.

Note the absence of stuff that works well as a website, like facebook or twitter. For games, I think the choice between native/html should probably be governed by the answer to:"Is it as much fun as html/webview?". This is a good yardstick for other "apps" as well.

For eg hn, there's no need for an app, but of course hn is a pretty terrible web page. There are a number of easy fixes that would make it more usable, especially on small screens, but the maintainers don't care. And that's fine -- it's not accidentally bad, it's intentionally bad.

One could make a similar site that didn't break voting, threading, screenlayout on small screens quite easily. And it should probably be a web site.

One can make a "web app" to schedule meetings (see doodle.com) -- and one could augment that with something native[1]. Or one could make native apps like the ones mentioned above.

Could one make a web-rtc proxy for ssh and allow logging in to edit firewall rules via web browser? Absolutely. I'm not sure I'd want that though. Not as long as web browser security refuses to learn from office macros: unsigned js code, all or nothing execution etc.

There is some middleground, as google docs demonstrates. Personally I prefer content creation/editing to be local, possible to do off-line (with sync) -- and I'd like competing apps to be able to easily share data (via eg: the file system).

Now, that twitter can't be bothered to make a decent web-site isn't really an argument against web-sites. It's an argument against poor web-sites.

[1] http://9to5mac.com/2015/05/14/sunrise-meet-keyboard/

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

#490

Post by fineline »

flurp wrote: post #486
_joev wrote: post #409

Earlier quoted context omitted.

"Native desktop" spotify is just a web app wrapped into an embedded Chromium browser.

"just" a browser with a lot of native technology baked in to enhance the experience. Playlist caching for one.

localStorage.getItem("myPlaylist")

I'm not saying that's what they use, it could be WebSQL, IndexedDB, FileAPI - local data storage is built into your browser.

Post reply on HN