The world has moved on from a beige box on a desk with a fat physical link made of copper and fibre.
Allowing users to work when their mobile signal is spotty is pretty good UX for those that don't deal in a office cubical or wfh.
Yes you could argue that native mobile apps have that covered...
But should it be that you have two proprietary "standards", and only those two? For "trivial" apps that are just data entry/query?
Why do I need 124mb for the app code alone of Twitter, when the web version is closer to ~7mb (ang don't start the argument about 7mb being obscene for a website, please. we're discussing a web APP, not grandma's cooking blog).
Plenty of sites are still on the "Linux, MySQL, SpringBoot, and HTML/CSS/JS" stack or equiv.
We just have tools now that let us add "works while you're on a train where the internewt is unreliable" to the featureset.
Wait, are you saying that the stack I mentioned doesn't work well on mobile? Because I've coded and tested everything myself-- my sites are infinitely better on mobile compared to anything written in react
Allowing users to work when their mobile signal is spotty is pretty good UX for those that don't deal in a office cubical or wfh.
Yes you could argue that native mobile apps have that covered...
But should it be that you have two proprietary "standards", and only those two? For "trivial" apps that are just data entry/query?
Why do I need 124mb for the app code alone of Twitter, when the web version is closer to ~7mb (ang don't start the argument about 7mb being obscene for a website, please. we're discussing a web APP, not grandma's cooking blog).
Plenty of sites are still on the "Linux, MySQL, SpringBoot, and HTML/CSS/JS" stack or equiv. We just have tools now that let us add "works while you're on a train where the internewt is unreliable" to the featureset.