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

241–250 of 515 posts

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

#241

Post by TazeTSchnitzel »

Margh wrote: post #146
pjc50 wrote: post #9

Four points: a) Tooling: yes, it's still much easier to debug a native app than a pseudo-native app. b) "Emulating native leads to bad UX": this section is absolutely right. Stop hijacking scrolling and building in cruft. c) "Hassle-free web": absolutely right. You don't need an app for that. Just give us the information and let us have the basic interaction we want. No, you shouldn't present your menu as a PDF eithe…

> It's hard to deep-link into an app. Disagree. Case in point: steam://friends https://www.iana.org/assignments/uri-schemes/prov/steam /s/ steam for news://home or news://business/26-05-2015-oil-prices The content could (and definitely should) still be html, obviously not everybody you link to is going to want to install the news app and it should fall back to opening in a browser, but if you want to wrap a fancy int…

Links into native apps are great!... Until someone doesn't have it installed

The few successful native apps with linking (iTunes, Spotify) go via the web.

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

#242

Post by pjmlp »

LunaSea wrote: post #219
cjslep wrote: post #70

Earlier quoted context omitted.

> Native apps are by definition less portable than web based ones. I don't believe it is that clear cut. I think you are ignoring the fact that native developers have frameworks of their own. Using Boost, GTK+, or Qt gives various layers-of-thickness over the OS so the native code is portable. Some, like Qt, also cover mobile operating systems as well as desktop ones. These frameworks are not young either; so while w…

I haven't seen anyone use Boost, GTK+ or Qt cross mobile / desktop.

Dropbox at CppCon 2014,

"Practical Cross-Platform Mobile C++ Development"

https://www.youtube.com/watch?v=ZcBtF-JWJhM

MuseScore

http://showroom.qt.io/musescore/

Qt show room has many others - http://showroom.qt.io/

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

#243

Post by tim333 »

>I think we web developers should advise news sites, and in fact any site that prioritises features over performance, to go native

As a user, I have no interest in that. On the front screen of my phone I have the 'google news' icon which is a link to a web page with links other news web pages. Why would I want 20 siloed apps for the various news sites I visit occasionally?

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

#244

Post by acdha »

omouse wrote: post #232
nkuttler wrote: post #49

Earlier quoted context omitted.

> After 25 years, why do web designers need to create their own page transition mechanics for long-form articles Why do you need page transitions for articles at all? The only reason I can think of is for more ad displays. Ok, if you have, say, a long manual with multiple chapters that would be several hundred pages when printed it can be nice to break it up, but that's probably not what you meant. > photo galleries…

It looks like you've brought up the most important point: the design of a page is altered based on advertising revenue. 90% of the JS being loaded is for tracking to increase advertising revenue. Much of the styling for a site that has no advertising can be fairly light. If we focused less on revenue generation we'd have a much much smoother web experience that would run quickly on mobile devices.

> If we focused less on revenue generation we'd have a much much smoother web experience that would run quickly on mobile devices.

I would flip that: we need to explore ways to generate revenue which don't rely on practices like trackers, structuring content to inflate page-views, etc. which don't benefit the user.

The most obvious example I'd use is ArsTechnica's approach of disabling ads for subscribers – I notice this any time I use a new browser and pages take twice as long to load because web performance just isn't a priority in the ad world.

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

#245

Post by stephenr »

TazeTSchnitzel wrote: post #238
stephenr wrote: post #198

Earlier quoted context omitted.

> What about the benefit that the web brings to updating the user's install What about the detriment the web brings to having apps that work offline reliably and ensure control over their own data? > Notify the users to keep their equipment on the network from time X to Y Not your problem. Have your packaged app in the place its expected to be updated from (a HTTPS server for something like Sparkle framework, and/or…

> What about the detriment the web brings to having apps that work offline reliably and ensure control over their own data? The web has supported this for years, but few use it.

Care to name the technology that allows a browser app to read/write file data to local storage that isn't inherently tied to the browser?

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

#246

Post by thatcat »

jamespo wrote: post #195
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…

The business realities make direct, free, downloadable videos impossible rather than unlikely at scale.

>business realities make direct, free, downloadable videos impossible at scale

And yet it's existed for years using p2p/torrents. So they're more like business fictions

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

#247

Post by TazeTSchnitzel »

the8472 wrote: post #121
sytelus wrote: post #33

Web APIs are in essence becoming an abstraction layer between OS and applications. It's not just about browser anymore. Browser is just one of the host for these APIs. In next decade or so, we should have all the power built in to standards that eliminates pretty much any advantage that native application can possibly have - even for heavy duty 3D gaming and offline video editing scenarios. Web APIs will and should b…

> Web APIs are in essence becoming an abstraction layer between OS and applications. Terrible ones at that. In native applications you can bypass abstraction layers when you need it. In a browser you are restricted to a almost comically crippled version of what any native APIs provide. Look at the API. It's fairly modern, and yet I can't even turn off premultiplied colors, which I would need for doing even semi-decen…

> yet I can't even turn off premultiplied colors

What are those? If you're talking about alpha, that can be bypassed.

> server sockets? udp? no dice.

The web platform doesn't allow protocols which bypass its security model, sure. But you do have other ways to communicate, WebSocket (over TCP) and WebRTC (over UDP).

> But can I grant a website access to some cordoned-off subtree of the filesystem?

Not yet, but you do have your own filesystem.

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

#248

Post by untog »

joshstrange wrote: post #199
k__ wrote: post #164

Earlier quoted context omitted.

I read that Appcelerator Titanium and NativeScript are a much better way. You can use much of your JavaScript skills and still get to go native.

Unless that platform has changed completely in the last year or so then they are wrong. Appcelerator (and things like it) generally make "Hello World" super easy and even the first week or two will be awesome. Then the cracks will start to show. You will add a listener on a button and the app starts crashing with a cryptic error, you start having to litter your code with `if(isAndroid)`/`if(isIOS)`, or for some reaso…

I agree with most of what you say, but:

you start having to litter your code with `if(isAndroid)`/`if(isIOS)`

That's an inevitable drawback of a cross-platform framework like this. XCode and Android Studio only work with one OS, so they sidestep it.

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

#249

Post by TazeTSchnitzel »

rimantas wrote: post #120
sytelus wrote: post #33

Web APIs are in essence becoming an abstraction layer between OS and applications. It's not just about browser anymore. Browser is just one of the host for these APIs. In next decade or so, we should have all the power built in to standards that eliminates pretty much any advantage that native application can possibly have - even for heavy duty 3D gaming and offline video editing scenarios. Web APIs will and should b…

> Web APIs will and should become the standard way of > developing apps across platforms God forbid. There are few lamer things than those Web APIs. Why do you think the gazzilion of frameworks exists, if not to work around all the things broken? And take a look at the web in 2005 and now, see what real progress was made. Yep, we got a bunch of half-baked APIs, which will never mature, because all the crowd already r…

> Why do you think the gazzilion of frameworks exists, if not to work around all the things broken?

Actually, most frameworks don't work around anything.

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

#250

Post by jessaustin »

Dewie3 wrote: post #168
Fr0styMatt8 wrote: post #135

Earlier quoted context omitted.

It's interesting that you mention YouTube, because the thing that finally convinced me that a 'web app' could be indistinguishable from a native app was YouTube's Leanback interface (YouTube TV). Check it out: https://www.youtube.com/tv Video player functionality aside (I understand the complaints), that thing full-screened just feels like a native app.

> YouTube on TV is not supported on this device? Is it only for mobile? I didn't see any "mob" or something in the URL. Anyway, with regards to being indistinguishable from native , I guess there is nothing quite like being reminded that you are "native" than an app complaining that you are on the wrong native device. :-)

Works fine on Ubuntu desktop, vivid, [EDIT:] chrome.
Post reply on HN