[wiseowise]

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

[dmitriid]

> You can write native apps that don’t follow HIG and you can write web apps that follow it.

You can't write a web app that properly follows a single OS's HIGs, much less multiple OSs'.

[wiseowise]

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.

[dmitriid]

> Sure you can

No you can't.

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

[wiseowise]

> No you can't.

Why and what you can't achieve from HIG?

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

???

[dmitriid]

> Why and what you can't achieve from HIG?

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.