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

251–260 of 515 posts

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

#251

Post by duncanawoods »

pjc50 wrote: post #208
duncanawoods wrote: post #185

Earlier quoted context omitted.

>> If there's anything where you wouldn't expect significant >> value-add from the native or pseudo-native experience, it would >> be news I strongly disagree. I see "the news" is a perfect counter example because technology has changed what news is . Its not daily static content anymore, its now real-time, multi-media, interactive and interconnected. The types of media on a news page include: recorded video, live fe…

.. but all of that is already being presented quite well in web pages?

...with today's web and IMHO its a great success.

I'm arguing against the parent that claims Web 0.5 (vanilla hyperlinked documents) is enough for the news. This is only sufficient to duplicate a newspaper and present prose\pictures of what happened yesterday. I claim that technology has dramatically changed the fabric of news itself which now requires the modern Web with its document/app blurring to include dynamic behaviour, interactivity and multi-media.

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

#252

Post by dasil003 »

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 recent versions of Android or iOS (certainly you're not going to support iOS The web is no-install, ubiquitous and accessible in a way no platform has ever been and which is impossible for any proprietary platform ever to be, and is backwards-compatible. Given these strengths, the effort to bring app-like functionality to the web is well-founded, because difficult though it may be, the converse of bringing the web's benefits to native apps is just plain impossible.

If when marketing wants to create these experiences we tell them to go native we're just shoveling the problem off to the poor native developers. The first step should be determining the value of said "experience", is it there to serve the user or is it there win awards?

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

#253

Post by [deleted] »

lotsofmangos wrote: post #147
coldpie wrote: post #126

Earlier quoted context omitted.

> A little less contrast > Size Matters Strong disagree on both of these points. I view most webpages (including that one) at around 66% zoom these days, because the text is so goddamn big. And anyone advocating for less contrast needs a shovel to the head.

anyone advocating for less contrast needs a shovel to the head. Or they have the thing where high contrast makes the letters jiggle and therefore difficult to read. I get that when tired. Maximum contrast does not make for good general usability, even if you happen to like it.

[deleted]

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

#254

Post by pavlov »

thekingshorses wrote: post #233
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 H…

I don't see the point of comparing HN apps. HN is a website and doesn't do anything meaningful as an app.

Android 5.x has less than 10% marketshare, and 4.x seems quite resilient in low-end devices. It's going to take a while until you can build hybrid apps exclusively for Lollipop.

If you don't think mobile browsers have performance issues, you must use high-end devices exclusively.

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

#255

Post by Confusion »

karl42 wrote: post #159
felipeerias wrote: post #100

Earlier quoted context omitted.

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.

Using pages to display text is fine. I regularly use space to scroll a page down when reading a long text in the browser because it is more pleasant than constantly scrolling. But fixed pages should not be part of the document markup in most cases. Reading a PDF on my phone is not a pleasure just because I can't just flow the text to fit my device.

You youngsters with your newfangled 'book' things. You'll have to pry my papyrus scrolls from my cold dead hands! Pagination, bah...

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

#256

Post by TazeTSchnitzel »

amelius wrote: post #23

> Is it the web’s purpose to emulate native by inserting yet more features? Certainly not. In my opinion, the problem with the web is that it has become too complicated. In an effort to make the web simpler for the ordinary user, the web has actually become a more complicated place for the (advanced) developer. HTML, CSS and javascript have grown so complicated that they lack certain desirable properties, such as ver…

> HTML, CSS and javascript have grown so complicated that they lack certain desirable properties, such as verifiable security, flexibility.

Verifiable security? You can't statically verify a program is secure.

Flexibility? The complexity has given it greater flexibility.

> For instance, a developer has no choice of programming language, but has to resort to javascript

Just like on native platforms, where the developer has no choice of programming language, but has to resort to machine code!

Unless you use a compiler. Which you can do, and it works very well.

I thought you thought complexity was a problem? Introducing "native" other-language support would only increase it.

> also, the developer has no choice of render engine

I thought complexity was an issue?

But this is also not true. You can use your own if you really want to.

Although why you need your own rendering engine is a good question. Almost all native apps use the OS's GUI framework.

> the developer has no choice of render engine, and to make matters worse, the developer has to write code that is compatible with about five different platforms (desktop/phone/tablet)

Who said they did? They can choose to write code that doesn't work well on other platforms. Though that's largely a UI thing, the code will run on any without changes.

> And of course, the fact that those platforms are not identical is also due to the fact that the web is too complicated.

What? From a code perspective, if it runs on one, it runs on the others. The API is the same. The only difference is UI: screen sizes and input methods.

> We need simpler primitives

We have those. If you want to run a 50MB C++ GUI framework in the browser, you can! It's just a terrible idea.

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

#257

Post by TazeTSchnitzel »

castell wrote: post #64

This article feels dated. If he wrote it in 2011, I would agree with him. Web apps don't try to recreate the native UI anymore - something that used to be the case some years ago in the iOS1-6 era. Nowadays the UI of Android 5+, iOS 7+ and WinPhone7+ look very simple and Web-alike. Simply avoid bloated outdated big JS libraries and use a minifier to shrink the JS and CSS files. I thought the trend reversed as many li…

Don't just use a minifier: use something that can eliminate dead code, like Google's Closure Compiler in advanced mode. Don't ship 10MB to the client if you only need 1MB!

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

#258

Post by TazeTSchnitzel »

archagon wrote: post #62

It's clear that the web has outgrown its original intent. Instead of just being a simple substrate for linked documents, many (if not most) websites are now trying to emulate applications, platforms, and services using the poor, ill-suited DOM. But I don't think the solution is to give up. Native apps are great, but there's a vast gulf between the binary running on your device and the server you got it from. Download…

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.

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

#259

Post by EliRivers »

Navarr wrote: post #235
EliRivers wrote: post #8

Earlier quoted context omitted.

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.

This is only true right now

It will always be true forever, or at least for as long as a web browser is a program run within an actual operating system.

It's not a competition. Pick the right tools for the job. If the job is getting your eMail or playing a relatively simple game, and a web browser abstracting as an OS can support your needs, knock yourself out.

If the job is something a bit bigger than that, use a more powerful OS.

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

#260

Post by netfire »

Here's the problem: native apps require downloading, updating and take up more space on the device. I think the mobile web could be much more than it is now, but mobile web browsers seem be improving at a very slow pace. One of the main reasons for that is that the creators of the mobile operating systems benefit more from an app store environment, where they can take a cut of the sales of an app, so they have little motivation to improve the browsing experience.

There's no reason that mobile browsers couldn't expose more internal access to components or controls (and UI options) that are currently only available to native apps.

Do we really want to be restricted to a environment where if we want to release an update to our app, we have to submit the update to the third party for approval? (which can take days) and where users have to download your app to try it out?

We shouldn't concede defeat. We should demand more from mobile web browsers.

Post reply on HN