| > This will never be as nice to use as a native app, because you cannot replicate all of the small details of how native UI works on each platform. Not sure how much of that is necessary. I mean, a button doesn't "look native", so what? It's a button. Apps written to require network requests to resolve a navigation are much worse than JavaScript handling a user event. > And say you manage to get close to emulating a native app on one platform — when the OS UI updates, you’ll be behind again. Not really the goal. You have this backwards. Keeping up with OS churn is one of the reasons to use an abstraction like this. It doesn't break your app nearly as much. The browser is a much more stable target than native mobile APIs. > I get that it’s inconvenient/expensive for you to build three UI layer. But that’s the only way to do this well. Inconvenient is dramatically understating the case. 3x spend is flat out impossible for many places. |
Is it? Native buttons also come with things like affordances, accessibility, recognizability.
"So what" is what lead Google to spend money on user research involving hundreds of people to figure out that text boxes looking like text boxes is good, actually.