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

341–350 of 515 posts

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

#341

Post by yellowapple »

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.

Some (most?) browsers still do this when presented with a media file. Firefox in particular will use VLC on my machine for that purpose (or, if it's not installed, some HTML5 barebones media player, or some other media player that can be embedded if one is installed).

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

#342

Post by vezzy-fnord »

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…

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, various format readers and writers, etc. that are largely dominated by native.

Even most non-HTTP network clients (like IRC and FTP) are still predominantly used as native apps because of the far superior experience they bring.

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

#343

Post by wmil »

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.

Before flash could play video, links that open in the media player of your choice were very common.

It was a nightmare. Each media player would try to hijack every link type it knew about each time it ran. But there wasn't full compatibility. So you'd click a link, RealPlayer would try to open it, and the player would crash.

The major players actively fought open standards, because they each had dreams of controlling a DRM & patent gated empire.

Flash brought some sanity to web video. Although initially it had performance issues (it had issues with hardware overlays on some video hardware).

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

#344

Post by nostrademons »

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.

Netscape could do this back in 1995. One of its preference settings let you associate external applications with certain MIME types; when you clicked on a link pointing to a resource of that type, it would automatically open the external program to view the file, as if you had double-clicked on it.

Similarly, you can do this right now on Android. When you click on a link, it fires off an Intent with the URL. Apps can register for this Intent and the user will be prompted for what program they wish to handle the link in. This is how the official YouTube/Google Maps/G+ apps work.

It turns out that for certain types of content, users really, really don't like to wait for external programs to load. It's not a technology issue; the technology has long existed to use rich clients, consumers just don't prefer it.

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

#345

Post by rpcope1 »

jasode wrote: post #53
mozumder wrote: post #19

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

>The web works best as a document platform. This is only true if you constrain the "web" to mean the Tim Berners-Lee document-centric HTML and its http hyperlinks. The "web" also means the whole internet stack, TCPIP, DNS routing, etc. In that case, the web is a foundational tool for anything that connects people or Internet Of Things. To say the "web works best as a document platform" is like saying "the electricity…

>The "web" also means the whole internet stack, TCPIP, DNS routing, etc. In that case, the web is a foundational tool for anything that connects people or Internet Of Things. To say the "web works best as a document platform" is like saying "the electricity grid works best as a lightbulb platform." We've gotten past the historical motivations of a interconnected electricity and have done other things with it.

No, absolutely not. The "web" refers only to what you mentioned above. It's only a recent bastardization that we started referring to the "Internet" as the "web", because of the dominant nature of HTTP. You're right though that the Internet is important, but the GP's point stands that HTTP was really only intended as a document protocol (Hypertext, yeah?) and it has seems a somewhat strange perversion that we've bent it to doing so much more.

Someone not in the know may call the transmission in a car "an engine", or call the differential a transmission. Just because someone outside of the industry does silly things like that doesn't mean all of a sudden obfuscate the usefulness of terminology at all, as it really helps no one.

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

#346

Post by yellowapple »

wpietri wrote: post #193
the8472 wrote: post #144

Earlier quoted context omitted.

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

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 playlists or categories).

Sure, now the user would have to go through the additional work of editing URLs if they want to access this endpoint manually, but then this article's points come into play: if your users expect more functionality than what the World Wide Web does well - delivering content - then a native app is probably preferable for everyone involved (and, indeed, exists for sites like YouTube).

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

#347

Post by capkutay »

UUMMUU wrote: post #184

This is probably going to be an unpopular opinion but I think the current push to make native feelings apps in JS is awesome. Playing with an app like Untappd and then realizing it's written by (at least originally) 2 people and still feels fluid is incredible. I've also never heard anyone except developers complain that it's not app-y enough. True things like games shouldn't be written in phonegap or react-native bu…

This may not be in line with the author's point, but I agree with you. You probably don't need to build a super optimized native app to launch your MVP. Developers should use whatever tools they're comfortable with for getting the job done. In the event that they get thousands of users and need to scale, then they can think about hiring people to build native apps.

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

#348

Post by voidhorse »

webtards wrote: post #86
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…

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…

The framework problem is a real interesting one... I'm a hobbyist--I am not employed as a web developer, but I like too experiment and see what I can create, so for me, learning a new framework is always a fun little project to embark on.

At the same time, i can't imagine how hellish it would be to work for a company that always wants to use the latest technology -- the framework market seems saturated to me, and I would wager it's probably better for a company to find a few technologies and stick to them, tackling problems/weak points as they arise and brewing custom solutions for those if necessary. Having to stop and shift over to a new framework every now and then seems like it would be a massive productivity hit.

I also don't like it when a framework becomes a crutch. Though I don't think that happens too often for most people.

I've also run into the heavy weight problem -- there have been a few instance where I've wanted to create something simple, and in most cases using a framework in that situation becomes the very definition of over kill. So instead I'll usually just write a simple php script or something to do whatever I need to get done, but even that feels a bit unnecessary. While I'm not sure if javascript should be elevated to all the use cases it has been recently, I do think it should be a language that enables a developer to natively(that is to say, w/o a framework) handle any simple functionality that might be expected for a site that is just a little bit fancier than a static site, so handling very simple data such as bare-bones blog or a simple mailing system. While it is getting there you still can't do something like write a simple form based mailer in pure js as far as I know, you can only open the client's native mailing app. You'd have to write a single php file or some other mechanism for that simple purpose.

But yeah, it seems like bloat is a tricky thing to avoid these days, especially since frameworks are the easiest, usually most error proof, and quickest way to get your website full of some modern bells and whistles, when in reality you may only be putting half of the technologies features to use.

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

#349

Post by MBCook »

fixermark wrote: post #324
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.

> It's awesome on the desktop though

Not in my experience. I've never had a native app pop-up a dialog saying "You can't use that menu to copy and paste, you have to use the keyboard shortcut." Instead, the standard platform way of doing things just works. Then there is the fact that Google Docs just refuses to open certain docs in certain browsers.

It's impressive for something on the web, but it's not better than a native app by any stretch.

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

#350

Post by yellowapple »

shwetank wrote: post #183
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.

Also the fact that you can embed youtube videos in other web pages.

If YouTube provided direct links to video files, you could embed YouTube videos in other web pages just as easily thanks to HTML5.
Post reply on HN