This is going to be a hot take, but I believe all web views are bad implementations for mobile apps. Primarily because a native app has all the styling, fonts, and client-side logic bundled with the app when it's installed.
A WebView loads those at runtime. So if you were intercept and track all the requests made by a WebView app, you'd see potentially hundreds of assets loading when you make a search query.
A native app doesn't need all those assets, it can make a simple API request to resolve this.
I can imagine a WebView could be bundled with the assets it needs, tho I doubt most people do this.
A month ago, as I was inside Home Depot searching for plexiglass for our studio booth, I pulled up the Home Depot app to search for cheaper alternatives in-store than the ones I saw on the aisle.
However, the app was MISERABLY slow and janky. I blame this squarely on the fact that most of the app is just a webview. The search bar seems to be native, but everything after is just a website wrapper. And, surprise surpise, the website is slow as well. After about 7 minutes of intense frustration, I cursed the thing and just bought whatever was on the shelf.
But then it struck me.
"I'm a mobile app developer, what's stopping me from just making an optimized version that actually works!"
By "works", I mean:
- it's fast (even on Home Depot's WIFI)
- it's convenient (I can see aisle/bay right in the search results)
- it's clean (not janky/jumpy with loading spinners everywhere)
- it's powerful (create a list of items, and send that list as a link to someone else, no account required)
How it works, I basically have a proxy server between my app and home depot, that makes all the necessary calls BUT, it then filters out all the HTML and returns just the data needed with GRPC (though JSON could've worked as well).
That's how I made "THD Lite." There's still lots of work to be done, hence I'm not releasing it just yet. But so far, it hits the first three goals perfectly.
But, given that I'm not paid by Home Depot, I'm only adding the bits that I utilize. (unless of course ... Home Depot would like to change that, reach me at bookofcooks123@gmail.com).
Correction: badly implemented web view vs Flutter
This is going to be a hot take, but I believe all web views are bad implementations for mobile apps. Primarily because a native app has all the styling, fonts, and client-side logic bundled with the app when it's installed.
A WebView loads those at runtime. So if you were intercept and track all the requests made by a WebView app, you'd see potentially hundreds of assets loading when you make a search query.
A native app doesn't need all those assets, it can make a simple API request to resolve this.
I can imagine a WebView could be bundled with the assets it needs, tho I doubt most people do this.
> a WebView could be bundled with the assets it needs
Yeah this is it. A well integrated web view works very seamlessly. You only notice the ones done badly.
That's fair, tho tbh I don't know of a single WebView app that does this.
P.S: ok I guess it's because I don't notice them, lol
A month ago, as I was inside Home Depot searching for plexiglass for our studio booth, I pulled up the Home Depot app to search for cheaper alternatives in-store than the ones I saw on the aisle.
However, the app was MISERABLY slow and janky. I blame this squarely on the fact that most of the app is just a webview. The search bar seems to be native, but everything after is just a website wrapper. And, surprise surpise, the website is slow as well. After about 7 minutes of intense frustration, I cursed the thing and just bought whatever was on the shelf.
But then it struck me.
"I'm a mobile app developer, what's stopping me from just making an optimized version that actually works!"
By "works", I mean:
- it's fast (even on Home Depot's WIFI)
- it's convenient (I can see aisle/bay right in the search results)
- it's clean (not janky/jumpy with loading spinners everywhere)
- it's powerful (create a list of items, and send that list as a link to someone else, no account required)
How it works, I basically have a proxy server between my app and home depot, that makes all the necessary calls BUT, it then filters out all the HTML and returns just the data needed with GRPC (though JSON could've worked as well).
That's how I made "THD Lite." There's still lots of work to be done, hence I'm not releasing it just yet. But so far, it hits the first three goals perfectly.
But, given that I'm not paid by Home Depot, I'm only adding the bits that I utilize. (unless of course ... Home Depot would like to change that, reach me at bookofcooks123@gmail.com).
Namely, what's being left out:
- All "Pro" features (subject to change)
- Online orders (I'm not trying to get sued)
- Anything that requires an account