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

371–380 of 515 posts

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

#371

Post by Too »

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.

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

#372

Post by vezzy-fnord »

kenjackson wrote: post #368
vezzy-fnord wrote: post #342

Earlier quoted context omitted.

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…

I'm sorry to say, but your definitions of "niche" and "legacy" are extremely heterodox and I can't have much of an argument under these semantic constraints.

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

#373

Post by baddox »

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…

YouTube's video playback problems might have nothing to do with the web. Despite having an iPad app that is otherwise mostly great, their iPad video player itself is abysmal. It's just flat-out broken, and they're presumably not going to fix it. If you start playing a video, the timeline at the bottom will start turning grey from left to right to indicate the part of the video that is buffered. But if you scrub to a position in the timeline that is buffered, the video player will spin for a rather long time, and sometimes just spin forever until you scrub to a new spot or manually change the video quality. Bizarrely, if you scrub to a position in the timeline beyond the buffer, the video will load nearly instantly like one would expect. Somehow the buffered video loads slowly, while unbuffered video loads quickly. It's a huge bug, it's been in the iPad app for as long as I can remember.

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

#374

Post by baddox »

the8472 wrote: post #144
adamc wrote: 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.

> It also benefits hugely from urls, which allow users to share what they've found. how about http://some.storage.service.tld/path/to/video.mkv or even rtmp://some.streaming.service.tld/path/to/stream ? For sharing that would be sufficient. Of course there are some business realities (ads, copyright, paying for storage) that make direct, free access to videos unlikely. But that's basically arguing that the web is a s…

> how about http://some.storage.service.tld/path/to/video.mkv or even rtmp://some.streaming.service.tld/path/to/stream ?

Well, if I click on the first link, a video doesn't play (that would be the case even if the link were to an actual MKV video). The second URL isn't even a hyperlink on news.ycombinator.com. But if I click on a valid YouTube link, a video plays nearly immediately.

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

#375

Post by carsongross »

I broadly agree that trying to completely mimic native apps with the web is unlikely to yield great results, and the author points out some of the obvious strengths of web applications (in an update he mentions URLs, which he missed initially. https://www.youtube.com/watch?v=i28UEoLXVFQ).

I think he underestimates the web, though. In particular, there is one aspect that he fails to mention and that I view as one of the best aspects of web development: the stateless request-response-replace-UI model of remote application development. This model is incredibly simple for developers to understand and work with, and eliminates a whole slew of complex problems found in traditional client-server development.

(I would note that these problems are being reintroduced with client-side web technologies like Angular and de-reintroduced by technologies like intercooler.js.)

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

#376

Post by TazeTSchnitzel »

archagon wrote: post #329
TazeTSchnitzel wrote: post #258

Earlier quoted context omitted.

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 arrang…

Beyond views you need a way to layout them. Would you not be simply reinventing the DOM?

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

#377

Post by Too »

dasil003 wrote: post #252

I get where he's coming from, but I don't think it gets to the root issue: Why does everything need to be a "rich experience"? Note I didn't say app-like, because many apps themselves are straightforward. If we don't make that distinction then we risk throwing out the baby with the bathwater. He cites having to build "2 native apps" instead of one website, but that's only true if you ignore everyone who is not on rec…

The no-install, and especially the sandboxed environment, is an argument that hasn't been discussed much here yet but which i think is a big factor to take into account. Sure, device and browser compatibility is nice but really, being able to open a news site without having to share my contact list, my location and my photo album is what makes the web a no-brainer.

If native installs could cater more for this scenario it could win some more ground, especially on windows, there you have no control at all over what goes into your machine. Android Play store and and Apples App store would also need to improve on this. They pretends to have support for it but the permission categories are all to vague, they are either all or nothing, and they have been abused to the point where nothing can be trusted any more.

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

#378

Post by c22 »

monsterix wrote: post #166
msl09 wrote: post #155

Earlier quoted context omitted.

I would like to complement that native youtube(the one used on mobile) is far better at playback while keeping nearly every other advantage that it has on the web.

> that native youtube(the one used on mobile) is far better at playback. No, it is not. Playback would get stuck, sound would go away for no rhyme or reason and what not. Better experience? - no - quite the opposite. I got rid [1] of the native nuisance completely. And the experience of search, comment and history on native was simply terrible . Much lesser control on ad-blocking too, and really the ads on YT are som…

I haven't tried YouTube on IOS but the native YouTube app for android is better than watching YouTube videos in mobile Chrome for me.

Evidence: ^

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

#379

Post by thatcat »

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.

>imagine having to install a plethora of apps on everydevice... Well, I don't have to imagine this because Youtube and Netflix both make you install apps. Flash and silverlight. You can opt-into the html5 streaming on yt, but that's still a change you have to make.

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

#380

Post by krick »

I pretty much agree with the post, even more — I like to agree with it. But there's a problem.

The problem is there's no stuff like "web/native app": there's a bunch of functionality that solves user's problem to greater or lesser extent. Although there are needs which are technically complex, usually what the user can ask for is pretty simple. Clean UI, button here, button there, some lights and pop-up notifications, a couple of graphics, which actually represent something pretty trivial internally. Sometimes the data needs to be pushed to or retrieved from some centralized storage or it needs to talk to some other "service". "Browser" is absolutely awful and pointless invention, but unfortunately we have accepted it somehow and learned to satisfy the needs of typical customer using it. HTML might be stupid and CSS might be inconsistent, but it's actually pretty easy to make the UI user wants with that and a handful of js code.

As a bonus, it will work on Linux, on Windows, on Mac, your Android phone and even some not-a-real-OS which happens to have a capable browser.

And what we have on the desktop? I don't know a single good UI framework for Linux ("good" in a sense it would make it easy to achieve what I want). There's somewhat usable WPF for Windows, which still doesn't really allow to implement anything user could wish for as easily, as I'd do with HTML. Somewhat usable, but pretty verbose is Android UI framework. I don't know what happens on Mac. And, yeah, none would be compatible between different platforma (except Qt, maybe, which is overly complicated by itself).

So there isn't much choice between "web and native". The "native" is currently pretty much non-existent.

Post reply on HN