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

381–390 of 515 posts

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

#381

Post by c22 »

pyre wrote: post #331
codingdave wrote: post #293

Earlier quoted context omitted.

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.

> Remember, on the web, you are the product. The same goes for many other things: - Movie theatres in the last few years (commercials before movies) - Television since the days of black-and-white TVs. - Radio dramas "sponsored by X" before TVs existed. How has anything changed?

"On the web you get to choose what kind of product you want to be."

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

#382

Post by zokier »

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.

But having URLs or discovery or social features is orthogonal to using web tech, especially in the front end. Eg. Spotify had all of those in a tight little native client, before they rewrote it with web stack with controversial results.

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

#383

Post by z3t4 »

So the customer/users want a native app!? Fine, I'll just bundle the web app with Webkit (io.js) and they'll be happy, and I don't have to worry about the app breaking in new browser versions.

Browser based applications are much easier to distribute and adds a security layer, so that you do not have to worry as much about trojan/viruses, compared to installing executables from cr4cksnh4cks.com

The browser is the perfect container. And it also helps a bit that the API's are super easy to work with. Making even the novice programmer productive and able to create powerful applications.

One reason why native is bigger on the smart-phone market is that Google, Apple and Microsoft want to completely control their ecosystem and lock people in. What I can not understand though, is why Google does it, as the majority of their income still comes from the word wide web. They have however made major advances on that front lately, to there is still hope.

As the virtualization technology advances, the gap between running on bare metal and in a container continuously decreases. So there will be little incentive running native/bare metal in the future.

We have a long way to go though. If you want to build something that make full use of the hardware, you still should go native. But I hope that changes in the future.

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

#384

Post by zokier »

krick wrote: post #380

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…

Have you checked QML? It is kinda mix of "native" and "web".

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

#385

Post by jasode »

weland wrote: post #355
jasode wrote: post #237

Earlier quoted context omitted.

>The term was easy to repurpose. But the World Wide Web is very much here and very present. And educated programmers call various text styles, "fonts" even though technically, a font is actually a specific size, and specific weight of a "typeface". The "font" is a subset of "typeface". Even though typefaces still exist, almost everyone uses the word "font." And programmers will also call SQL (without CTE) a "programm…

> Today... if we have Dropbox/GoogleMaps/Sudoku/etc, with millions of users as reality, what does "web" in "web app" really mean? The "http+html" has become a universal transport mechanism (with some apps even tunneling through http to do interesting things.). HTTP + HTML does not include "the whole Internet stack, TCP/IP, DNS routing etc.", as you mentioned above.

You're right. 1000x I agree that TBL's http specification and the html specification is not TCPIP and DNS.

However, that wasn't the level of conversation I was trying to have.

There is another viewpoint of http+html that is not the specification. That viewpoint is the usage of http/html/TheWeb.

For example, the White House is building made of stone. It is not a human. So how can newspapers say "the White House has signed the Internet Freedom Act into law." Well, we're not getting anywhere going round and round in circles insisting that stone buildings have no agency to pick up a pen and sign a document and that only a human like President Obama can do it. There are multiple meanings of "White House" and we seem to get along fine with it.

There are also multiple meanings of "web." It's possible for the industry to invent a totally separate word besides "web" for the abuse/reuse of http+html as a transport for apps but that didn't happen. If a startup in Silicon Valley has a goal to release an app that makes use of TCPIP+DNS with the best chance for wide adoption, they can entertain the idea of using a custom UDP+port scheme... or they can just piggyback on http. They didn't use http as Tim Berner-Lee's specified in 1989. It's the out-of-spec usage that's adding new color to what modern "web" means.

I'm not saying I approve of it or it's technically superior. They didn't ask TBL's permission for it to evolve that way. Is it anyone's fault?! Too late to assign blame now. It is what it is. The phenomena I described above exists no matter what label we give it. It would be awesome if another word besides "web" described it but it doesn't exist (yet).

If the "White House" can act as a synonym for "human", it's not impossible for "web" to act as synonym for "whole internet stack." (Again, the synonym mapping is using the other evolving definition of "web" instead of the official RFC specifications.)

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

#387

Post by wvenable »

z3t4 wrote: post #383

So the customer/users want a native app!? Fine, I'll just bundle the web app with Webkit (io.js) and they'll be happy, and I don't have to worry about the app breaking in new browser versions. Browser based applications are much easier to distribute and adds a security layer, so that you do not have to worry as much about trojan/viruses, compared to installing executables from cr4cksnh4cks.com The browser is the perf…

> And it also helps a bit that the API's are super easy to work with.

Not in the least, you have to be comfortable in a half-dozen technologies at least to make a half-decent web application. You want performance, animations, etc then you better be an expert. And even then, your perfect container is a limited container.

By comparison, building a native app is much simpler. The complication comes in with cross-platform applications.

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

#388

Post by gusmd »

baddox wrote: post #373
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…

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…

That happens frequently on the desktop website YouTube too. It also happens on my Android phone using the native app.

Related to that, if you try to scrub to a position BEFORE what you are watching right now (say, 1 minute before), which is obviously buffered since you have just watched it, it goes full loading-retard again. It's like it just throws away the data it buffered and showed you. It is insanely infuriating.

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

#389

Post by pavlov »

nostrademons wrote: post #369
pavlov wrote: post #28

I feel we’ve gone too far in emulating native apps. Conceding defeat will force us to rethink the web’s purpose and unique strengths — and that’s long overdue. This, a million times. Mobile websites and mobile apps have completely different strengths. The current trend is to develop them both with the same HTML-based toolchains and make them as similar as possible, which ends up being to the detriment of both. Users…

Both Android Studio and XCode will give you usable iOS and Android code from visual layouts. I've found that usually the easiest way to prototype an interface is just to build it for real - it's faster than Photoshop, even. The hard part about X-platform mobile development is that oftentimes you need different product concepts on Android & iOS, because the idioms, best practices, device capabilities, and user expecta…

Both Android Studio and XCode will give you usable iOS and Android code from visual layouts.

Well, for some definitions of "usable" and "visual layouts"!

Our goal is to make a designer's tool that can output complete, store-ready projects for simple apps and for both platforms. That includes three things that neither Xcode nor Android Studio does:

1) Interface Builder and Android Studio's layout editor are not meant for designers. (Seriously, try giving them to a Photoshop-educated designer.)

2) Xcode and Android Studio let you define views, but neither of them produces the controller-level code from visual designs. (We do that and also produce model-level code for simple apps; there's a plugin API for more complex situations, or you can of course do that in handwritten code.)

3) Cross-platform. Anything you do in Xcode or Android Studio needs to be rebuilt from scratch on the other platform.

...the idioms, best practices, device capabilities, and user expectations are different on each platform.

I feel that this doesn't hold true anymore. iOS 7+ and Android 4+ have largely converged on a flat style where a 3rd party app can define its own style that is easily compatible with both.

With Windows 10, even Microsoft is coming into this "common mobile" UI fold. They're giving up on the idiosyncratic (and interesting) Windows Phone concepts, and instead adopting a generic look that makes it easier to port Android/iOS apps directly. They're also offering new APIs and runtimes for that.

(Edit: To clarify, you can customize layouts separately for iOS and Android in Neonto Studio.)

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

#390

Post by coldtea »

haberman wrote: post #284
coldtea wrote: post #79

Earlier quoted context omitted.

> 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. What exactly is incredible about YouTube today (apart from it being a huge repository of videos, of course)? That it almost works like a 2000 era video player, only slower and clunkier? The new fangled DRM? That it can bring a decent computer to its knees with…

> That it almost works like a 2000 era video player, only slower and clunkier? What are you even talking about? If you click on a YouTube link, a video your computer has never seen before is playing in less than five seconds, streaming over the internet. You can instantly seek to any part of the video, even if it hours long. You can speed it up to 2x, or slow it down to 0.25x, without changing the pitch of the sound.…

>What are you even talking about? If you click on a YouTube link, a video your computer has never seen before is playing in less than five seconds, streaming over the internet.

Nothing about this is "web" specific. That's just "streaming over the internet" as you said. Lots of native apps do it too (for both music and video, internet radio, iTunes video rentals, etc.). The reason we didn't have this as widespread before was limited bandwidth connections (a limitation of internet, not of being native).

>You can instantly seek to any part of the video, even if it hours long. You can speed it up to 2x, or slow it down to 0.25x, without changing the pitch of the sound. If you have a Chromecast, you can display the video on your TV instead. Nothing in 2000 had a remotely similar feature set

Again, nothing about what you describe is web specific. Native can do it all and do it better and with less battery crippling cpu usage.

And nothing described -instant seek, pitch shifting with retime, etc- was impossible in native video players in 2000 (or even 1995), while all of it was impossible for the web in 2000.

Which also means things possible for native apps now are impossible for web apps now, which makes sense since native is a superset of what functionality is available in a web sandbox, and with faster potential speed. (And of course being web is not a requirement for accessing internet resources).

Post reply on HN