> What is it achieved through? Vendor locked, user and developer hostile native app stacks?
Yes, there is Vendor-lock in, you can't deny that. I don't know what you mean with "user-hostile" and "developer hostile".
I - as user - personally ignore anything web based, if there is a native alternative, as I prefer apps that follow the HIG and use the native toolkit of the platform. Sure I'm just a single person, so this is anecdotal.
> And that’s web stack with access to system APIs.
No I fully disagree. A good UX is only doable, if you use native components and fully follow the HIG. I have not yet encountered a good webapp that is on par with a native app that does exactly this.
Anything web based is good for "one code base - available - but subpar - for many platforms", while native apps are "One code base - one platform, but a great experience" (Given you follow the HIG and use native components)
One extremely trivial example: I don't want to accidentally delete e.g. my files, just because some app thinks switching e.g. "Ok" and "Cancel" around is nice.
While yes, web apps have their uses, but they can't match good native apps even remotely.
> Yes, there is Vendor-lock in, you can't deny that. I don't know what you mean with "user-hostile" and "developer hostile".
Anything that locks you in is hostile to you as a consumer.
> I - as user - personally ignore anything web based, if there is a native alternative, as I prefer apps that follow the HIG and use the native toolkit of the platform.
Interface guidelines and toolkit are different matters. You can write native apps that don’t follow HIG and you can write web apps that follow it.
> No I fully disagree. A good UX is only doable, if you use native components and fully follow the HIG. I have not yet encountered a good webapp that is on par with a native app that does exactly this.
What is a good UX?
> Anything web based is good for "one code base - available - but subpar - for many platforms", while native apps are "One code base - one platform, but a great experience" (Given you follow the HIG and use native components)
If I write Apple only web that follows HIG like a bible and adheres to all standards, where does it put me?
> One extremely trivial example: I don't want to accidentally delete e.g. my files, just because some app thinks switching e.g. "Ok" and "Cancel" around is nice.
That’s platform guidelines. Nothing stops me from implementing them in web app or disregarding them in native apps.
> While yes, web apps have their uses, but they can't match good native apps even remotely.
Sure they can, and they do. You probably used them at some point but couldn’t even notice they were web.
Sure you can. Those are interface guidelines. When you start talking about HIG that touch upon specific native elements, we’re back to why vendor lock-in is bad.
Ah yes. There are some unknown theoretical HIGs that you can follow which don't exist and don't reflect the actual platforms that people, you know, actually use.
This has nothing to do with blindly parroting "vendor lock in bad". Because Apple's HIGs for a long time were light years ahead of anything else, and yes, I would expect a well-designed app to follow them on the Mac (anything from accent colors, secondary focus and humane modal dialogs to affordances, accessibility considerations etc.)
Whereas "sure you can" web implementing some bogus HIGs can't even do a modal dialog right.
> Ah yes. There are some unknown theoretical HIGs that you can follow which don't exist and don't reflect the actual platforms that people, you know, actually use.
Sorry?
> Because Apple's HIGs for a long time were light years ahead of anything else, and yes, I would expect a well-designed app to follow them on the Mac (anything from accent colors, secondary focus and humane modal dialogs to affordances, accessibility considerations etc.)
What does this have to do with native vs web argument? The topic is here what and what you can't achieve with both technologies.
> Whereas "sure you can" web implementing some bogus HIGs can't even do a modal dialog right.
I gave you examples, and you dismissed them because "vendor lock in is bad" and "I don't see what this has to do with native vs web".
> ???
There's no modal dialog on the web that conforms to any of the existing HIGs. And while you can implement one, the amount of effort is ridiculous. Compared to native.
And that goes for almost literally everything. For example, there's a reason 99.9999% of the thousands of dropdown re-implementations fail even the simplest of accessibility checks.
This is a fringe view, in my estimation. Websites do not follow one HIG, people are used to variance. Also, when it comes to Apple, they tend to double down on outright stupid decisions, whereas Android is just a so much of a mess that native does not really mean anything. If you want to make something cool, the basket of native widgets will not get you far either. In general, do not stray away too far from the users expectations (which may well imply not following whatever the HIG says) and they will accept you. The platonic idealists will never be happy under any circumstance, so do not optimize for them.
>Yes, there is Vendor-lock in, you can't deny that. I don't know what you mean with "user-hostile" and "developer hostile".
IMO it's only "developer hostile" for developers who don't want to have to learn a new OS and languages. This sounds like someone with years of Angular experience who doesn't want to learn React because it'll make all the tricks they've learned getting Angular to behave obsolete. As far as being "user hostile" I've got no idea why that's in there... unless they're just throwing things against the wall to see if they stick, and if that's their intent they picked the wrong forum to do it in.
What is it achieved through? Vendor locked, user and developer hostile native app stacks?
> The future we should strive for is the best UX for the customer.
And that’s web stack with access to system APIs.