> All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms.
Of course it will.
If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost.
Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top.
Boom. You're operating close to the speed of light.
> Ummm... I sell web apps. Many major vendors have products that are, at heart, web apps. Progressive web apps, web apps, electron, phone gap, Cordova, capacitor, etc. I find this observation a demonstration of your ignorance of this market.
As a user I've seen and used this crap. My understanding of the market is much better than yours, it seems, because I approach it as a user. And yeah, you definitely don't listen to the users.
I've yet to see a single [1] web app that didn't have the shortcomings I partly listed. I've seen this crap in banking apps, ride sharing apps, hotel apps, calendar apps, travel apps, ride and car sharing apps... The list is endless. Every time there's web, there's deficiencies: long loading times, bad scrolling, elements out of bounds, bad touch and tap targets, abysmal animations, layout shifts, you name it.
[1] This is a slight exaggeration. I vaguely remember a couple when I went "hmmm... it's a webview, but nicely implemented"
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.
> The native bias here is crazy. Most users just don't care and can't tell if they are on something that's native vs a web view.
They can. You just don't know how to listen. "It's slow to open", "it's janky", "it stutters when it scrolls", "I tap/click and nothing happens" etc.
Does this happen with native apps? You betcha. It is significantly more prevalent with web because web has never been and never will be an app platform. It's core is to display text and images, and it can barely manage that.
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.
I don't lose a tab among hundreds others if I need to reference something. It has all the necessary navigation on-screen (language switch, search inline, table of contents)
Don't get me wrong, wikipedia website is also brilliant: fast and reaponsive. The app is simply adjusted to the platform it's on, including all the mobile interactions you've come to expect. For example, there's no hover on mobile. In the app I can tap-hold a link and see the preview that you see on hover on Wikipedia's site.
> Not sure how much of that is necessary. I mean, a button doesn't "look native", so what? It's a button.
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.
> They are both well known gaps that make integrations a pain in the ass.
Funny how you keep not saying what you mean across two threads. While accusing others of being ignorant, partisan, or never using something, it looks like you're just describing yourself.
Literally everything that runs in the browser is "aligned with the platform" since there's nothing but the platform that is running in the browser.
Meanwhile, "the aligned with platform" lit.dev is busy reinventing React, but poorly:
- uses non-standard syntax like `<div ?hidden=xxx .value=yyy .@click=zzz`
- special functions of the form "this particular function call even though it looks like a regular function call will actually throw an exception if used outside a very specific place inside a string". See "built-in directives"
- as a part of the mess that is Web Components in general is now busy reinventing React Context
and so on and so forth.
But yeah, sure, "more aligned something something"
Of course it will.
If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost.
Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top.
Boom. You're operating close to the speed of light.