Web vs. native: let’s concede defeat • Hacker News Board

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

#231

Post by datashovel » Tue, May 26, 2015, 2:42 PM UTC

jevgeni wrote: post #213

datashovel wrote: post #26

Earlier quoted context omitted.

It seems we have different assumptions we're basing our arguments on. I get the impression that the huge diversity of linux distros is enabled primarily by the fact that more and more development these days is web and not native.

There isn't any great diversity in Linux distros interface-wise. You basically have a handful of distros that use X Windows and one of the four old window managers.

I appreciate that. I agree it's not obvious what, if any differences exist between alot of the lesser-known distros. However I would argue that a large enough sample from the most popular Linux Distros has something substantively unique to offer.

But we haven't even considered BSD-flavor. Perhaps if we expanded to include BSD-based operating systems. To name a few: FreeBSD, DragonFly BSD, PcBSD, NetBSD, OpenBSD.

All of the BSDs mentioned above have a very unique mission.

It's easier for me (as consumer) to choose any one of those to run my desktop / laptop knowing that I'm going to pretty much get all the same access to apps that I would if I were to run Windows or OS X.

Without any reassurance that I'm going to be able to do what I need to do on a BSD or Linux machine, I'm probably going to be stuck choosing something created and maintained by Microsoft or Apple.

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

#232

Post by omouse » Tue, May 26, 2015, 2:43 PM UTC

nkuttler wrote: post #49

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

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

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

#233

Post by thekingshorses » Tue, May 26, 2015, 2:44 PM UTC

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…

I agree with PPK, but sorry to say this: you are just throwing garbage.

> There's nothing more annoying to a mobile user than an "app" that takes 10 seconds to start up

Try this on your mobile browser http://hn.premii.com/

Now download this. Android : https://play.google.com/store/apps/details?id=com.premii.hn Or iOS: https://itunes.apple.com/us/app/hacker-news-yc/id713733435

And play with it. Download top 5 native HN apps, and launch those, and tell me which one takes 10 seconds on which device.

No doubt that you will have to deal with different version of webkit browsers (webview) on android. As long as you follow standards and not use latest CSS rules, you will be fine. And with Android 5.0+, its much much better.

---

Now try this page on your mobile, and tell me how bad it is. This is few hours of work (Flipboard style animation), and works on iOS/Android Chrome/WP8: http://reddit.premii.com/#/r/news

There are issues with browsers, but performance is not one of the issue.

----

It takes time on Cordova not because of HTML, but because how each platform works natively. I am not a native developer.

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

#234

Post by hypertexthero » Tue, May 26, 2015, 2:45 PM UTC

Two problems with native applications:

1. The systems and hardware they run on are usually controlled by one company.

2. There's no View Source.

Where would we be if 'native' applications had won over the '[worst is better][1]' approach of the web? What do you do if you lose your phone and the only way to get information is through an app that was installed on it?

[Alex Martelli][2]:

> Our culture’s default assumption is that everybody should always be striving for perfection – settling for anything less is seen as a regrettable compromise. This is wrong in most software development situations: focus instead on keeping the software simple, just “good enough”, launch it early, and iteratively improve, enhance, and re-factor it. This is how software success is achieved!

Good enough is usually good enough and can be accomplished through a web browser if your design is good and not compromised by 'business decisions'.

There is a place for native apps. Communication applications such as Whatsapp are a good example. Applications whose main purpose is to provide information, such as websites, are not.

Finally, lets not forget that the internet is not a thing, [it's an agreement][3].

[1]: http://hypertexthero.com/logbook/2013/07/europython-2013-not...

[2]: https://ep2013.europython.eu/conference/talks/good-enough-is...

[3]: http://worldofends.com/

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

#235

Post by Navarr » Tue, May 26, 2015, 2:47 PM UTC

EliRivers wrote: post #8

Navarr wrote: post #6

> Native apps talk directly to the operating system, while web apps talk to the browser, which talks to the OS. Thus there’s an extra layer web apps have to pass, and that makes them slightly slower and coarser than native apps. This problem is unsolvable. But what if the browser is the OS? I agree with the point though that we shouldn't be trying to emulate native to the T with web applications, that we shouldn't be…

But what if the browser is the OS? Then the user has chosen, for whatever good reasons, to run a pretty limited OS, and in doing so has chosen not to be able to take advantage of all the things that having a much less limited OS would offer.

> "run a pretty limited OS"

This is only true right now and only if browsers were not working to make more low level stuff available. There is very little limiting about being in a browser these days. Drivers, perhaps. Kernel stuff, perhaps.

But as far as a game is concerned? Or an email application? Or anything in the context of this discussion? Not too much limiting them.

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

#236

Post by snowwrestler » Tue, May 26, 2015, 2:47 PM UTC

the8472 wrote: post #230

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…

> What do people say about it? you want to share youtube comments with people? they are a significant value-add to you?

Youtube comments are great for finding out the name of songs in the background of the video.

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

#237

Post by jasode » Tue, May 26, 2015, 2:47 PM UTC

weland wrote: post #210

jasode wrote: post #178

Earlier quoted context omitted.

But "computer" used to mean a " person who calculates" and not a " machine that calculates". All of us call modern day devices with CPUs a "computer" even though it lost the essence of "human". The usage of words evolve. I 100% agree that ""The web" is defined by a set of traits (hyperlinks etc.)". I'm also adding that "web" also now includes expanded perceptions by everyone else beyond "hyperlinks+http" and that enl…

By the time electronic computers became widespread, very few non-electronic computers remained -- and few of them were human. The term was easy to repurpose. But the World Wide Web is very much here and very present. > To the layman, both actions are "surfing the web". To the layman, a server and a computer are the same thing, and yet calling Apache a computer is incorrect.

>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 "programming language" even though it's not Turing Complete.

Even binary black-&-white-thinking programmers will exercise a lot of leeway with how words are used.

I want to emphasize that this all started with my response to the "web is best as a document platform."

I think most of us can substitute "web" to say "http+html is best as a document platform." That's what TBL meant.

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.). As the years progress, there are more examples of http becoming a "dumb and dumber" generic transport pipe for things that are not documents.

Let's say a startup company wants to create a website to crowdsource music promotions. They want the service to offer programmable access so people can write open source clients. The presentation slide / whitepaper will not use the phrase "internet api". Instead it will use "web api". If every corporate firewall and user' homes computers with Microsoft Firewall had wide open UDP ports, it's possible for the phrase "internet api" to have more currency than "web api". But that's not how history has played out.

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

#238

Post by TazeTSchnitzel » Tue, May 26, 2015, 2:48 PM UTC

stephenr wrote: post #198

virmundi wrote: post #163

What about the benefit that the web brings to updating the user's install? I know that it is technically possible to push a new Java or .NET app out to users. I've done it. The one thing it requires is a lot of coordination. Notify the users to keep their equipment on the network from time X to Y. Notify the infrastructure team to schedule a push. Have the dev team on standby in case the push goes bad. Have the softw…

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

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

#239

Post by plorkyeran » Tue, May 26, 2015, 2:48 PM UTC

felipeerias wrote: post #100

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…

Have you tried to disable pagination in reading apps like iBooks or Instapaper? Long articles and books are more comfortable to read if they are paginated: one small tap, one pageful of new stuff. Far more convenient and less prone to losing your place than scrolling.

Yes. I gave pagination in Instapaper a try, and turned it off after about an hour. I tried to turn it off in iBooks, but there doesn't seem to be any such option in the iOS version.

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

#240

Post by nkuttler » Tue, May 26, 2015, 2:49 PM UTC

mozumder wrote: post #52

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…

> 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. Actually yes this is the use-case I was referring to. HTML has semantics to define sections, headers, etc.. but it doesn't manage them in any way. If you write HTML that define sections, for example, it's no different than if you write HTM…

Section and header tags were standardized last year, it's definitely too early to tell how browsers will handle them, but with the ubiquity of CSS and for the reasons I already mentioned I doubt they will ever get any styling, unless maybe for when no CSS was defined at all.

Ultimately, I don't think of the web as a page-based medium, it's document-based. Electronic documents that want to mimic pages are a relic from the past, imo. What you seem to want should probably be implemented as browser plugins.