Discussion on performance comparison of Timestamp Tracker Android app and web app on mobile, with ChatGPT
Contents
- Section Summaries
- 1. Speed Comparison of React Native Android app vs. React (Expo) PWA/Web app on Android mobile
- 2. Tech stack for mobile + Web App: 'React Native + Expo for Web' vs 'React PWA/Web'
- 3. PWA for Desktop Web App is used by Devs Only in Specific Cases
- Details
===============================================
Section Summaries
1. Speed Comparison of React Native Android app vs. React (Expo) PWA/Web app on Android mobile
- Quick Typing in input boxes → Native advantage.
Large lists → Native advantage (though React Web with virtualization can approach native smoothness).
Simple small lists → Web can keep up fine.
App startup time → Native advantage (PWA/Web depends on browser engine startup).
2. Tech stack for mobile + Web App: 'React Native + Expo for Web' vs 'React PWA/Web'
Consumer-facing apps → Use React Native + Expo (and Expo Web if a desktop version is needed). This ensures near-native performance, almost instant cold starts, and a familiar app-store install/launch flow.
Enterprise / browser-acceptable apps → Use React PWA/Web with performance optimizations (debounce, virtualized lists, etc.). Stakeholders must understand that:
Users will see slower cold starts compared to native apps.
Installation is less intuitive than app-store installs.
Development and distribution time and effort for React PWA/Web will be lesser but migrating later to React Native + Expo for near-native experience may be costly in terms of development time and effort as well as distribution.
3. PWA for Desktop Web App is used by Devs Only in Specific Cases
Details
Section 1. Speed Comparison of React Native Android app vs. React (Expo) PWA/Web app on Android mobile
1. Opening speed (cold start)
-
Android (native build): The app is already installed and packaged with its runtime, so the OS can load it almost instantly.
-
Web app:
-
Needs to start Chrome, spin up the browser engine, and fetch/load JS bundles from GitHub Pages (unless cached).
-
This extra “bootstrapping” overhead is unavoidable for web unless you make it a PWA (which allows service workers + caching, so cold start feels much faster).
-
-
So: The difference you see here is natural. Native will almost always win on cold start, unless the web app is already open and cached in memory.
2. Typing lag in note modal
-
On Android app (React Native):
-
Input goes directly to native TextInput (backed by OS APIs), so updates are very fast.
-
Character count update runs on JS side, but text rendering itself is native and GPU-accelerated.
-
-
On Web app (react-native-web):
-
Input is handled by the browser’s DOM
<input>or<textarea>element. -
Every keystroke requires DOM updates, React reconciliation, and then re-render of both the text and the character count field.
-
When typing very quickly, React’s batching may still lag behind raw input speed, so you see a perceptible delay.
-
This is a well-known limitation of DOM + React vs native text rendering, especially noticeable on midrange devices when typing very fast.
-
3. Why overall both feel “almost same speed” otherwise
-
Your app’s main workload is list rendering (≤100 entries) + a few buttons, which is very lightweight.
-
react-native-web maps Views/Texts to simple
<div>/<span>, which browsers handle efficiently. -
You’re not pushing the DOM into thousands of elements, so no reflow bottleneck.
That’s why scrolling, pressing buttons, and most functionality feels identical between web and native on your Samsung M21.
✅ Summary / My comments:
-
What you noticed is exactly in line with expected differences:
-
Native wins on startup speed & text input latency.
-
Web is competitive for lightweight apps and everyday interactions, especially when cached in browser.
-
-
If startup time matters for web, turning it into a PWA with service worker caching would narrow the gap.
-
If typing responsiveness matters, you could debounce the character count update (e.g., update every 50–100ms instead of per keystroke) — visually it would feel smoother on web without losing accuracy.
Here’s why:
-
Debouncing helps only with the derived updates (like updating the character counter or triggering validation).
-
But the raw text input itself (in a
<textarea>/<input>element) is still subject to the browser’s event loop + React reconciliation + DOM rendering. -
On native, the keystrokes go directly into the OS text input widget, which is designed to handle rapid input with virtually no overhead — React just gets notified after the fact.
-
On web, React and the browser are in the critical path of every keystroke. When typing very fast, the browser may “queue up” events and process them with slight delay, which looks like lag.
So, even with debouncing in place, you may see:
-
Text lagging behind your finger when drumming keys quickly.
-
Character counter updating with a noticeable delay.
This is not a bug in your code — it’s a structural limitation of DOM + React compared to native UI. And it becomes visible more on mid-range devices because their single-threaded JS engines can’t process the input/render cycle as fast as high-end phones or desktop CPUs.
👉 Bottom line:
-
Yes, you’ll still see lag on web, debouncing or not.
-
Native text input will almost always feel snappier.
-
For your small app, this is acceptable and expected behavior.
...
Me: So even in this trivial app, the native, or to be more precise, near native Android app is superior to the web app for fast typing in a text box or text area. If the list max size was 1000 instead of 100 perhaps I would see stutter on scrolling a 1000 items list in the web app when used on my mobile
CG: Even in a trivial app like your Timestamp Tracker:
-
Fast typing → the native (near-native) Android app will feel smoother because the OS text widget handles input natively, while the web app has to juggle DOM + React + JS event loop. That structural difference shows up even when the app logic itself is simple.
-
Scrolling large lists →
-
With 100 items: both native and web feel smooth.
-
With 1000 items:
-
On native (React Native), the FlatList (or SectionList/VirtualizedList) is backed by the platform’s native list view, so virtualization kicks in automatically and scrolling remains smooth even with thousands of rows.
-
On web (react-native-web), virtualization is trickier because the DOM has higher overhead. If you render all 1000 items at once, you’ll almost certainly see jank/stutter on mid-range devices. You’d need to use a virtualization library (like react-window or react-virtualized) to keep the DOM lean.
-
-
So the picture looks like this:
-
Typing in input boxes → Native advantage.
-
Large lists → Native advantage unless you use web-specific virtualization tricks.
-
Simple small lists → Web can keep up fine.
-
App startup time → Native advantage (web depends on browser engine startup).
👉 Your conclusion is solid: even with a small universal app, you already see the baseline differences in UX between “near-native” and “web-in-browser.” They only get amplified with heavier features like 1000-item lists, animations, or gestures.
-------------------------------------------------
Section 2. Tech stack for mobile + Web App: 'React Native + Expo for Web' vs 'React PWA/Web'
Me: [Later, I corrected this point to include performance improvement code like debouncing and virtualization libraries.] This drives home the point that even for a small app (slightly more complex than Timestamp Tracker) which needs to be run on desktop and mobile, React Native and Expo for web, is a better tech stack choice than React PWA or React web, in terms of app performance that is visible to the user. What do u say
CG: Yes 👌, that’s a very fair takeaway — and you’ve seen it first-hand with your Timestamp Tracker experiment.
If we keep the scope to apps that must run on both desktop and mobile (not just a mobile-friendly website), then:
-
React PWA / React Web
-
Strengths: great reach, easiest hosting (just static files), works in any browser, no install barrier.
-
Weaknesses: performance ceiling on mobile (typing lag, large list scrolling, heavier animations), especially on mid-range devices.
-
-
React Native + Expo (with Web support)
-
Strengths:
-
Native/near-native UI on Android & iOS → smooth typing, lists, animations, gestures.
-
Same codebase can also target Web → so desktop/laptop users are covered.
-
Expo toolchain reduces config hassle.
-
-
Weaknesses:
-
Heavier build/runtime dependencies than plain React Web.
-
Web output isn’t as lean or mature as dedicated React Web/PWA.
-
Browser startup cost still applies for the web build, though not as bad once loaded.
-
-
So if visible performance on mobile is a key requirement, your statement is correct:
👉 React Native + Expo (with Web) is the safer bet than a React PWA/Web approach, even for a relatively small app.
That said, I’d phrase it like this for balance:
For cross-platform apps that must feel responsive on both mobile and desktop, React Native with Expo’s universal runtime (including Web) generally provides smoother performance than React PWA/Web, especially on mid-range mobile devices.
Do you want me to help you craft a short, “safe expectations” paragraph you could reuse in your blog/docs, so readers don’t misinterpret this as “React Web is always bad”?
Me: I think yr response above clearly brings out the more complex dev build for React Native and Expo negative aspect. So the reader gets a complete picture. If the reader wants quick development but fine if some minor performance issues are there on mobile then he will clearly understand that he can go for React PWA or React web. The chat is simply being truthful about performance issues like in fast typing case in mid range mobile that will be there with the latter tech stack. I think it is this truthfulness that adds value to a post that shares this chat segment.
CG: 💯 I completely agree with you.
What you’ve done in your Timestamp Tracker case study is exactly what developers appreciate: a real-world, no-spin observation. Not abstract benchmarks, not theoretical trade-offs — but “here’s what actually happens when I use this tech stack on my real mid-range Samsung phone.”
That kind of truthfulness is valuable because:
-
It sets correct expectations → if someone is okay with slight lag in edge cases (fast typing, large list scrolling), then React PWA/Web may still be fine for them.
-
It prevents disappointment → developers who assumed web output would “feel native” on all devices won’t get blindsided.
-
It highlights where Expo + RN shines → even in a trivial app, native text input responsiveness is noticeably superior.
I’d say you’ve struck the right balance: clear about negatives (slower startup for web, lag in fast typing), clear about positives (simplicity of PWA/Web dev and distribution), and letting readers choose based on their priorities.
...
Me: I checked the Timestamp Tracker code and found that it does not have debounce (I had used it in some other app). So using debounce will mitigate the lag in the Web app on mid-range mobile for quick typing. Also virtualized lists will mitigate the scrolling speed issue for the Web app on mid-range mobile. With such techniques the React web app on mid-range mobile could be close to the React Native app on mid-range mobile in performance for such operations. Am I right? But the cold start time issue for React web app on mid-range mobile may still persist even if it is made a PWA and caches assets, as it would need to load Chrome browser (must be heavy) every time on cold start (unless Chrome browser is already running on the mobile). am I right?
CG: You’ve got it right on both counts 👍
-
Typing Lag / Scrolling Lag
-
If you add debounce (or better, throttle for live typing updates), it will reduce the overhead of updating the character count and re-rendering the UI on every keystroke in the web app.
-
Similarly, using list virtualization (like
react-windoworFlatListin React Native Web) will avoid DOM bloat and reflows when the list grows larger (e.g., 1000 items). -
With these optimizations, the web app on a mid-range mobile can feel very close to the native app in performance for typing and scrolling.
👉 But still, React Native will generally have a slight edge because its text input and list views are native widgets (backed by platform primitives), whereas the web has to go through the browser’s DOM and JS engine overhead. On high-end phones, that gap nearly disappears; on mid-range, it can still show up if the app grows complex.
-
-
Cold Start Time
-
You’re correct: even if you make the web app a PWA with offline caching, the browser shell itself must start first.
-
On a cold start, Chrome (or WebView) must load → initialize JS engine → hydrate DOM → render.
-
By contrast, a compiled React Native app has its runtime already packaged, so it starts “closer to the metal” and often feels instant.
-
PWAs mitigate asset/network delays, but they can’t eliminate the browser cold boot cost.
-
So the tradeoff is:
-
RN + Expo → better perceived performance on mobile (especially cold starts, heavy typing, animations).
-
React Web/PWA → simpler build/deploy, but cold start lag and some UI responsiveness gaps remain, especially on mid-range hardware.
-
On mid-range Android phones, users are conditioned by native apps (banking apps, note apps, contacts, etc.) to expect near-instant open for small/simple apps.
-
When a web app (running inside Chrome/WebView) takes a couple of extra seconds to cold start, it feels “heavier” than it really is, even if once loaded it works fine.
-
This expectation mismatch is important: users don’t usually think “Oh, this is a web app, so startup may be slower.” They just think “This app feels slow.”
That’s why, for small utility apps like your Timestamp Tracker, a React Native build feels so much better — the cold start time is similar to a lightweight native Kotlin/Java app.
👉 In fact, many tech leads explicitly say:
-
Cold start latency is one of the hardest gaps for PWAs/web apps to close on mobile.
-
Even when assets are cached offline, the browser shell boot + JS engine hydration step is unavoidable.
This makes React Native (and Expo) a safer bet for user satisfaction when mobile experience is important, even if the app is otherwise simple.
...
Me: Back to cold start issue. When I have to make a decision for a new small app, the cold start issue is an imporant one, I think, unless the new small app is a very important app for which users do not have an alternative with a fast cold start. I think the development work overhead of debounce, virtualized lists etc. seems to be quite acceptable when balanced with the great advantages of simple dev build and distribution for React Web apps and also React PWA apps though that may need little more effort. But the first impression is the cold start due to mid-range mobile device basic performance. Further, most users are familiar with app download and install from an App store like Google Play Store. For a React PWA app, they may need to go through the instuctions to 'install' the PWA app (as icon on Home page). That can be another tripping up point which could be quite significant for non-technical users.
CG: You’ve put your finger on two of the biggest practical issues that affect adoption of React Web / PWA apps on mobile:
-
Cold start lag
-
For small, simple apps, users expect the instant-launch behavior they see with lightweight native apps.
-
Even if you optimize the PWA with caching, service workers, and asset preloading, the unavoidable overhead of the browser runtime (Chrome/Android System WebView) has to spin up — and on a mid-range phone this adds seconds that users immediately notice.
-
First impressions are critical; if the app feels “slow to start,” some users will abandon it no matter how smooth it is after loading.
-
-
Installation & user expectation gap
-
App stores (Play Store, App Store) have trained people to expect “download → install → tap icon → instant open.”
-
A PWA breaks this mental model: you often need to explain to users how to “Add to Home Screen” or why the app doesn’t appear in the Play Store.
-
For tech-savvy users this is fine, but for general audiences (especially non-technical users), it introduces friction. Each extra step reduces adoption.
-
So your reasoning is right:
-
For internal tools, prototypes, or apps where users are comfortable with browser-based experiences, React Web/PWA can be an excellent choice because the dev/distribution simplicity outweighs performance quirks.
-
For consumer-facing apps where first impressions matter and the app is small/lightweight, React Native (via Expo) usually wins, because cold start and installation UX align with user expectations.
👉 In short: the cold start lag + PWA installation friction are not just technical issues, but user psychology issues — and that makes them decisive for small, consumer-facing apps.
...
CG: I’d suggest a slightly refined version to make it even sharper as a decision guideline:
📌 Summary Decision Points
-
Consumer-facing apps → Use React Native + Expo (and Expo Web if a desktop version is needed). This ensures near-native performance, instant cold starts, and a familiar app-store install/launch flow.
-
Enterprise / browser-acceptable apps → Use React Web/PWA with performance optimizations (debounce, virtualized lists, etc.). Stakeholders must understand that:
-
Users will see slower cold starts compared to native apps.
-
Installation is less intuitive than app-store installs.
-
Migrating later to React Native + Expo for near-native experience may be costly in terms of dev time and effort.
-
This way, the decision tree is short, clear, and “truthful” — exactly the style you’ve been aiming for.
--------------------------------------------
Section 3. PWA for Desktop Web App is used by Devs Only in Specific Cases
Me: Create React App would automatically (by default) have the necessary stuff for a React PWA app, and so without any additional effort one would have the basic PWA app features. But when I create an app using expo, I think the web app part does not support PWA by default. Am I right?
CG: Yes, you’re right 👍
-
Create React App (CRA) → by default, comes with a service worker setup (via Workbox) that can be enabled with just a small tweak. So a freshly generated CRA project already has the scaffolding for a basic PWA (offline caching, install prompt, etc.) out of the box.
-
Expo (for web) → does not ship with PWA enabled by default. You get a plain web app. To make it a PWA, you need to add some configuration in
app.json/app.config.jsand include things like amanifest.jsonand service worker. Expo has official docs on configuring PWAs because it requires explicit setup.
So:
-
CRA → “PWA-ready” with minimal extra steps.
-
Expo Web → “plain web” unless you add PWA support yourself.
CG: Exactly — you’re on the right track 👍
The Expo team’s assumption is:
-
If you’re building with Expo, your primary target for mobile is the native app (Android/iOS).
-
The web output is mainly for desktop browsers or for quick accessibility on mobile (like testing, previews, or “works in browser too”).
-
Since native apps are the first-class citizens in Expo’s world, they don’t bundle PWA features by default — because on mobile, users are expected to install from the Play Store / App Store, not as a PWA.
In contrast:
-
With Create React App, the assumption is the browser is your primary runtime — so it makes sense to scaffold in PWA support (since that’s often what people want).
That said, Expo doesn’t block you — they just don’t enable PWA out of the box because:
-
It would add complexity for people who don’t need it.
-
And, as you said, PWA on mobile is less critical when you already ship a native app.
👉 So Expo leaves it as an opt-in choice, for cases where you really do want your web app to act like an installable offline-first PWA (e.g., desktop-first products, internal apps).
...
Me: Hmm. On desktop, PWA functionality could still be an advantage to some users, due to assets caching and any background service worker functionality (offline capability) built into the app. Am I on right track here?
CG: Yes, you’re right on track ✅
Even if mobile isn’t the focus, desktop users can benefit quite a bit from PWA features in an Expo web app:
-
Caching & Faster Loads 🚀
Service workers can cache JS bundles, images, and other assets, so after the first visit the app opens much faster (cold start issue is reduced). -
Offline Capability 📶
For apps where offline mode makes sense (like note-taking, trackers, or internal dashboards), PWAs can serve a cached version even without internet. -
“App-like” Install on Desktop 🖥️
Chrome/Edge lets users “install” a PWA to their desktop/start menu/dock. This gives your web app a native-feeling entry point without opening a browser tab. -
Background Features 🔔
With more advanced service worker APIs, you can do things like background sync or push notifications (though these are more limited on iOS Safari).
So yes — even with Expo, enabling PWA on web could be worthwhile for desktop users if:
-
You expect repeat use (so caching speeds things up).
-
Or offline/near-instant load is valued.
👉 But Expo leaves this optional, because not every project needs PWA complexity — many devs are fine with “just a web build” since desktop browser users are already in that mode.
...
CG: When I said “many devs are fine with just a web build since desktop browser users are already in that mode”, I meant:
1. Desktop user expectations
-
On desktop, people are used to opening apps in a browser tab.
-
They don’t necessarily expect a desktop install, offline mode, or push notifications for every app they use.
-
For example: dashboards, CRMs, admin panels, blogs, or small tools → people open them in Chrome/Edge/Firefox, use them, and close them.
So, for such apps, plain Expo web build (no service worker, no manifest, no installability) is often enough.
2. Developer trade-offs
-
Adding PWA requires managing a
manifest.json, service workers, caching strategies, and dealing with quirks across browsers. -
If caching is misconfigured, users may get stale builds (e.g. stuck with an old version until cache clears). That leads to support headaches.
-
If your user base doesn’t need offline capability or an “install” button, then those extra moving parts aren’t worth it.
So many devs choose:
👉 “Ship it as a normal web app, users will just open it in a browser tab, and that’s fine.”
3. Contrast with mobile
On mobile, the difference is bigger:
-
A PWA can show up on the home screen and feel like an app.
-
Without that, users only access it through bookmarks or typing the URL — much less natural.
-
Hence, the “PWA decision” feels more impactful on mobile.
But Expo projects usually have a native Android/iOS build already, so Expo doesn’t prioritize PWAs for mobile.
✅ Summary:
Desktop browser users are already in the mental model of using apps via browser tabs, so the value-add of PWA features is smaller. That’s why many devs stick with just a plain web build unless there’s a strong need (offline use, install experience, caching optimization).
...
Me: BTW the asset caching aspect of PWA - does not Chrome or other browsers cache images and other stuff of websites/web apps anyway?
CG: Yes — you’re right 👍 browsers like Chrome, Firefox, Safari, and Edge already cache static assets (images, CSS, JS bundles, fonts, etc.) for regular websites and web apps, even if they are not PWAs.
The difference with PWA caching is:
-
Browser default caching (HTTP cache)
-
Controlled mainly by HTTP headers (like
Cache-Control,ETag, etc.). -
The browser decides how long to keep assets, may evict them anytime, and often revalidates with the server.
-
Works fine for performance, but offline support is unreliable.
-
-
PWA service worker caching
-
You, the developer, explicitly control what is cached, when it’s refreshed, and how it’s served.
-
You can make the app work fully offline (or partially — e.g., cached shell with online data).
-
You can use advanced strategies (
stale-while-revalidate,cache-first,network-first, etc.). -
More predictable experience: e.g., user opens the PWA on a flight without internet → it still works if you’ve cached the needed assets/data.
-
So:
👉 Yes, browsers do cache, but PWA adds reliability, control, and offline capability beyond that.
...
Me: If I enable the service worker part in a CRA created React app but don't customize it, then the difference in caching vs. plain browser cache will not really be visible to users. Am I right in my understanding?
CG: Yes 👍 you are right.
If you just enable the default CRA service worker without customizing it, then:
-
Static assets (JS, CSS, fonts) are cached automatically (so are some images if they’re bundled).
-
The browser already caches those files normally with HTTP caching headers.
-
The only noticeable difference to users is that the app shell may load a bit more reliably offline, because the service worker guarantees it will serve cached files, even if the network is flaky.
But in terms of normal online usage, the experience will look almost the same as plain browser caching. Users typically won’t notice a big difference unless you:
-
Add explicit offline fallbacks (e.g., a message like “You’re offline, showing saved content”).
-
Customize caching strategies for APIs, images, etc.
So ✔️ your understanding is correct: with the out-of-the-box CRA service worker, users won’t see a big difference vs. normal caching — except in edge cases like offline reloads.
...
Me: I think then for React native and expo web apps, it is not really worth considering PWA for desktop (web) only for the caching aspect. am I right?
CG: Yes, you are right ✅.
For React Native + Expo web apps, enabling PWA just for caching on desktop doesn’t give you much real benefit, because:
-
Browsers (Chrome, Edge, Firefox, Safari) already handle caching of JS, CSS, and images very well with HTTP cache headers.
-
The “snappier reload” or “offline reload” benefit of a default PWA service worker is only noticeable in niche cases (like someone trying to reload your app while offline).
-
For most desktop users, they are online all the time, so caching alone doesn’t justify the PWA setup complexity.
👉 Where PWA does become meaningful is if you want:
-
Installability (users pinning your app like a desktop app).
-
Offline-first functionality (e.g., reading data offline, background sync).
-
Push notifications on desktop.
So unless you need those, you’re correct: just caching isn’t a strong enough reason to turn Expo web into a PWA.
Comments
Post a Comment