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

51–60 of 515 posts

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

#51

Post by dottrap »

wolf550e wrote: post #12
frou_dh wrote: post #10

Earlier quoted context omitted.

Is a "win" for the developer necessarily a win for the users? Whose experience takes precedence?

If cost of developing app is halved, many more apps will be built. The choice is often not between "expensive native app" and "cheap hybrid app", it's between "why is it so expensive? but I can afford this (hybrid app)" and "no way that's too expensive (native app)".

In theory, this might be true. In practice, I find that it is just an excuse to cut corners and ignore the problems.

I recently had to help somebody with their public library and a particularly magazine publisher for digital issues. They require a web app to read the issues. They were trying to use their Mac, but the site refused to load. The public library staff had no clue why it didn't work ("well, it works for us", and their attempts to contact the publisher was your stereotypical tech support horror story.) Long story short, their website doesn't work on all browsers. They implicitly know that it doesn't work in Safari because they apparently wrote a native app just for iOS. However, they have no native app for Mac and never bothered to fix their website.

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

#52

Post by mozumder »

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…

> 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 HTML without sections.

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

#53

Post by jasode »

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

Do some "native" apps do nothing more than what a 100% static HTML could do? Yes, abuse of a Javascript widget framework does happen. However, the bad examples don't mean the "web" should be held back by the original visions of HTML or Hypercard. The Google maps app is not traditional HTML+CSS.

EDIT: The replies misunderstand my position. I'm not trying to redefine the traditional technical meaning of "web" and make you like it. I'm attempting to explain that "the web" has evolved and what it now means to the world out there. (E.g. see non-document usages like Dropbox, google maps, online Sudoku games, etc.)

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

#55

Post by aliakhtar »

KaiserPro wrote: post #34
orthoganol wrote: post #14

So, the OP is adverse to the JavaScript single page app fad, because in his opinion it is overly complicated to try to get a web app to behave like a native app, and instead should embrace its "weby-ness"? Is he just thinking about developers who have to use the tools he does not like, or the consumer experience side of it too?

Single page apps are in my experience a massive faff. They may look good, but they tend to break things like back/forwards have text that can't be copied and pasted. Some have embedded video, which eats everything.

> they tend to break things like back/forwards

That's not a requirement for building a single page app, there have been ways of emulating history in spas for a while now.

> have text that can't be copied and pasted

What do you mean? SI'm not aware of any sites whose text 'can't' be copied unless they disabled right clicking.

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

#56

Post by dottrap »

onion2k wrote: post #37
frou_dh wrote: post #10

Earlier quoted context omitted.

Is a "win" for the developer necessarily a win for the users? Whose experience takes precedence?

I don't think the tools we use impact the user experience that much, certainly not as much as the designs we use or the UX choices we make. If a hybrid app has a bad user experience it'd probably still be a bad experience if it'd have been built as a native app instead.

The article calls out scrollbar hijacking. That is a very example of the tools screwing up the user experience.

You generally don't have those problems in native. Apple in particular designs their APIs to steer you in the right direction and make it painful for you to do something that goes against their UX guidelines.

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

#57

Post by pornel »

To me the worst side-effect of naively chasing "native" is permission prompts.

The web platform wants to have powerful features that are dangerous and/or easy to abuse, but haven't found a good way to allow them safely.

The "solution" we've settled for is to blame the user for clicking "OK" on permission prompts that have unclear consequences to non-technical users.

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

#58

Post by charliefg »

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…

This is clearly just my laptop (or maybe firefox) but that google site took about 30 seconds to load up. Every time I click on the tab that has it open - my computer fan whirs up to near full speed and it locks up firefox's graphic rendering until it finishes the page. Once loaded there is an unusable level of lag on the browser and CPU usage is levelling at 55 odd percent.

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

#59

Post by xt »

zhte415 wrote: post #47
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-…

There's an answer to your questions. It is documented here: http://motherfuckingwebsite.com/

This is what you want => http://bettermotherfuckingwebsite.com/

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

#60

Post by bobajeff »

Yeah, this is kind of what I've been thinking:

Let data be data. Let features be features. And let user interfaces be user interface. So many websites mess this up in order to deliver a quick working site that only works on the desktop and sometimes only Windows. And now we have sites making seperate ghetto mobile versions or mobile apps missing features. We still have data that can't be accessed through URL with text that can't be selected or shown without JavaScript loaded.

Unless you are doing something more complicated than content devilery (ie games or utility apps) there is no reason to override fundamental features of the web.

Post reply on HN