I built the same app 10 times: Evaluating frameworks for mobile performance

Posted by 0xblinq 2 days ago

I built the same app 10 times: Evaluating frameworks for mobile performance(www.lorenstew.art)

232 points | 151 commentspage 5

Mashimo 2 days ago|

This made me look at our current app, it's a whooping 10MB just to get on the landing page. Build with Angular.

.. creating a maintenance issue right now.

android521 2 days ago||

it doesn't matter. in 10 years, few people will access websites directly.

ShaneWrn 2 days ago||

[dead]

Raydii 2 days ago||

[dead]

RayFrankenstein 2 days ago||

The guy is such a web zealot that he refuses to make the sensible engineering tradeoff that favors speed and offline capabilities over platform ubiquity. Most sane people would write a native app for this sort of thing if money was on the line.

t00 2 days ago|

Am I missing something here? The mobile SPA app can be deployed using tools like capacitor to a device and the framework along with all static content is loaded into the app bundle. In such case it makes no (realistic) difference which framework is selected and it matters more how the background/slow transfers are handled with data-only API requests, possibly with hosted images. With the background workers PWA can be built as well, streamlining installation even more.

iainmerrick 2 days ago|

Does that involve shipping a native wrapper for your web app?

If so, you have the extra cost, effort and bureaucracy of building and deploying to all the different app stores. Apple's App Store and Google Play each have various annoyances and limitations, and depending on your market there are plenty of other stores you might need to be in.

Sometimes you do need a native or native-feeling app, in which case a native wrapper for JS probably is a good idea, other times you want something lightweight that works everywhere with no deployment headaches.

t00 2 days ago||

As much as I agree with app deployment headaches, apps provide something a website cannot (except PWA) - ability to do stuff offline, log and register data which can be uploaded when connection is re-established. When talking about user experience - launching the app, selecting new -> quote -> entering details -> save -> locking the phone without worrying or waiting, knowing that it will eventually get uploaded, is much more convenient than walking with the phone around the property to get better reception to even load the new quote page.

UX matters, and user does not care if the native wrapper or 500kB of js is there or not, as long as the job is done conveniently and fast.