I agree with most of the other comments here, and it sounds like Shopify made sound tradeoffs for their business. I'm sure the people who use Shopify's apps are able to accomplish the tasks they need to.
But as a user of computers and occasional native mobile app developer, hearing "<500ms screen load times" stated as a win is very disappointing. Having your app burn battery for half a second doing absolutely nothing is bad UX. That kind of latency does have a meaningful effect on productivity for a heavy user.
Besides that, having done a serious evaluation of whether to migrate a pair of native apps supported by multi-person engineering teams to RN, I think this is a very level-headed take on how to make such a migration work in practice. If you're going to take this path, this is the way to do it. I just hope that people choose targets closer to 100ms.
When the user clicks a button, we start a server round-trip and fetch the data and do client-side parsing, layout, formatting and rendering and then less than 500ms later, the user can see the result on his/her screen.
With a worst-case ping of 200ms for a round-trip, that leaves about 200ms for DB queries and then 100ms for the GUI rendering, which is roughly what you'd expect.
Since the post is about the benefits of react, I'm sure if requests were involved they would mention it.
Also, even if it was involved, 200ms for round-trip and DB queries is complete bonkers. Most round-trips don't take more than 100ms, and if you're taking 200ms for a DB query on an app with millions of users, you're screwed. Most queries should take max 20-30ms, with some outliers in places where optimization is hard taking up to 80ms.
In the real world, you can't just optimise for the sake of it. You need to get a business case for it. Because it all boils down to revenue vs expenses
You could do the maths on conversion rate increase if that latency disappeared vs the cost of spinning up a dc & running it (including the mess that is localised dbs)
I’m not sure the economics works out for most businesses (I say this as an Australian)
Most queries are 20-30ms. But a worst case of 200ms for large payloads or edge cases or just general degradations isn't crazy. Without knowing if 500ms is a p50 or p99 it's kind of a meaningless metric but assuming it's a p99, I think it's not as bad as the original commenter stated.
Agreed. The P95 and P99 in particular are likely to be over 1 second, possibly over 2. They chose P75 to be able to post a seemingly impressive number.
I personally wouldn't be very happy with a P75 of 500 ms. It's slow.
I have a 160ms ping to news.ycombinator.com. Loading your comment took 1.427s of wall clock time. <s>Clearly, HN is so bad, it's complete bonkers ;)</s>
"if you're taking 200ms for a DB query on an app with millions of users, you're screwed"
My calculation was 200ms for the DB queries and the time it takes your server-side framework ORM system to parse the results and transform it into JSON. But even in general, I disagree. For high-throughput systems it typically makes sense to make the servers stateless (which adds additional DB queries) in exchange for the ability to just start 20 servers in parallel. And especially for PostgreSql index scans where all the IO is cached in RAM anyway, single-core CPU performance quickly becomes a bottleneck. But a 100+ core EPYC machine can still reach 1000+ TPS for index scans that take 100ms each. And, BTW, the basic Shopify plan only allows 1 visitor per 17 seconds to your shop. That means a single EPYC server could still host 17,000 customers on the basic plan even if each visit causes 100ms of DB queries.
Having indices doesn’t guarantee anything is cached, it just means that fetching tuples is often faster. And unless you have a covering index, you’re still going to have to hit the heap (which itself might also be partially or fully cached). Even then, you still might have to hit the heap to determine tuple visibility, if the pages are being frequently updated.
Also, Postgres has supported parallel scans for quite a long time, so single-core performance isn’t necessarily the dominating factor.
I do not understand this thinking at all, a parsed response into whatever rendering engine, even if extremely fast is going to be a large percentage of this 500ms page load. Diminishing it with magical thinking about pure database queries under load with no understanding of the complexity of Shopify is quite frankly ridiculous, next up you’ll be telling everyone to roll there own file sharing with rsync or something…
I know - old man yells at cloud and stuff - but some 8-bit home computers from the 80s completed their entire boot sequence in about half a second. What does a 'UI rendering engine' need to do that takes half a second on a device that's tens of thousands of times faster? Everything on modern computers should be 'instant' (some of that time may include internet latency of course, but I assume that the Shopify devs don't live on the moon).
Not sure why people keep bringing the old (my machine x years ago was faster). Machines nowadays do way more than machines from 80s. Whether the tasks they do are useful or not is separate discussion.
Casey Muratori has a clip [0] discussing the performance differences between Visual Studio in 2004 vs. today.
Anecdotally, I’ve been playing AoE2: DE a lot recently, and have noticed it briefly stuttering / freezing during battles. My PC isn’t state of the art by any means (Ryzen 7 3700X, 32GB PC4-24000, RX580 8GB), but this is an isometric RTS we’re talking about. In 2004, I was playing AoE2 (the original) on an AMD XP2000+ with maybe 1GB of RAM at most. I do not ever remember it stuttering, freezing, or in any way struggling. Prior to that, I was playing it on a Pentium III 550 MHz, and a Celeron 333 MHz. Same thing.
A great anti-example of this pattern is Factorio. It’s also an isometric top-down game, with RTS elements, but the devs are serious about performance. It’s tracking god knows how many tens or hundreds of thousands of objects (they’re simulating fluid flow in pipes FFS), with a goal of 60 FPS/UPS.
Yes, computers today are doing more than computers from the 80s or 90s, but the hardware is so many orders of magnitude faster that it shouldn’t matter. Software is by and large slower, and it’s a deliberate choice, because it doesn’t have to be that way.
If you buy poor software instead of good software (yes, branding, IP and whatever but that's just even more reason for companies not to make it good), complaining doesn't help does it. Commercial software is made to be sold and if it sells enough that's all company executives care about. As long as enough people buy it, it will continue to be made.
Company devs trying to get more time/resources to improve performance will be told no unless they can make a realistic business case that explains how the expense of increased focus on performance will be financially worth in terms of revenue. If enough people buy poor software, improving it is not business smart. Companies exist to make money not necessarily to make good products or provide a good service.
I understand your point but you need to understand that business execs don't care about that unless it significantly impacts revenue or costs in the present or very near future.
Nah, it’s not just that. IME, most devs are completely unaware of how this stuff works. They don’t need to, because there are so many abstractions, and because the industry expectation has shifted such that it isn’t a requirement. I’ve also met some who are aware, but don’t care at all, because no one above them cares.
Tech interviews are wildly stupid: they’ll hammer you on being able to optimally code some algorithm under pressure on a time limit, but there’s zero mention of physical attributes like cache line access, let alone a realistic problem involving data structures. Just once, I’d love to see “code a simple B+tree, and then discuss how its use in RDBMS impacts query times depending on the selected key.”
Sure, and the screen in text mode was 80 x 25 chars = 2000 bytes of memory. A new phone has perhaps three million pixels, each taking 4 bytes. There's a significant difference.
And yet the GPU in your phone can run a small program for each pixel taking hundreds or even thousands of clock cycles to complete and still hit a 60Hz frame rate or more. It's not the hardware that's the problem, but the modern software Jenga tower that drives it.
If you are good those numbers are an order of magnitude off. In truth it is probably mostly auth or something. If you simply avoid json you can radically attack these things fast.
RTT to nearest major metro DC should be up to 20ms (where I am it is less than half that), your DB calls should not be anything like 200ms (and in the event they are you need to show something else first), and 10-20ms is what you should assume for rendering budget of something very big. 60hz means 16ms per frame after all.
What percentile? Topics like these don't talk about the 5G connected iphone 16 pro max, but have to include low-end phones with old OS versions and bad connectivity (e.g. try the same network connectivity in the London metro, where often there is no receiption whatsoever).
As you reach for higher percentiles, RTT and such start growing very fast.
Edit: other commenter mentioned 75% as percentile.
Independent of connectivity, UI rendering should be well under the device refresh rate. Consider the overhead of a modern video game that runs 60fps without a hiccup. It’s ludicrous that a CRUD app which usually only populates some text fields and maybe a small image or two can’t do the same
OP gave a render budget of 100ms _after_ the data has loaded. That’s unacceptable. If this were a MacOS app, that would mean dragging a window corner to resize the content , forcing a new layout and redraw, would yield 10 fps of change. And yet nearly all native apps redraw and layout instantly, even with complex tables of text at various fonts and sizes.
This is also a great litmus test to check if an app was made with electron because they always redraw slowly.
There's no argument that starts this way which doesn't end either with "support working offline", or defining when you consider that a user has stepped out of bounds with respect to acceptable parameters, which then raises the question what do you do in that event?
If all you're trying to do is say 75% of users have a good experience, and in your territory 75% means a 150ms and that's too long then the network cannot be in your critical path, and you have to deal with it. If you're on a low end phone any I/O at all is going to kill you, including loading too much code, and needs to be out of the way.
If you can tell the UX is going to be bad you will need to abort and tell them that, though they really will not like it, it's often better to prevent such users ever getting your app in the first place.
I come from mobile games, and supported titles with tens of millions of players around the world back in the early 4G era. All I can tell you is not once did mobile ping become a concern - in fact those networks are shockingly good compared to wifi.
I can only guess the connectivity between your mast and the Internet is awfully congested, and/or you are in the middle of nowhere.
One of the reasons starlink does as well as it does is the ground stations are well connected to the wider world, whereas your nearest cell mast might not be.
No. Just no. There’s an entire generation of devs at this point who are convinced that a DB is something you throw JSON into, use UUIDs for everything, add indices when things are slower than you expected, and then upsize the DB when that doesn’t fix it.
RAM access on modern hardware has a latency of something like 10 nanoseconds. NVMe reads vary based on queue depth and block size, but sub-msec is easily attainable. Even if your disks are actually a SAN, you should still see 1-2 msec. The rest is up to the DB.
All that to say, a small point query on a well-designed schema should easily execute in sub-msec times if the pages are in the DB’s buffer pool. Even one with a small number of joins shouldn’t take more than 1-2 msec. If this is not the case for you, your schema, query, or DB parameters are sub-optimal, or you’re doing some kind of large aggregation query.
I took a query from 70 to 40 msec today just by rewriting it. Zero additional indexing or tuning, just unrolling several unnecessary nested subqueries, and adding a more selective predicate. I have no doubt that it could get into the single digits if better indexing was applied.
I beg of devs, please take the time to learn SQL, to read EXPLAIN plans, and to measure performance. Don’t accept 200 msec queries as “good enough” because you’re meeting your SLOs. They can be so much faster.
"All that to say, a small point query on a well-designed schema should easily execute in sub-msec times if the pages are in the DB’s buffer pool"
Shopify is hosting a large number of webshops with billions of product descriptions, but each store only has a low visitor count. So we are talking about a very large and, hence, uncacheable dataset with sparse access. That means almost every DB query to fetch a product description will hit the disk. I'd even assume a RAID of spinning HDDs for price reasons.
Shopify runs a heavily sharded MySQL backend. Their Shop app uses Vitess; last I knew the main Shopify backend wasn’t on Vitess (still sharded, just in-house), but I could be wrong.
I would be very surprised if “almost every query” was hitting disk, and I’d be even more surprised to learn that they used spinners.
Sometimes, yes. Sometimes not. This was on MySQL 5.7, and I wound up needing to trace the optimizer path to figure out why it was slower than expected.
While I do very much appreciate things like WHERE foo IN —> WHERE EXISTS being automatically done, I also would love it if devs would just write the latter form. Planners are fickle, and if statistics get borked, query plans can flip. It’s much harder to diagnose when all along, the planner has been silently rewriting your query, and only now is actually running it as written.
I think 500ms P75 is good for an app that hits network in a hot path (mobile networks are no joke), but I agree that 200ms is very very bad for hitting the DB on the backend. I've managed apps with tables in the many, many billions of rows in MySQL and would typically expect single digit millisecond responses. If you use EXPLAIN you can quickly learn to index appropriately and adjust queries when necessary.
People have gotten used to that, but UI work back to the 1960s has done studies and showed clearly that for many of these operations you get tens of ms before people notice and their attention wanes. The web often doesn't allow for response times as fast as the humans need, which is a good reason to write real apps not web apps. That is also why I use tabs - load a bunch in the background so when I'm ready I can just switch tabs and it is there.
500ms is the 75th percentile speed, so 75% of users are having load times faster than that. For context, Google's synthetic p75 loads emulate a crappy old Android phone on a bad network.
A linked post[0] says their p75 was 1400ms before 2023, yowza.
No. It on a request basis, meaning that one in a four clicks a user does take more than half a second to complete. Slow times for as low percentiles as 75 mean users hit the bad cases very often in practice.
2 seconds to wait for a webpage to load isn’t even that bad. If you take an average user on facebook it is horrendously slow - to someone who knows how fast something can be - but no typical user cares/notices. They just accept it.
Nike’s website is phenomenally quick. But again. Ask anyone if that is what they care about. Nope. It’s the shoes.
> Having your app burn battery for half a second doing absolutely nothing is bad UX. That kind of latency does have a meaningful effect on productivity for a heavy user.
The implication is that React Native is to blame for this and I'm not sure that's true. What would the ms delay be with pure native? I have plenty of native apps that also have delays from time to time.
It all depends on whether the number includes network roundtrip or not, which they don't state. I read it as not including a network request, i.e. all CPU and local I/O.
The article they link to about how they optimized talks about caching network calls as part of their strategy to get below 500ms, so I would assume network calls are included in the number.
Replying to myself for clarification: I did not read their 500ms number as including waiting for a network. It sounded like that's how long it was taking React Native to load local data and draw the screen. If that's not the case, it's a very different story.
> For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful.
Indeed. The games industry uses immediate mode GUIs and people get upset if they achieve less than 60fps. Having everything be this slow is just a huge failure of coordination on behalf of the industry.
(next mini question: why is it seemingly impossible to make an Android app smaller than 60mb? I'm sure it is possible, but almost all the ones I have from the app store are that size)
Can't speak for every app but I've worked on several through the years, a sizeable chunk of all the apps I've worked on were assets. It's possible to hide a lot of it from the app store size if you really wanted to but you'd end up downloading all the assets at some point anyway so there's really no point in putting the extra engineering effort in just to make your app store number look smaller.
This obviously isn't the case for every app and most of the ones I've worked on had a lot of bloat/crap in them as well.
It's a cross-platform spiritual successor of WPF and it kicks ass! You get proper separation of models and views, you can separate what controls there are from how they look (themes/styles), you can build the entire thing into a native compiled application with very reasonable speed and memory use.
> I just hope that people choose targets closer to 100ms.
Why? If it's about the phone burning battery for 500ms, it probably isn't doing that - it's just waiting for data to arrive. And even when it's rendering, it's probably not burning battery like say Uber (with which you can feel the battery melt in your hands).
But that's not why I am commenting. I am writing because so many commentors are saying that 500ms is bad. Why is 500ms bad, as long as the UI is not freezing or blanking out?
Why not lower expectations, and wait for half a second? Of course, there are apps for which 500ms is unacceptable - but this doesn't seem to be one of them.
Subjectively, I find the Shop app to be quite nice and speedy. It works well enough that I’d never have guessed it is using any kind of cross platform framework.
It’s easy to get caught up on numbers, but at the end of the day the user experience is all that matters. And I very much doubt that performance is a concern for their users.
Exactly. Tech people almost always go to the "performance wormhole" arguing about ms and how it could be improved 10x - myself included. But working at a startup the past couple of years, I came to the conclusion that it does not matter to the end users at all. If an app is "nice" and "speedy" as you say, that’s enough. Shopify made a good decision and tradeoffs; it works for them, and I would argue it would work for 90% of other companies as well. You don't really need a native app for most purposes; React Native and Flutter are good enough.
Assuming the 500ms is mostly delay for fetching data over a socket, unless the code is really broken that should not really be burning battery. <500ms for display of non-trivial network-fetched data is great regardless of whether it's rendered by react native or is a fully native app. They would both be I/O-bound on the network primarily, with a small but insignificant compute overhead for RN. If the data needs lots of transformation (though not compute-intensive transformation like calculating hashes or somethign) upon returning that could make a difference, though again I'd be surprised if CPU for RN vs native was all that different.
As an Elixir dev who aims for and routinely achieves <10ms response times, (and sometimes < 1 ms for frequent endpoints that I can hand optimize into a single efficient SQL query, which Ecto makes easy I might add!) I find the response time to be the more egregious part :-D
> Having your app burn battery for half a second doing absolutely nothing is bad UX.
Why are you assuming the app is either burning much battery or even doing more than waiting on current data from the server? For an app that I would assume isn't much use without up-to-date data from the server?
I thought the section on the importance of native devs and how they're staffing mobile was really interesting:
"Native devs are crucial
Mobile engineers who specialize in iOS and Android are essential to building great mobile apps. There is no replacing experience and taste that comes from having built many mobile products and deeply understanding conventions and usability. Being able to drop down to the platform layer, write bindings, master build & release, distribution, etc requires native expertise.
They also play a vital role in optimizing app performance across the myriad of device models, ensuring a consistent user experience for all users. Additionally, native expertise is essential for managing React Native version updates, as well as adopting new features, APIs, and tooling changes that accompany new iOS and Android releases. You can't build a good product without these experts.
We invested in training our native mobile developers in React Native through a self-serve course that covered everything they needed to know to ship production-ready code. Additionally, we set up office hours with developers who were already proficient in React Native to provide support through Q&A sessions, pair programming, and code reviews.
We also supplemented our mobile teams with some web developers for their Javascript, Typescript, and React expertise. This ensured we had strong expertise in both native and React Native, and over time, it levelled up the entire team.
Having a good mix of native and web developers is the key to building great mobile apps using React Native in our experience. "
Probably the first "we adopted x" blog post that I can find relatable and spot-on.
I think it's one of the big misconceptions that React Native is _the_ path to get your web devs or even existing code onto mobiles. That's how you get the criticism that RN builds bad, mouldy apps.
Between our clients that have had this issue with quality and shops in the same space as us that haven't (one who boasts a review on one of their apps being "an example on how to build a proper fully native app"), having a good portion of native devs on the team is a big differentiator. Unfortunately this means a RN Team isn't as cheap as some hope.
I was listening to a podcast around 2017 (?) with AirBnb (?) devs when they were using RN and I remember they said “RN is a tool for mobile devs to not write the same app twice, not a shortcut for web devs to not learn native”.
As someone who works with React Native this is definitely true. Imagine a venn diagram:
Full Navive: 2 very big bubbles
React Native: 2 small bubbles and one big bubble
It doesn't happen very often but it can be quite annoying to implement features that need native controls on both platforms. In my case I only know native android (no ios) so when implementing native things I need to bring in an ios native dev and agree on the communication API and any platform-specific edge case before implementing stuff.
It is a lot easier when I can do it all by myself and it is even harder for team members who have no native experience at all.
Blazing fast is a bold claim. I use this app nearly every day on a brand new Pixel 9 Pro and, while much improved from a few years ago, it is far from "blazing fast".
For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful. UX studies indicate 0.1s as a number where an application no longer feels instantaneous. (https://www.nngroup.com/articles/response-times-3-important-...)
Contrast this against something like the Slack app where the screen is navigating even before the pressed animation has appeared. Or for an app with probably not as much engineering focus, Fastmail, which begins the screen transition within 100ms of the pressed animation state appearance.
On our apps we consistently see a p50 3-4x speed difference between iOS and Android (though there are more lower end android devices). Hard to fathom if it's all due to variability in android devices vs RN being less performant on Android.
Developing for Apple can be a PITA with their strict background processing rules, apps just terminate/stop working unless they fall under a special case. I get it but yeah.
edit: by terminate I don't mean crash, it just stops code execution an example is an active socket connection getting disconnected unless it's doing something like streaming audio
But as a user I appreciate the strictness much more. I don't have to worry about closing background apps or having a bunch of crap running when I'm not actively using it. The OS (mostly) handles that for me, as it should.
Absolutely. I’d rather have backgrounded apps unexpectedly closed from time to time than to find a big chunk of battery gone at a bad time because some app I don’t even care about has decided it needs to keep running and eating resources for some reason.
I'm surprised that there was no mention of Expo. In the past, I would say bare-metal is better than Expo-managed React Native projects because of the limitations when it came to native modules. Fast forward to today, and anything you can do in a bare metal RN app can be done with Expo.
The biggest game-changer recently is Expo's Continuous Native Generation[0]. You can configure all of your native modules and ios/android files with a simple config file (which has its limits, whereby you'll need to write an Expo Config Plugin[1]). You will no longer commit the ios/android native code to your repository, and instead let it be procedurally built.
This resolved a lot of environment issues developers would often run into, and greatly simplified onboarding new devs. You can build your iOS/Android apps through the CI with ease. And you'll no longer be afraid of upgrading React Native, as Expo will handle all of the breaking changes in the native code for you.
My guess is that Shopify started with bare metal React Native apps (which I would have done the same 5 years ago), and now migrating back to Expo-managed projects is nontrivial. At my work we only manage one app, and it was well worth migrating back.
React Native renders actual native widgets to the screen, so for example on iOS you would write to cross-platform abstractions but you’d still get real UIKit components on the screen.
Flutter draws its own components that can look superficially like the target platform (or not, it’s up to the developer) in a manner closer to a game engine. HN seems to love Flutter and apparently the developer experience is excellent, but as a user I find Flutter apps to be in general a poor experience. They rarely look or act quite right (assuming the developers even try; I’ve used a number that look like someone has transplanted an Android app onto iOS).
My thought is that Expo prioritises web compatibility too much to the point that it leans into conventions with things like navigation that are web-oriented and these contribute towards an app not feeling like a native app.
why Expo over Flutter? do React Native and Expo provide better abstractions over the Java/ObjC native APIs? again I've never done native dev just curious sorry if this isnt HN worthy comment
The tooling for Flutter is better, but Expo brings React Native much closer.
I fend that React Native app "feel" more native because they're actually using native components, but controlled via a JS runtime. Flutter on the other hand mostly renders to a canvas and re-implements native controls (although it can also wrap native components like RN does).
This leads to there being less of an "uncanny valley" in React Native apps compared to flutter. It also means that all the little details from the system (the text selecting and editing interactions in text inputs being a major one) are idential to native apps when using React Native, because it IS the native component.
The downside to this is that you need to consider platform differences more with React Native, which is one of the things which leads to developers without mobile experience having issues with it.
As the article says, you get the most out of React Native if you're a mobile developer, or at least have someone on the team who is. You can't abstract away all the details of a mobile platform without some tradeoffs.
Not apples comparison imho. Flutter requires using a new fringe language and while it might be a very nice language it's a heavy lift in most businesses contexts to march off into a new language just to use a mobile framework.
So, the main reason for Expo (there are others) is: get to write in the language most developers already know.
You'd hope they benchmarked the old native iOS app and the RN app.
Since the blog post doesn't mention previous native-only perf, I'd assume they didn't compare or the RN version isn't close to native-only perf (leaning heavily towards the second reason).
Looking at a previous blog post, the first hunch seems to be correct - the second may also be true.
I hope they benchmark their load-screen time with every release/CD to stay on top of any regressions, otherwise, there'll be more mad scrambles when the perf debt piles up too high.
Right after that, they have three links (one blog post, two videos) to explanations of how they optimized screen load speed that can answer that question.
It's a mix of layout stuff (like using lazy list views to avoid below the fold rendering) and network fetches (they talk about using better caching).
That was my initial thought as well. Anyone know what native screen loads typically are? I’m sure it varies wildly between apps, but 500ms seems like it would be on the slower end of a “fast” app.
It really depends on what a "screen load" means exactly. If its just rendering the screen from some client-side data then I would expect something <16ms. To support 120fps displays, it would need to be <8ms.
If a "screen load" includes making a network request to fetch data, then this is a very weird metric to include in a post about React Native. Most of that time budget should just be waiting for the request to complete. Just as before, it should take <16ms to render the screen once the data arrives.
For typical apps, the four variables here are backend latency, network latency, client-side deserialization, and client GUI rendering. (Less commonly, apps which have complex client-side state will also spend time reconciling server and client state.)
Keeping UI rendering under 16ms is the gold standard for native apps. That leaves only deserialization as the other target which the mobile developer can optimize. However, the typical solution there involves convincing the backend to ship a different format (i.e. switching from JSON to binary PList or to SQLite DB file).
> Keeping UI rendering under 16ms is the gold standard for native apps.
No, it isn't.
If you're not including the actual rendering, so the actual code of the app only or at least only the code on the UI thread, the targets are much smaller. More like 3-6ms/frame.
If you're including rendering then pipelining and 90hz+ being common still changes that anyway.
For reference, our app is 100% in Jetpack Compose, our screen rendering for both cold and warm are in the average of ~460-480ms. App start is around ~480ms.
If your warm and cold starts are that close I'take a closer look at your measurement methodology. Could be your cold starts are actually warm, or your timing is starting late.
This strikes me as curiously defensive, in that Canadian way of praising things that are obviously problematic to draw attention to them.
The wider noise around React Native is seemingly that it works, especially while iterating on things, but it makes the final 20% of work much harder than it already was. As one person put it to me recently “with RN you just have to face the fact you won’t be winning any design awards”.
What really amazes me is how far React Native and web React have separated, to the point using the web one is a complete non event.
I just kinda looked around the Shopify app to get a feel for it. There are a few frameworks that tap into native view switching (transitioning between pages and tabs), which creates most of the native feeling (along with native view components like lists/menus/switches).
I don’t know why the quality of the app feels cheap, but it just feels so (the web views load in with zero ease, they just jank onto the screen. So while you have native screen transitioning, you still have this low quality feeling of a bad nypost article shitting out an ad popup on you. Hard to explain, but that’s my my general feeling).
Regardless, while not impressive, it’s in this non-impressiveness that informs my unwillingness to invest into native or something like Flutter. These apps are too simple to go through the hoops.
Shopify RN app is a good example of a mundane non-sexy tech decision.
Overall nothing beats CSS and JavaScript for UI, but even in 2025 we cannot reliably push 60fps.
I disagree with you on a few specifics, but I think the more general question does become what should the Shopify app be like? Non sexy is, as you say, probably the right call.
For mobile apps generally I cannot recall the last time I was actually impressed by one. The reverse is often true, such as with Sonos. Individual features (again Sonos, the calibration it can do) can be neat but experiences as a whole have gone off a cliff, React Native or not.
I suspect you maybe haven’t used Dart then because it’s genuinely not even close. I know in a philosophical sense everything is subjective when you squint hard enough but I’m also talking about very clear and concrete things.
Just to give one simple example. Take the concept of a mixin where you want to essentially create a partial class interface and use it for basic composition. An incredibly straightforward 101 level OOP concept.
Then take a look at how it works in Typescript here:
Glad they spent some times discussing the downsides. I’m 4 months in to a Hotwire Native replacement for an unmaintained React Native app. The differences are stark and I could definitely see myself picking up Hotwire again for another project if given the same constraints, but I’ve had good experiences with React Native in the past too. Ultimately though I just do not like all the work that has to go into maintaining a large scale React codebase.
Theres a constant churn of a bunch of dependencies. Devs add minuscule libraries all the time. And I think some of the best React libraries have been abandoned, which is kinda sad, but nice from a maintenance perspective.
React very much feels like programming using only side-effects and that’s not really a fun experience IMHO. Performance issues are also somewhat difficult to spot in review and not very elegant to solve.
It’s been a few years since I’ve used React Native so maybe things are better now?
This is my experience with all javascript stuff these days. If you leave the codebase even for a few months now you're spending days updating it to all the new breaking library changes. Worse, if your tooling is out of date you're probably spending a week just fighting to fix/change/update the tooling. It's the most brittle tech stack I've ever had to work with.
This is the missing criteria in the technical decision making, IMO. How reliant is the team on the recruiting/retention of the current size and structure of the talent, both on the team and in the wider community?
Small teams trying to keep burn ultra low vs. giant companies might have similar technical goals but opposite staff capabilities. This is a crucial factor.
A second-order effect is how much time/energy/money you have to throw at maintenance. Can you afford to spend X% of your time on maintenance? Which technologies offer comparative advantages on maintenance cost? These are surprisingly often easy to answer, and nearly never explicitly considered!
I agree that maintenance costs are often overlooked/ignored, but I'm curious how you get answers on the costs. I've never found it particularly easy to get reliable information on maintenance costs.
I guess what I was thinking was: even if you can't quantify it, you can squint at the comparative advantages and trade-offs and make a qualitative, yet objective judgement call.
Im sorry but I was never able to relate to this problem.
All core libraries of javascript are atleast a decade old at this point and that too without any major breaking changes.
Express is almost decade old, react is more than a decade old, redux is almost a decade old,
Tailwind is the only new thing but that too is almost half a decade old.
You’re never telling React “do this”, instead it’s always “change this state” and then hope that it does what you expect it to do, but instead it re-renders 10 components for nonobvious reasons. Sure useMemo can help with this, but, eh, I just wish it worked the first way.
And every React-adjacent project either ends up abandoned or subsumed into the beast.
After having used Ember for several years I find it very sad they didn't develop a "mobile" offering, the dev experience is fastly superior (especially as it relates to state handling).
Hooks are a bit of a cancer, they leak absolutely everywhere on top of making it quite difficult to reason about re-renders.
> React very much feels like programming using only side-effects and that’s not really a fun experience IMHO.
This is interesting and I like the way you've phrased it. Are you talking about React Native, or React in general? And do you use hooks?
I like React on the web, but only when using hooks and only because I haven't found anything that I like more than it. I still find it tedious and overly hook-y¹. It also gives a lot of wiggle room for devs to shoot themselves in the foot with useEffect, like some of my previous clients have done.
¹ Hold on, I gotta pull in 18 hooks from across my project, npm dependencies and react itself before I can write the jsx in what would otherwise be a 10-15 line fooButton function.
> I like React on the web, but only when using hooks and only because I haven't found anything that I like more than it.
After being thrown into the Angular woods for a while I found that what I really wanted was just a "React with RxJS Observables that look like writing Hooks if you squint, but don't have some of the complex rules either" and then I realized that I was basically trying to reinvent some of Knockout, but with TSX templates. I'm still amazed by how much I was able to accomplish from that idea, including some of the "advanced" features of modern React, in a relatively small package (modulo the one and only one dependency on RxJS).
I don't know how many other developers want the same thing.
(I know some find RxJS overly complex, which is exactly why Angular is as awful to work in as it is, both in how it badly uses RxJS (and teaches bad habits) and how there's generally three ways to do everything, one with RxJS and two others avoiding it or misusing it, with now a fourth way of Signals which are just RxJS-lite with Knockout-style `computed`, proving time is a flat circle and Angular remains a design-by-committee mishmash of too many things that don't interoperate well. I think learning Angular's mishmash is far worse than just learning RxJS well, but I also spent a lot of time doing Rx in C# and in CycleJS for a while, too.)
React's reactivity model is "inverted" from almost every other model out there. Vue, to me, feels the most like Knockout. I also find that I rarely run into edge cases compared to React and Vue feels the most like OG HTML.
I did investigate Vue with TSX at one point. It wasn't for me, but I did like Vue with TSX over Vue's primary template language.
A part of the way I see it is that Knockout promised "Observables" and `computed` was sort of the distracting fork away from something like RxJS Observables. Now that fork seems to be named "Signals". I'm not a fan of "Signals" and think they miss a lot of the power and elegance of "real" Observables like RxJS. I understand the appeal of the "magic" of `computed` tools. I better appreciate the power of the larger toolbox of RxJS operators. (I also think Observables are a lot easier to unit test than `computed`. A good "marble test" is a thing of beauty.)
Yea precisely. Hooks themselves are OK, it’s just plain ole code reuse, necessary the language itself makes that somewhat difficult. But then you’re not programming JS anymore — you’re wed to React and nothing else. I hate how it takes over codebases.
We maintain a few number of projects for clients - the apps are feature complete and will not change much in the next years. The goal here is to spend not much money on the apps but to keep them functional in the appstore.
RN is somewhat cheaper up fron than native development or say flutter. Unfortunately, maintenance cost is high and difficult to predict.
Why?
Appstores are adding new requirements and increase API-level all the time. Support for that is often baked into new RN versions. Unfortunately, new RN versions often break things, which break libraries in turn. So you need to upgrade this morass and if you are unlucky, you need to redevelop huge swaths of your app because the lib now is deprecated /works differently / will never be updated to the new RN version.
Also true for any large JS/TS application, in my experience. It's an emergent property of a developer culture that places no value on backwards compatibility.
I was glad to see the discussion as well but it feels like the downsides were also very understated. Working on an RN app as a native dev requires a lot of cross-domain knowledge that isn't typical for a native dev.
Great to see Hotwire Native here! I was asking myself would it be easier for Shopify to steer back more towards Rails ecosystem technologies. They went React / JavaScript full-throttle. JavaScript ecosystem seems so immature, and changing constantly with a huge maintenance burden. Rails feels really stable and Hotwire, although it's changing, feels stable. Stimulus was announced in 2018 I believe and they didn't have a single paradigm shift comparable to React's hooks, server components, etc.
So basically, as long as you are large enough to have direct contact with the upstream team, have a separate team to manage React Native itself, and have two separate teams for iOS and Android to manage stuff that needs native access, you are good.
> We care very deeply about performance at Shopify
> We’ve achieved sub-500ms (P75) screen loads in the Shopify app
Pick 1.
Also interesting that this deep care about performance extends to blogs, where a simple animated image showing how awesome hot reload is causing a noticeable delay in scrolling
Every so often they write an article talking about how great their several-years-long effort to switch to React Native is going, and every time I read it and come away with an even more negative opinion of React Native.
I've learned not to trust company technical blogs. They're all just marketing fluff intended to act as recruiting materials, and judging by the comments here, it's working. As your post highlights, taken in the greater context, it sounds like their decision to move to React Native was so slow going and the end-user experience is just okay.
I suppose taken from the perspective of "We want to easily hire frontend devs that can easily be slotted in to work on the project and make impact on all platforms, including mobile" then it's a win, but at a cost in years and a degraded user experience. From a business perspective, probably a good move in the long run.
I was just showing my team this article. We'd start getting warning alerts if our P75 page load times reached 500ms. I wonder if we're measuring load times differently.
Agreed. The web driven enshittification of everything continues. It doesn't have to be this way. It really doesn't.
If what you're using makes it this way, maybe stop using it? Stop drinking the kool-aid, get over your sunk cost fallacy and start thinking about what your end user experience should be, and work backwards from there, making decisions that guarantee you hit it. Don't choose the language or tool first and leave yourself constrained to only what is possible in it.
The sunk cost fallacy in this case would've prevented the switch from native. And what's worse is they've thought about user experience, "just" set the bar for it too low
Will another 10 years go by and there still won't be a dark mode for the app?
As someone who uses the mobile app basically every day, it is absolutely one of the things that bothers me, every single time I use it. That's not a good thing.
It's constantly surprising to me that this one aspect of software appearance is a hill that the industry has collectively decided to die on.
We can't agree to use colours that are unambiguous for colourblind folks, we can't agree to use sufficient contrast in our UIs, we can't agree to use big enough touch targets, most companies are truly awful at accessibility... and yet everyone wants dark mode, and most companies implement it. How much time have we lost as an industry making interfaces harder to read?
Dark mode is an accessibility feature for myself, and many others I would imagine.
Calling it dark mode might not be ideal though. We should probably call it something like system theme awareness, or anything that doesn’t make the reader to think “gee, that’s not the theme I like.”
Before installing Noir on iOS, I always appreciated opening HN, or any website without dark mode, and feeling my eyes melting even on lowest brightness setting. Great and easy to read! Thanks for keeping my eyes I check!
By the way, is it Shopify’s open source policy to ignore outside PRs, or are they simply understaffed? My PR which addresses a major issue in one of Shopify’s big React Native libraries has received zero acknowledgement from Shopify for almost a year.
World of subpar development experience. Truly amazing!
Shitty native toolchains that constantly need to be updated (looking at you, Xcode), dumpster fire IDEs (both Android Studio, still don’t understand how Google managed to butcher IntelliJ like that, and Xcode), half completed libraries that are either deprecated or in alpha and, for some reason, in need of constant changes. Compile times in double digits for large projects. Stay up to date with shitty Gradle if you want to have semi sane development experience on Android (maybe they’ll finally roll out declarative version this year, but they said they’re still committed to original DSLs, so good luck to poor sob who will encounter mix of Groovy and Kotlin DSL).
Wonderful world of single vendor languages where only interests of vendor dictate how language evolves (just how much resources and time were wasted on horrible KMP, because JetBrains wants to grab mobile market fully).
I agree Xcode might be one of the worst IDEs I have ever used but at basically every company I've worked for the update cycle was maybe once or twice a year and for the most part was painless. There's been maybe one or two upgrades of Xcode in my ~13 year career that were a headache.
I have no idea what libraries you're talking about but you don't really need to use any third party libraries to build a good iOS app. Unless you're doing something incredibly obscure most of the big/popular ones are very well maintained.
Has anyone had a success with using "React Native for Web" for a Web-first consumer site (for desktop and mobile, including heavy plain text entry at times), but also being able to use the same React Native code to go to the iOS and Android app stores (when you reluctantly also satisfy those consumers who really-really want to install native apps)?
Bluesky. They use Expo on top of React Native, use React Native for Web (with a desktop and mobile), and for mobile native apps.
Let's note that because the clients are fully open-source and on GitHub, people from Expo and React Native are helping the little team behind the clients improve performance over time: it's not their final form!
Uniswap does this successfully. They share quite a lot of code between web and native, and their apps are open source. I made Tamagui, the library they use for sharing UI code, which goes much further than RNW in making this possible.
There's also the question of the amount of footgun you give to developers. While iOS is more performant than Android, Google gives Android developers much more guidance in best practices and patterns that help developers avoid issues around architecture, injection, state and threading.
I've seen many iOS projects overwhelmed by tech debt while its Android counterpart was still OK-ish. I don't believe this is coincidence.
So how hard is it to apply React Native the correct way? Having a dedicated team of dozens of engineers including native experts for each platform is different than your average 4-8 people dev (web, API, iOS, Android) team. Let alone if you only have people experienced in web doing the work.
When I build Swift applications the fact they have sub 500ms loads is not an achievement, they're simply already doing that without me trying. But I have found the right way to build iOS apps myself over the years, very little help from Apple.
I started with Svelte but ecosystem that React has is giant.
Plus React Compiler is already being used in Instagram and Facebook so within this year, the virtual dom diffing would be a thing of past.
The virtual dom is just part of the performance problem, the biggest problem in my opinion is the huge complexity that React adds, they solved part of it with useReducer and useSyncExternalStore, but I don’t think it will eventually be solved.
I really wanted to work with native SwiftUI, but the lack of hot reload and long waiting times for the preview to refreshes is just painful. React Native on the contrary, delivers good enough live feedback experience. I don’t enjoy React, but compared to waiting 10 seconds for preview changes and occasional “expressions too complex, break it down to smaller one” - I’d choose React. I do still trying to code natively on every XCode updates; just with the hope of it getting better somehow.
That's a difficult to interpret metric. If it's only being met 75% of the time, I'd tend to assume most features are much better than that, but some are never meeting the target, and there's no indication by how much.
I really think aside from games, media editing, and other such heavy activities, 90% of apps are, or should be, web views. What they are doing makes a lot of sense.
Not sure at shopify size, but I highly encourage startups to use cross platform for mobile distribution. React native's OTA update alone is already worth for fast movers.
Cannot recommend RN enough. One code base gives you three apps. Web, Android and iOS. With NativeWind, you have full Tailwind available to you and I had great success to the point where I have been thinking that I should be building customer facing web apps in RN (React Native Web + Tailwind) which at any time can be exported as native apps while already being a great web app.
I frequently encounter Shopify e-commerce in the wild, and it’s my most disliked experience. From browsing the stores to checkout, it always feels clunky.
I always shrugged it off as iOS bullshit but now I know the real reason. It’s just slow enough to make you doubt yourself - it’s not the website, it’s probably my shitty {phone|poor internet|computer}
So many of you are yapping about how the performance is not good enough. Yet none of you are talking about how Shopify literally could not develop their mobile app without it. The 3 minutes to compile the app just to do a trivial change makes it near impossible for devs to be productive. Hot reloading is what got me hooked to react native, I literally cannot allow for my brain to rot waiting for minutes waiting for Xcode to compile for a simple border radius change.
this is an unserious reply. and if you are serious then you're likely not a frontend developer. often you want to test if a certain kind of hack fix works. your mind becomes glued to thinking about "does that fix it?" - hence why it's not easy to branch into a new line of thought then just come back to the change you pushed minutes ago. You're pretty much suggesting that the developer context changes into another thing for anywhere between 1 and 4 minutes and then context switches back to see if the build worked. The task that you'd be context switching into for 1-4 minutes will be interrupted by another thing and you'll likely make no progress doing it
I agree with most of the other comments here, and it sounds like Shopify made sound tradeoffs for their business. I'm sure the people who use Shopify's apps are able to accomplish the tasks they need to.
But as a user of computers and occasional native mobile app developer, hearing "<500ms screen load times" stated as a win is very disappointing. Having your app burn battery for half a second doing absolutely nothing is bad UX. That kind of latency does have a meaningful effect on productivity for a heavy user.
Besides that, having done a serious evaluation of whether to migrate a pair of native apps supported by multi-person engineering teams to RN, I think this is a very level-headed take on how to make such a migration work in practice. If you're going to take this path, this is the way to do it. I just hope that people choose targets closer to 100ms.
I would read the <500ms screen loads as follows:
When the user clicks a button, we start a server round-trip and fetch the data and do client-side parsing, layout, formatting and rendering and then less than 500ms later, the user can see the result on his/her screen.
With a worst-case ping of 200ms for a round-trip, that leaves about 200ms for DB queries and then 100ms for the GUI rendering, which is roughly what you'd expect.
Since the post is about the benefits of react, I'm sure if requests were involved they would mention it.
Also, even if it was involved, 200ms for round-trip and DB queries is complete bonkers. Most round-trips don't take more than 100ms, and if you're taking 200ms for a DB query on an app with millions of users, you're screwed. Most queries should take max 20-30ms, with some outliers in places where optimization is hard taking up to 80ms.
> 200ms for round-trip and DB queries is complete bonkers
Never lived in Australia I see
If Shopify app P75 response time is that slow due to that the users are in Australia, then they should get a data center there.
In the real world, you can't just optimise for the sake of it. You need to get a business case for it. Because it all boils down to revenue vs expenses
If the P75 is bad because of Australia that means 25% of their customer base is Australian.
Should they?
You could do the maths on conversion rate increase if that latency disappeared vs the cost of spinning up a dc & running it (including the mess that is localised dbs)
I’m not sure the economics works out for most businesses (I say this as an Australian)
Probably not, because the if-statement in my post is likely false. The Australian user base is likely not high enough.
> Most queries should take max 20-30ms
Most queries are 20-30ms. But a worst case of 200ms for large payloads or edge cases or just general degradations isn't crazy. Without knowing if 500ms is a p50 or p99 it's kind of a meaningless metric but assuming it's a p99, I think it's not as bad as the original commenter stated.
They mention later in the article that the 500ms is p75.
Realistically 50ms p75 should be achievable for the level of complexity in the shopify app.
P75. I can only image the p90 and p99 are upwards of 1 second.
Agreed. The P95 and P99 in particular are likely to be over 1 second, possibly over 2. They chose P75 to be able to post a seemingly impressive number.
I personally wouldn't be very happy with a P75 of 500 ms. It's slow.
Ah. I see we are spoiled with <4ms queries on our database. See, it all depends on perspective and use case. :)
I have a 160ms ping to news.ycombinator.com. Loading your comment took 1.427s of wall clock time. <s>Clearly, HN is so bad, it's complete bonkers ;)</s>
time curl -o tmp.del "https://news.ycombinator.com/item?id=42730748"
real 0m1.427s
"if you're taking 200ms for a DB query on an app with millions of users, you're screwed"
My calculation was 200ms for the DB queries and the time it takes your server-side framework ORM system to parse the results and transform it into JSON. But even in general, I disagree. For high-throughput systems it typically makes sense to make the servers stateless (which adds additional DB queries) in exchange for the ability to just start 20 servers in parallel. And especially for PostgreSql index scans where all the IO is cached in RAM anyway, single-core CPU performance quickly becomes a bottleneck. But a 100+ core EPYC machine can still reach 1000+ TPS for index scans that take 100ms each. And, BTW, the basic Shopify plan only allows 1 visitor per 17 seconds to your shop. That means a single EPYC server could still host 17,000 customers on the basic plan even if each visit causes 100ms of DB queries.
Having indices doesn’t guarantee anything is cached, it just means that fetching tuples is often faster. And unless you have a covering index, you’re still going to have to hit the heap (which itself might also be partially or fully cached). Even then, you still might have to hit the heap to determine tuple visibility, if the pages are being frequently updated.
Also, Postgres has supported parallel scans for quite a long time, so single-core performance isn’t necessarily the dominating factor.
That seems really slow for a get request to hn without a session cookie (fetching only cacheable data).
And being not logged in - probably a poor comparison with Shopify app.
I do not understand this thinking at all, a parsed response into whatever rendering engine, even if extremely fast is going to be a large percentage of this 500ms page load. Diminishing it with magical thinking about pure database queries under load with no understanding of the complexity of Shopify is quite frankly ridiculous, next up you’ll be telling everyone to roll there own file sharing with rsync or something…
I know - old man yells at cloud and stuff - but some 8-bit home computers from the 80s completed their entire boot sequence in about half a second. What does a 'UI rendering engine' need to do that takes half a second on a device that's tens of thousands of times faster? Everything on modern computers should be 'instant' (some of that time may include internet latency of course, but I assume that the Shopify devs don't live on the moon).
Moorsches Law v2 (/s) states that while computers get faster, we add more layers so computers actually get slower.
Back when "WinTel" was a true duopoly, we used to call this "Gates Law".
"What Andy giveth, Bill taketh away."
Not sure why people keep bringing the old (my machine x years ago was faster). Machines nowadays do way more than machines from 80s. Whether the tasks they do are useful or not is separate discussion.
Casey Muratori has a clip [0] discussing the performance differences between Visual Studio in 2004 vs. today.
Anecdotally, I’ve been playing AoE2: DE a lot recently, and have noticed it briefly stuttering / freezing during battles. My PC isn’t state of the art by any means (Ryzen 7 3700X, 32GB PC4-24000, RX580 8GB), but this is an isometric RTS we’re talking about. In 2004, I was playing AoE2 (the original) on an AMD XP2000+ with maybe 1GB of RAM at most. I do not ever remember it stuttering, freezing, or in any way struggling. Prior to that, I was playing it on a Pentium III 550 MHz, and a Celeron 333 MHz. Same thing.
A great anti-example of this pattern is Factorio. It’s also an isometric top-down game, with RTS elements, but the devs are serious about performance. It’s tracking god knows how many tens or hundreds of thousands of objects (they’re simulating fluid flow in pipes FFS), with a goal of 60 FPS/UPS.
Yes, computers today are doing more than computers from the 80s or 90s, but the hardware is so many orders of magnitude faster that it shouldn’t matter. Software is by and large slower, and it’s a deliberate choice, because it doesn’t have to be that way.
[0]: https://www.youtube.com/watch?v=MR4i3Ho9zZY
> I’ve been playing AoE2
If you buy poor software instead of good software (yes, branding, IP and whatever but that's just even more reason for companies not to make it good), complaining doesn't help does it. Commercial software is made to be sold and if it sells enough that's all company executives care about. As long as enough people buy it, it will continue to be made.
Company devs trying to get more time/resources to improve performance will be told no unless they can make a realistic business case that explains how the expense of increased focus on performance will be financially worth in terms of revenue. If enough people buy poor software, improving it is not business smart. Companies exist to make money not necessarily to make good products or provide a good service.
I understand your point but you need to understand that business execs don't care about that unless it significantly impacts revenue or costs in the present or very near future.
Nah, it’s not just that. IME, most devs are completely unaware of how this stuff works. They don’t need to, because there are so many abstractions, and because the industry expectation has shifted such that it isn’t a requirement. I’ve also met some who are aware, but don’t care at all, because no one above them cares.
Tech interviews are wildly stupid: they’ll hammer you on being able to optimally code some algorithm under pressure on a time limit, but there’s zero mention of physical attributes like cache line access, let alone a realistic problem involving data structures. Just once, I’d love to see “code a simple B+tree, and then discuss how its use in RDBMS impacts query times depending on the selected key.”
Sure, and the screen in text mode was 80 x 25 chars = 2000 bytes of memory. A new phone has perhaps three million pixels, each taking 4 bytes. There's a significant difference.
And yet the GPU in your phone can run a small program for each pixel taking hundreds or even thousands of clock cycles to complete and still hit a 60Hz frame rate or more. It's not the hardware that's the problem, but the modern software Jenga tower that drives it.
If you are good those numbers are an order of magnitude off. In truth it is probably mostly auth or something. If you simply avoid json you can radically attack these things fast.
RTT to nearest major metro DC should be up to 20ms (where I am it is less than half that), your DB calls should not be anything like 200ms (and in the event they are you need to show something else first), and 10-20ms is what you should assume for rendering budget of something very big. 60hz means 16ms per frame after all.
What percentile? Topics like these don't talk about the 5G connected iphone 16 pro max, but have to include low-end phones with old OS versions and bad connectivity (e.g. try the same network connectivity in the London metro, where often there is no receiption whatsoever).
As you reach for higher percentiles, RTT and such start growing very fast.
Edit: other commenter mentioned 75% as percentile.
Independent of connectivity, UI rendering should be well under the device refresh rate. Consider the overhead of a modern video game that runs 60fps without a hiccup. It’s ludicrous that a CRUD app which usually only populates some text fields and maybe a small image or two can’t do the same
That's a page load, not a frame render.
Also, due to layouting, a CRUD app may actually be harder to optimize per frame, than the trivial to parallelize many triangle case as seen in games.
OP gave a render budget of 100ms _after_ the data has loaded. That’s unacceptable. If this were a MacOS app, that would mean dragging a window corner to resize the content , forcing a new layout and redraw, would yield 10 fps of change. And yet nearly all native apps redraw and layout instantly, even with complex tables of text at various fonts and sizes.
This is also a great litmus test to check if an app was made with electron because they always redraw slowly.
> What percentile?
There's no argument that starts this way which doesn't end either with "support working offline", or defining when you consider that a user has stepped out of bounds with respect to acceptable parameters, which then raises the question what do you do in that event?
If all you're trying to do is say 75% of users have a good experience, and in your territory 75% means a 150ms and that's too long then the network cannot be in your critical path, and you have to deal with it. If you're on a low end phone any I/O at all is going to kill you, including loading too much code, and needs to be out of the way.
If you can tell the UX is going to be bad you will need to abort and tell them that, though they really will not like it, it's often better to prevent such users ever getting your app in the first place.
I come from mobile games, and supported titles with tens of millions of players around the world back in the early 4G era. All I can tell you is not once did mobile ping become a concern - in fact those networks are shockingly good compared to wifi.
> RTT to nearest major metro DC should be up to 20ms (where I am it is less than half that)
over a mobile network? My best rtt to azure or aws over tmobile or verizon is 113ms vs 13ms over my fiber conection.
With times like that you'd be better off with Starlink!
I'm not joking: https://www.pcmag.com/news/is-starlink-good-for-gaming-we-pu...
Are you doing the 113 test from the actual device, or something tethered to it? For example, you don't want a bluetooth stack in the middle.
straight off my android phone by disabling wifi then moving through my 2 sims
That is odd then, but it is odd.
I can only guess the connectivity between your mast and the Internet is awfully congested, and/or you are in the middle of nowhere.
One of the reasons starlink does as well as it does is the ground stations are well connected to the wider world, whereas your nearest cell mast might not be.
Nah it could also be differing peering agreements with the ISP and the data center you are connecting to.
On T-Mobile, I get 30ms to Cloudflare but 150ms to my local AWS.
But I also get 450 mbps on T-Mobile so I’m not complaining.
If you have a dual SIM phone, try to swap your SIMs.
Don’t take the bait. It is a typical hn hyperbole comment
> 200ms for DB queries
No. Just no. There’s an entire generation of devs at this point who are convinced that a DB is something you throw JSON into, use UUIDs for everything, add indices when things are slower than you expected, and then upsize the DB when that doesn’t fix it.
RAM access on modern hardware has a latency of something like 10 nanoseconds. NVMe reads vary based on queue depth and block size, but sub-msec is easily attainable. Even if your disks are actually a SAN, you should still see 1-2 msec. The rest is up to the DB.
All that to say, a small point query on a well-designed schema should easily execute in sub-msec times if the pages are in the DB’s buffer pool. Even one with a small number of joins shouldn’t take more than 1-2 msec. If this is not the case for you, your schema, query, or DB parameters are sub-optimal, or you’re doing some kind of large aggregation query.
I took a query from 70 to 40 msec today just by rewriting it. Zero additional indexing or tuning, just unrolling several unnecessary nested subqueries, and adding a more selective predicate. I have no doubt that it could get into the single digits if better indexing was applied.
I beg of devs, please take the time to learn SQL, to read EXPLAIN plans, and to measure performance. Don’t accept 200 msec queries as “good enough” because you’re meeting your SLOs. They can be so much faster.
Beg all you want. They're still going to dump JSON strings (not even jsonb) and UUIDs in them anyway, because, "Move fast and break things."
I lament along with you.
“We’re disrupting!”
“Yeah, you’re disrupting my sleep by breaking the DB.”
>RAM access on modern hardware has a latency of something like 10 nanoseconds
What modern hardware are you using that this is true? That's faster than L3 cache on many processors.
Correction: DRAM latency is ~10 - 20 nsec on most DDR4 and DDR5 sticks. The access time as seen by a running program is much more than that.
As an actual example of RAM latency, DDR4-3200 with CL22 would be (22 cycles * 2E9 nsec/sec / 3200E6 cycles/sec) == 13.75 nsec.
"All that to say, a small point query on a well-designed schema should easily execute in sub-msec times if the pages are in the DB’s buffer pool"
Shopify is hosting a large number of webshops with billions of product descriptions, but each store only has a low visitor count. So we are talking about a very large and, hence, uncacheable dataset with sparse access. That means almost every DB query to fetch a product description will hit the disk. I'd even assume a RAID of spinning HDDs for price reasons.
Shopify runs a heavily sharded MySQL backend. Their Shop app uses Vitess; last I knew the main Shopify backend wasn’t on Vitess (still sharded, just in-house), but I could be wrong.
I would be very surprised if “almost every query” was hitting disk, and I’d be even more surprised to learn that they used spinners.
> just unrolling several unnecessary nested subqueries, and adding a more selective predicate
And state of the art query optimizers can even do all this automatically!
Sometimes, yes. Sometimes not. This was on MySQL 5.7, and I wound up needing to trace the optimizer path to figure out why it was slower than expected.
While I do very much appreciate things like WHERE foo IN —> WHERE EXISTS being automatically done, I also would love it if devs would just write the latter form. Planners are fickle, and if statistics get borked, query plans can flip. It’s much harder to diagnose when all along, the planner has been silently rewriting your query, and only now is actually running it as written.
Explicit query plan pinning helps a lot, alongside strong profiling and monitoring tools.
I think 500ms P75 is good for an app that hits network in a hot path (mobile networks are no joke), but I agree that 200ms is very very bad for hitting the DB on the backend. I've managed apps with tables in the many, many billions of rows in MySQL and would typically expect single digit millisecond responses. If you use EXPLAIN you can quickly learn to index appropriately and adjust queries when necessary.
500ms p75 is not good for the (low) complexity of the shopify app.
Also reporting p75 latency instead of p99+ just screams to me that their p99 is embarrassing and they chose p75 to make it seem reasonable.
100ms to render an iOS screen means dropping 6 frames. That would put an applicant in the "no hire" category.
The 500ms number is p75 - not worst case at all.
200ms round trip is like 10x more than what's reasonably possible.
Same with your other numbers.
People have gotten used to that, but UI work back to the 1960s has done studies and showed clearly that for many of these operations you get tens of ms before people notice and their attention wanes. The web often doesn't allow for response times as fast as the humans need, which is a good reason to write real apps not web apps. That is also why I use tabs - load a bunch in the background so when I'm ready I can just switch tabs and it is there.
What does "DB queries" mean here? The on-device sqlite stuff?
500ms is the 75th percentile speed, so 75% of users are having load times faster than that. For context, Google's synthetic p75 loads emulate a crappy old Android phone on a bad network.
A linked post[0] says their p75 was 1400ms before 2023, yowza.
[0] https://shopify.engineering/improving-shopify-app-s-performa...
> so 75% of users are having load times faster
No. It on a request basis, meaning that one in a four clicks a user does take more than half a second to complete. Slow times for as low percentiles as 75 mean users hit the bad cases very often in practice.
2 seconds to wait for a webpage to load isn’t even that bad. If you take an average user on facebook it is horrendously slow - to someone who knows how fast something can be - but no typical user cares/notices. They just accept it.
Nike’s website is phenomenally quick. But again. Ask anyone if that is what they care about. Nope. It’s the shoes.
Then there's McMaster Carr, which has great service, but all anyone seems to want to talk about is how snappy their site is!
Used to work for a competitor. It’s not just the speed, it’s an amazing site all around; they know their customers and cut out all the fluff.
Even more amazing is that it has always been that good, since 20 years ago at least.
> Having your app burn battery for half a second doing absolutely nothing is bad UX. That kind of latency does have a meaningful effect on productivity for a heavy user.
The implication is that React Native is to blame for this and I'm not sure that's true. What would the ms delay be with pure native? I have plenty of native apps that also have delays from time to time.
It all depends on whether the number includes network roundtrip or not, which they don't state. I read it as not including a network request, i.e. all CPU and local I/O.
The article they link to about how they optimized talks about caching network calls as part of their strategy to get below 500ms, so I would assume network calls are included in the number.
React Native is just a tool, this is Shopify's fault
Replying to myself for clarification: I did not read their 500ms number as including waiting for a network. It sounded like that's how long it was taking React Native to load local data and draw the screen. If that's not the case, it's a very different story.
From another comment by seemack (https://news.ycombinator.com/item?id=42730348):
> For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful.
author here - the stated screen load time includes server round-trip, parsing, layout, formatting, and rendering.
In that case, I apologize for misunderstanding, and would edit my original comment if I could.
Indeed. The games industry uses immediate mode GUIs and people get upset if they achieve less than 60fps. Having everything be this slow is just a huge failure of coordination on behalf of the industry.
(next mini question: why is it seemingly impossible to make an Android app smaller than 60mb? I'm sure it is possible, but almost all the ones I have from the app store are that size)
Can't speak for every app but I've worked on several through the years, a sizeable chunk of all the apps I've worked on were assets. It's possible to hide a lot of it from the app store size if you really wanted to but you'd end up downloading all the assets at some point anyway so there's really no point in putting the extra engineering effort in just to make your app store number look smaller.
This obviously isn't the case for every app and most of the ones I've worked on had a lot of bloat/crap in them as well.
Make a single example of an app that from when I click to the opening takes less than that.
I've just tried whatsapp, notes, gallery, settings and discord out of curiosity, none did and I have a very fast phone.
It sounds like you're referring to app-launch time, which is different from screen-load time. Very different things!
Check out Avalonia [0]
It's a cross-platform spiritual successor of WPF and it kicks ass! You get proper separation of models and views, you can separate what controls there are from how they look (themes/styles), you can build the entire thing into a native compiled application with very reasonable speed and memory use.
[0] https://avaloniaui.net
> I just hope that people choose targets closer to 100ms.
Why? If it's about the phone burning battery for 500ms, it probably isn't doing that - it's just waiting for data to arrive. And even when it's rendering, it's probably not burning battery like say Uber (with which you can feel the battery melt in your hands).
But that's not why I am commenting. I am writing because so many commentors are saying that 500ms is bad. Why is 500ms bad, as long as the UI is not freezing or blanking out?
Why not lower expectations, and wait for half a second? Of course, there are apps for which 500ms is unacceptable - but this doesn't seem to be one of them.
Subjectively, I find the Shop app to be quite nice and speedy. It works well enough that I’d never have guessed it is using any kind of cross platform framework.
It’s easy to get caught up on numbers, but at the end of the day the user experience is all that matters. And I very much doubt that performance is a concern for their users.
Exactly. Tech people almost always go to the "performance wormhole" arguing about ms and how it could be improved 10x - myself included. But working at a startup the past couple of years, I came to the conclusion that it does not matter to the end users at all. If an app is "nice" and "speedy" as you say, that’s enough. Shopify made a good decision and tradeoffs; it works for them, and I would argue it would work for 90% of other companies as well. You don't really need a native app for most purposes; React Native and Flutter are good enough.
Assuming the 500ms is mostly delay for fetching data over a socket, unless the code is really broken that should not really be burning battery. <500ms for display of non-trivial network-fetched data is great regardless of whether it's rendered by react native or is a fully native app. They would both be I/O-bound on the network primarily, with a small but insignificant compute overhead for RN. If the data needs lots of transformation (though not compute-intensive transformation like calculating hashes or somethign) upon returning that could make a difference, though again I'd be surprised if CPU for RN vs native was all that different.
As an Elixir dev who aims for and routinely achieves <10ms response times, (and sometimes < 1 ms for frequent endpoints that I can hand optimize into a single efficient SQL query, which Ecto makes easy I might add!) I find the response time to be the more egregious part :-D
> Having your app burn battery for half a second doing absolutely nothing is bad UX.
Why are you assuming the app is either burning much battery or even doing more than waiting on current data from the server? For an app that I would assume isn't much use without up-to-date data from the server?
I thought the section on the importance of native devs and how they're staffing mobile was really interesting:
"Native devs are crucial
Mobile engineers who specialize in iOS and Android are essential to building great mobile apps. There is no replacing experience and taste that comes from having built many mobile products and deeply understanding conventions and usability. Being able to drop down to the platform layer, write bindings, master build & release, distribution, etc requires native expertise.
They also play a vital role in optimizing app performance across the myriad of device models, ensuring a consistent user experience for all users. Additionally, native expertise is essential for managing React Native version updates, as well as adopting new features, APIs, and tooling changes that accompany new iOS and Android releases. You can't build a good product without these experts.
We invested in training our native mobile developers in React Native through a self-serve course that covered everything they needed to know to ship production-ready code. Additionally, we set up office hours with developers who were already proficient in React Native to provide support through Q&A sessions, pair programming, and code reviews.
We also supplemented our mobile teams with some web developers for their Javascript, Typescript, and React expertise. This ensured we had strong expertise in both native and React Native, and over time, it levelled up the entire team.
Having a good mix of native and web developers is the key to building great mobile apps using React Native in our experience. "
Probably the first "we adopted x" blog post that I can find relatable and spot-on.
I think it's one of the big misconceptions that React Native is _the_ path to get your web devs or even existing code onto mobiles. That's how you get the criticism that RN builds bad, mouldy apps.
Between our clients that have had this issue with quality and shops in the same space as us that haven't (one who boasts a review on one of their apps being "an example on how to build a proper fully native app"), having a good portion of native devs on the team is a big differentiator. Unfortunately this means a RN Team isn't as cheap as some hope.
I was listening to a podcast around 2017 (?) with AirBnb (?) devs when they were using RN and I remember they said “RN is a tool for mobile devs to not write the same app twice, not a shortcut for web devs to not learn native”.
Airbnb gave up on React Native just after that and wrote a series of articles about their experience:
— https://medium.com/airbnb-engineering/sunsetting-react-nativ...
As someone who works with React Native this is definitely true. Imagine a venn diagram:
Full Navive: 2 very big bubbles
React Native: 2 small bubbles and one big bubble
It doesn't happen very often but it can be quite annoying to implement features that need native controls on both platforms. In my case I only know native android (no ios) so when implementing native things I need to bring in an ios native dev and agree on the communication API and any platform-specific edge case before implementing stuff.
It is a lot easier when I can do it all by myself and it is even harder for team members who have no native experience at all.
[dead]
Blazing fast is a bold claim. I use this app nearly every day on a brand new Pixel 9 Pro and, while much improved from a few years ago, it is far from "blazing fast".
For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful. UX studies indicate 0.1s as a number where an application no longer feels instantaneous. (https://www.nngroup.com/articles/response-times-3-important-...)
Contrast this against something like the Slack app where the screen is navigating even before the pressed animation has appeared. Or for an app with probably not as much engineering focus, Fastmail, which begins the screen transition within 100ms of the pressed animation state appearance.
I wonder a little bit why this is slower on Android than iOS. On iOS I've never experienced this, and my phone is a couple years old now.
Not saying I have the answer, but it is a curiosity
It's a good question! I've been hearing the joke for years that RN architects don't have any android devices to test on.
On our apps we consistently see a p50 3-4x speed difference between iOS and Android (though there are more lower end android devices). Hard to fathom if it's all due to variability in android devices vs RN being less performant on Android.
Developing for Apple can be a PITA with their strict background processing rules, apps just terminate/stop working unless they fall under a special case. I get it but yeah.
edit: by terminate I don't mean crash, it just stops code execution an example is an active socket connection getting disconnected unless it's doing something like streaming audio
But as a user I appreciate the strictness much more. I don't have to worry about closing background apps or having a bunch of crap running when I'm not actively using it. The OS (mostly) handles that for me, as it should.
Absolutely. I’d rather have backgrounded apps unexpectedly closed from time to time than to find a big chunk of battery gone at a bad time because some app I don’t even care about has decided it needs to keep running and eating resources for some reason.
I'm surprised that there was no mention of Expo. In the past, I would say bare-metal is better than Expo-managed React Native projects because of the limitations when it came to native modules. Fast forward to today, and anything you can do in a bare metal RN app can be done with Expo.
The biggest game-changer recently is Expo's Continuous Native Generation[0]. You can configure all of your native modules and ios/android files with a simple config file (which has its limits, whereby you'll need to write an Expo Config Plugin[1]). You will no longer commit the ios/android native code to your repository, and instead let it be procedurally built.
This resolved a lot of environment issues developers would often run into, and greatly simplified onboarding new devs. You can build your iOS/Android apps through the CI with ease. And you'll no longer be afraid of upgrading React Native, as Expo will handle all of the breaking changes in the native code for you.
My guess is that Shopify started with bare metal React Native apps (which I would have done the same 5 years ago), and now migrating back to Expo-managed projects is nontrivial. At my work we only manage one app, and it was well worth migrating back.
[0] https://docs.expo.dev/workflow/continuous-native-generation/
[1] https://docs.expo.dev/config-plugins/introduction/
What are your thoughts on Flutter vs Expo vs React Native for someone that wants to build a native app for fun?
React Native renders actual native widgets to the screen, so for example on iOS you would write to cross-platform abstractions but you’d still get real UIKit components on the screen.
Flutter draws its own components that can look superficially like the target platform (or not, it’s up to the developer) in a manner closer to a game engine. HN seems to love Flutter and apparently the developer experience is excellent, but as a user I find Flutter apps to be in general a poor experience. They rarely look or act quite right (assuming the developers even try; I’ve used a number that look like someone has transplanted an Android app onto iOS).
This is fascinating how does Flutter try to make up for the performace hit that comes with adding a layer of abstraction?
My thought is that Expo prioritises web compatibility too much to the point that it leans into conventions with things like navigation that are web-oriented and these contribute towards an app not feeling like a native app.
None of those will get you a "native" app, but they might get you most of the way to a cross-platform app.
fair point but coin toss it is what I'm getting they are all equally good/bad?
Flutter has THE best dev experience out of all platforms, including native. Hands down, Dart tooling + Flutter tooling are just on another level.
Agreed, I know people get incredibly pissy at Google on this site but Flutter is hands down the best app development experience period in 2025.
> Expo vs React Native
Expo is React Native with some nice things sprinkled on top. I'd go with Expo.
why Expo over Flutter? do React Native and Expo provide better abstractions over the Java/ObjC native APIs? again I've never done native dev just curious sorry if this isnt HN worthy comment
The tooling for Flutter is better, but Expo brings React Native much closer.
I fend that React Native app "feel" more native because they're actually using native components, but controlled via a JS runtime. Flutter on the other hand mostly renders to a canvas and re-implements native controls (although it can also wrap native components like RN does).
This leads to there being less of an "uncanny valley" in React Native apps compared to flutter. It also means that all the little details from the system (the text selecting and editing interactions in text inputs being a major one) are idential to native apps when using React Native, because it IS the native component.
The downside to this is that you need to consider platform differences more with React Native, which is one of the things which leads to developers without mobile experience having issues with it.
As the article says, you get the most out of React Native if you're a mobile developer, or at least have someone on the team who is. You can't abstract away all the details of a mobile platform without some tradeoffs.
Not apples comparison imho. Flutter requires using a new fringe language and while it might be a very nice language it's a heavy lift in most businesses contexts to march off into a new language just to use a mobile framework.
So, the main reason for Expo (there are others) is: get to write in the language most developers already know.
> Our apps are blazing fast (<500ms screen loads)
I’m not sure I would consider 0.5 seconds to be blazing fast.
I wish the article went into detail on what these screens do and what a screen load means exactly.
You'd hope they benchmarked the old native iOS app and the RN app.
Since the blog post doesn't mention previous native-only perf, I'd assume they didn't compare or the RN version isn't close to native-only perf (leaning heavily towards the second reason).
Looking at a previous blog post, the first hunch seems to be correct - the second may also be true.
From 2024 March, https://shopify.engineering/improving-shopify-app-s-performa... talks about how their RN-ified app was loading screens in 1400ms (P75) and the steps they took to reduce that to 500ms.
I hope they benchmark their load-screen time with every release/CD to stay on top of any regressions, otherwise, there'll be more mad scrambles when the perf debt piles up too high.
Right after that, they have three links (one blog post, two videos) to explanations of how they optimized screen load speed that can answer that question.
It's a mix of layout stuff (like using lazy list views to avoid below the fold rendering) and network fetches (they talk about using better caching).
That was my initial thought as well. Anyone know what native screen loads typically are? I’m sure it varies wildly between apps, but 500ms seems like it would be on the slower end of a “fast” app.
It really depends on what a "screen load" means exactly. If its just rendering the screen from some client-side data then I would expect something <16ms. To support 120fps displays, it would need to be <8ms.
If a "screen load" includes making a network request to fetch data, then this is a very weird metric to include in a post about React Native. Most of that time budget should just be waiting for the request to complete. Just as before, it should take <16ms to render the screen once the data arrives.
> Anyone know what native screen loads typically are?
500ms sounds about right for a cold launch but otherwise is pretty poor.
50-100ms for "minor" screen changes and 100-200ms for "major" ones are otherwise reasonable for native screens.
For typical apps, the four variables here are backend latency, network latency, client-side deserialization, and client GUI rendering. (Less commonly, apps which have complex client-side state will also spend time reconciling server and client state.)
Keeping UI rendering under 16ms is the gold standard for native apps. That leaves only deserialization as the other target which the mobile developer can optimize. However, the typical solution there involves convincing the backend to ship a different format (i.e. switching from JSON to binary PList or to SQLite DB file).
> Keeping UI rendering under 16ms is the gold standard for native apps.
No, it isn't.
If you're not including the actual rendering, so the actual code of the app only or at least only the code on the UI thread, the targets are much smaller. More like 3-6ms/frame.
If you're including rendering then pipelining and 90hz+ being common still changes that anyway.
> Keeping UI rendering under 16ms is the gold standard for native apps.
Not since they’ve started releasing 120hz screens.
For reference, our app is 100% in Jetpack Compose, our screen rendering for both cold and warm are in the average of ~460-480ms. App start is around ~480ms.
If your warm and cold starts are that close I'take a closer look at your measurement methodology. Could be your cold starts are actually warm, or your timing is starting late.
This strikes me as curiously defensive, in that Canadian way of praising things that are obviously problematic to draw attention to them.
The wider noise around React Native is seemingly that it works, especially while iterating on things, but it makes the final 20% of work much harder than it already was. As one person put it to me recently “with RN you just have to face the fact you won’t be winning any design awards”.
What really amazes me is how far React Native and web React have separated, to the point using the web one is a complete non event.
I just kinda looked around the Shopify app to get a feel for it. There are a few frameworks that tap into native view switching (transitioning between pages and tabs), which creates most of the native feeling (along with native view components like lists/menus/switches).
I don’t know why the quality of the app feels cheap, but it just feels so (the web views load in with zero ease, they just jank onto the screen. So while you have native screen transitioning, you still have this low quality feeling of a bad nypost article shitting out an ad popup on you. Hard to explain, but that’s my my general feeling).
Regardless, while not impressive, it’s in this non-impressiveness that informs my unwillingness to invest into native or something like Flutter. These apps are too simple to go through the hoops.
Shopify RN app is a good example of a mundane non-sexy tech decision.
Overall nothing beats CSS and JavaScript for UI, but even in 2025 we cannot reliably push 60fps.
I disagree with you on a few specifics, but I think the more general question does become what should the Shopify app be like? Non sexy is, as you say, probably the right call.
For mobile apps generally I cannot recall the last time I was actually impressed by one. The reverse is often true, such as with Sonos. Individual features (again Sonos, the calibration it can do) can be neat but experiences as a whole have gone off a cliff, React Native or not.
Flutter does 120fps no problems and has for some time now. Its also a lot nicer to work with Dart than Typescript.
Entirely subjective and I would disagree with dart. JSX is one of the most important things react ever popularised in the frontend space.
What do you find attractive WRT JSX versus other templating syntax?
I suspect you maybe haven’t used Dart then because it’s genuinely not even close. I know in a philosophical sense everything is subjective when you squint hard enough but I’m also talking about very clear and concrete things.
Just to give one simple example. Take the concept of a mixin where you want to essentially create a partial class interface and use it for basic composition. An incredibly straightforward 101 level OOP concept.
Then take a look at how it works in Typescript here:
https://www.typescriptlang.org/docs/handbook/mixins.html
and contrast that with how you do the same thing in Dart here:
https://dart.dev/language/mixins
I’ve got extensive experience with both. I promise you Dart is much much much nicer to work with on every relevant metric I can think of.
Perfect world:
JS and CSS compile to native, somehow.
My ability to do this
function App() () { const items = get(url); render(items) }
Does not exist on native. It's 2025. Why is this?
----
It's because we don't have literate programmers. They don't know how to speak CLEARLY.
>It's because we don't have literate programmers. They don't know how to speak CLEARLY.
Mate, I think this is a bit of a reach.
It's a vent. I don't like writing comprehensive code for simple things. Philosophically, I believe code is a liability. Each line is a problem.
The article alludes to something people do. They wrote a whole lot of code to not write a whole lot of code. These are deep stories.
Glad they spent some times discussing the downsides. I’m 4 months in to a Hotwire Native replacement for an unmaintained React Native app. The differences are stark and I could definitely see myself picking up Hotwire again for another project if given the same constraints, but I’ve had good experiences with React Native in the past too. Ultimately though I just do not like all the work that has to go into maintaining a large scale React codebase.
Curious what you meant by the last sentence there. Does React uniquely complicate maintenance as a codebase grows?
Theres a constant churn of a bunch of dependencies. Devs add minuscule libraries all the time. And I think some of the best React libraries have been abandoned, which is kinda sad, but nice from a maintenance perspective.
React very much feels like programming using only side-effects and that’s not really a fun experience IMHO. Performance issues are also somewhat difficult to spot in review and not very elegant to solve.
It’s been a few years since I’ve used React Native so maybe things are better now?
This is my experience with all javascript stuff these days. If you leave the codebase even for a few months now you're spending days updating it to all the new breaking library changes. Worse, if your tooling is out of date you're probably spending a week just fighting to fix/change/update the tooling. It's the most brittle tech stack I've ever had to work with.
This is the missing criteria in the technical decision making, IMO. How reliant is the team on the recruiting/retention of the current size and structure of the talent, both on the team and in the wider community?
Small teams trying to keep burn ultra low vs. giant companies might have similar technical goals but opposite staff capabilities. This is a crucial factor.
A second-order effect is how much time/energy/money you have to throw at maintenance. Can you afford to spend X% of your time on maintenance? Which technologies offer comparative advantages on maintenance cost? These are surprisingly often easy to answer, and nearly never explicitly considered!
> These are surprisingly often easy to answer
I agree that maintenance costs are often overlooked/ignored, but I'm curious how you get answers on the costs. I've never found it particularly easy to get reliable information on maintenance costs.
I guess what I was thinking was: even if you can't quantify it, you can squint at the comparative advantages and trade-offs and make a qualitative, yet objective judgement call.
I just write everything from scratch. This seems like a lot of work but it allows me to focus on other things that usually have no deadlines.
Im dense enough to delete things and rewrite if they require babysitting.
Im sorry but I was never able to relate to this problem. All core libraries of javascript are atleast a decade old at this point and that too without any major breaking changes.
Express is almost decade old, react is more than a decade old, redux is almost a decade old, Tailwind is the only new thing but that too is almost half a decade old.
Can you share your package.json?
"React very much feels like programming using only side-effects" this absolutely nails it.
This is essentially how DOM manipulation works, which is JS' main use case.
You’re never telling React “do this”, instead it’s always “change this state” and then hope that it does what you expect it to do, but instead it re-renders 10 components for nonobvious reasons. Sure useMemo can help with this, but, eh, I just wish it worked the first way.
And every React-adjacent project either ends up abandoned or subsumed into the beast.
After having used Ember for several years I find it very sad they didn't develop a "mobile" offering, the dev experience is fastly superior (especially as it relates to state handling).
Hooks are a bit of a cancer, they leak absolutely everywhere on top of making it quite difficult to reason about re-renders.
> React very much feels like programming using only side-effects and that’s not really a fun experience IMHO.
This is interesting and I like the way you've phrased it. Are you talking about React Native, or React in general? And do you use hooks?
I like React on the web, but only when using hooks and only because I haven't found anything that I like more than it. I still find it tedious and overly hook-y¹. It also gives a lot of wiggle room for devs to shoot themselves in the foot with useEffect, like some of my previous clients have done.
¹ Hold on, I gotta pull in 18 hooks from across my project, npm dependencies and react itself before I can write the jsx in what would otherwise be a 10-15 line fooButton function.
> I like React on the web, but only when using hooks and only because I haven't found anything that I like more than it.
After being thrown into the Angular woods for a while I found that what I really wanted was just a "React with RxJS Observables that look like writing Hooks if you squint, but don't have some of the complex rules either" and then I realized that I was basically trying to reinvent some of Knockout, but with TSX templates. I'm still amazed by how much I was able to accomplish from that idea, including some of the "advanced" features of modern React, in a relatively small package (modulo the one and only one dependency on RxJS).
I don't know how many other developers want the same thing.
(I know some find RxJS overly complex, which is exactly why Angular is as awful to work in as it is, both in how it badly uses RxJS (and teaches bad habits) and how there's generally three ways to do everything, one with RxJS and two others avoiding it or misusing it, with now a fourth way of Signals which are just RxJS-lite with Knockout-style `computed`, proving time is a flat circle and Angular remains a design-by-committee mishmash of too many things that don't interoperate well. I think learning Angular's mishmash is far worse than just learning RxJS well, but I also spent a lot of time doing Rx in C# and in CycleJS for a while, too.)
https://vuejs.org/guide/extras/render-function.html#jsx-tsx
React's reactivity model is "inverted" from almost every other model out there. Vue, to me, feels the most like Knockout. I also find that I rarely run into edge cases compared to React and Vue feels the most like OG HTML.
I did investigate Vue with TSX at one point. It wasn't for me, but I did like Vue with TSX over Vue's primary template language.
A part of the way I see it is that Knockout promised "Observables" and `computed` was sort of the distracting fork away from something like RxJS Observables. Now that fork seems to be named "Signals". I'm not a fan of "Signals" and think they miss a lot of the power and elegance of "real" Observables like RxJS. I understand the appeal of the "magic" of `computed` tools. I better appreciate the power of the larger toolbox of RxJS operators. (I also think Observables are a lot easier to unit test than `computed`. A good "marble test" is a thing of beauty.)
For what it is worth, my RxJS-based solution: https://github.com/WorldMaker/butterfloat
Yea precisely. Hooks themselves are OK, it’s just plain ole code reuse, necessary the language itself makes that somewhat difficult. But then you’re not programming JS anymore — you’re wed to React and nothing else. I hate how it takes over codebases.
Any idea on whether this is a result of just npm/js ecosystem? Or just native frameworks in general?
Trying to figure out if Flutter or RN would be best use of what little time I have left on this planet
We maintain a few number of projects for clients - the apps are feature complete and will not change much in the next years. The goal here is to spend not much money on the apps but to keep them functional in the appstore. RN is somewhat cheaper up fron than native development or say flutter. Unfortunately, maintenance cost is high and difficult to predict. Why? Appstores are adding new requirements and increase API-level all the time. Support for that is often baked into new RN versions. Unfortunately, new RN versions often break things, which break libraries in turn. So you need to upgrade this morass and if you are unlucky, you need to redevelop huge swaths of your app because the lib now is deprecated /works differently / will never be updated to the new RN version.
Also true for any large JS/TS application, in my experience. It's an emergent property of a developer culture that places no value on backwards compatibility.
I was glad to see the discussion as well but it feels like the downsides were also very understated. Working on an RN app as a native dev requires a lot of cross-domain knowledge that isn't typical for a native dev.
Is there any benchmark about Hotwire Native screen response time?
Great to see Hotwire Native here! I was asking myself would it be easier for Shopify to steer back more towards Rails ecosystem technologies. They went React / JavaScript full-throttle. JavaScript ecosystem seems so immature, and changing constantly with a huge maintenance burden. Rails feels really stable and Hotwire, although it's changing, feels stable. Stimulus was announced in 2018 I believe and they didn't have a single paradigm shift comparable to React's hooks, server components, etc.
So basically, as long as you are large enough to have direct contact with the upstream team, have a separate team to manage React Native itself, and have two separate teams for iOS and Android to manage stuff that needs native access, you are good.
> We care very deeply about performance at Shopify
> We’ve achieved sub-500ms (P75) screen loads in the Shopify app
Pick 1.
Also interesting that this deep care about performance extends to blogs, where a simple animated image showing how awesome hot reload is causing a noticeable delay in scrolling
The quality standards are so low… half a second to switch screens is ok? Jesus!
Apple just keeps making billions and billions by focusing on UX, when other ”tech” companies are satisfied with this garbage.
> The quality standards are so low…
Every so often they write an article talking about how great their several-years-long effort to switch to React Native is going, and every time I read it and come away with an even more negative opinion of React Native.
https://news.ycombinator.com/item?id=34263896
https://www.reddit.com/r/swift/comments/1bxogd1/have_you_con...
I've learned not to trust company technical blogs. They're all just marketing fluff intended to act as recruiting materials, and judging by the comments here, it's working. As your post highlights, taken in the greater context, it sounds like their decision to move to React Native was so slow going and the end-user experience is just okay.
I suppose taken from the perspective of "We want to easily hire frontend devs that can easily be slotted in to work on the project and make impact on all platforms, including mobile" then it's a win, but at a cost in years and a degraded user experience. From a business perspective, probably a good move in the long run.
I was just showing my team this article. We'd start getting warning alerts if our P75 page load times reached 500ms. I wonder if we're measuring load times differently.
It's also their P75 target load time.
Agreed. The web driven enshittification of everything continues. It doesn't have to be this way. It really doesn't.
If what you're using makes it this way, maybe stop using it? Stop drinking the kool-aid, get over your sunk cost fallacy and start thinking about what your end user experience should be, and work backwards from there, making decisions that guarantee you hit it. Don't choose the language or tool first and leave yourself constrained to only what is possible in it.
The sunk cost fallacy in this case would've prevented the switch from native. And what's worse is they've thought about user experience, "just" set the bar for it too low
Heh. Still no dark mode, it's almost as embarrassing as HN not having a dark mode -- yeah I said it.
https://news.ycombinator.com/item?id=34263628
Will another 10 years go by and there still won't be a dark mode for the app?
As someone who uses the mobile app basically every day, it is absolutely one of the things that bothers me, every single time I use it. That's not a good thing.
It's constantly surprising to me that this one aspect of software appearance is a hill that the industry has collectively decided to die on.
We can't agree to use colours that are unambiguous for colourblind folks, we can't agree to use sufficient contrast in our UIs, we can't agree to use big enough touch targets, most companies are truly awful at accessibility... and yet everyone wants dark mode, and most companies implement it. How much time have we lost as an industry making interfaces harder to read?
Dark mode is an accessibility feature for myself, and many others I would imagine.
Calling it dark mode might not be ideal though. We should probably call it something like system theme awareness, or anything that doesn’t make the reader to think “gee, that’s not the theme I like.”
Prefers-color-scheme exists. It’s not that hard.
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
Before installing Noir on iOS, I always appreciated opening HN, or any website without dark mode, and feeling my eyes melting even on lowest brightness setting. Great and easy to read! Thanks for keeping my eyes I check!
By the way, is it Shopify’s open source policy to ignore outside PRs, or are they simply understaffed? My PR which addresses a major issue in one of Shopify’s big React Native libraries has received zero acknowledgement from Shopify for almost a year.
There’s no policy. The person or team owning an open source repo does what they want.
Some are very closely watched, some were mostly just meant as extraction and not really expecting outside contributions.
What would be amazing is if Swift and/or Kotlin could just be the 'native' language across both platforms and work at native speeds on both platforms.
I have not dived deep into it, but that seems to be the purpose of kotlin multiplatform https://www.jetbrains.com/kotlin-multiplatform/
https://skip.tools/ Swift can be!
Saw this the other day and looks interesting
Looks interesting! Thanks for the link.
Not sure I agree with this though:
> first-class development environment (Xcode)
World of subpar development experience. Truly amazing!
Shitty native toolchains that constantly need to be updated (looking at you, Xcode), dumpster fire IDEs (both Android Studio, still don’t understand how Google managed to butcher IntelliJ like that, and Xcode), half completed libraries that are either deprecated or in alpha and, for some reason, in need of constant changes. Compile times in double digits for large projects. Stay up to date with shitty Gradle if you want to have semi sane development experience on Android (maybe they’ll finally roll out declarative version this year, but they said they’re still committed to original DSLs, so good luck to poor sob who will encounter mix of Groovy and Kotlin DSL). Wonderful world of single vendor languages where only interests of vendor dictate how language evolves (just how much resources and time were wasted on horrible KMP, because JetBrains wants to grab mobile market fully).
Let’s gooo!
I agree Xcode might be one of the worst IDEs I have ever used but at basically every company I've worked for the update cycle was maybe once or twice a year and for the most part was painless. There's been maybe one or two upgrades of Xcode in my ~13 year career that were a headache.
I have no idea what libraries you're talking about but you don't really need to use any third party libraries to build a good iOS app. Unless you're doing something incredibly obscure most of the big/popular ones are very well maintained.
Android no longer has anything as part of standard SDK, everything is done as Androidx libraries.
Has anyone had a success with using "React Native for Web" for a Web-first consumer site (for desktop and mobile, including heavy plain text entry at times), but also being able to use the same React Native code to go to the iOS and Android app stores (when you reluctantly also satisfy those consumers who really-really want to install native apps)?
Bluesky. They use Expo on top of React Native, use React Native for Web (with a desktop and mobile), and for mobile native apps.
Let's note that because the clients are fully open-source and on GitHub, people from Expo and React Native are helping the little team behind the clients improve performance over time: it's not their final form!
Uniswap does this successfully. They share quite a lot of code between web and native, and their apps are open source. I made Tamagui, the library they use for sharing UI code, which goes much further than RNW in making this possible.
There's also the question of the amount of footgun you give to developers. While iOS is more performant than Android, Google gives Android developers much more guidance in best practices and patterns that help developers avoid issues around architecture, injection, state and threading.
I've seen many iOS projects overwhelmed by tech debt while its Android counterpart was still OK-ish. I don't believe this is coincidence.
So how hard is it to apply React Native the correct way? Having a dedicated team of dozens of engineers including native experts for each platform is different than your average 4-8 people dev (web, API, iOS, Android) team. Let alone if you only have people experienced in web doing the work.
When I build Swift applications the fact they have sub 500ms loads is not an achievement, they're simply already doing that without me trying. But I have found the right way to build iOS apps myself over the years, very little help from Apple.
>>React is legacy technology
https://infrequently.org/2024/11/if-not-react-then-what/#fn-...
Thanks, I’ve been thinking about ditching react in favor of Svelte for a long time now, and this post cites enough reasons to justify it
I started with Svelte but ecosystem that React has is giant. Plus React Compiler is already being used in Instagram and Facebook so within this year, the virtual dom diffing would be a thing of past.
The virtual dom is just part of the performance problem, the biggest problem in my opinion is the huge complexity that React adds, they solved part of it with useReducer and useSyncExternalStore, but I don’t think it will eventually be solved.
I really wanted to work with native SwiftUI, but the lack of hot reload and long waiting times for the preview to refreshes is just painful. React Native on the contrary, delivers good enough live feedback experience. I don’t enjoy React, but compared to waiting 10 seconds for preview changes and occasional “expressions too complex, break it down to smaller one” - I’d choose React. I do still trying to code natively on every XCode updates; just with the hope of it getting better somehow.
> We’ve achieved sub-500ms (P75) screen loads
That's a difficult to interpret metric. If it's only being met 75% of the time, I'd tend to assume most features are much better than that, but some are never meeting the target, and there's no indication by how much.
I’ve noticed the app has gotten a lot slower and buggier on iOS in the last few years. Kind of wondered what they were writing it with.
I really think aside from games, media editing, and other such heavy activities, 90% of apps are, or should be, web views. What they are doing makes a lot of sense.
Which tools do they use to measure performance?
> Our apps are blazing fast (<500ms screen loads)
Hahaha we are absolutely cooked.
Load times I would've considered unsatisfactory in 2010 are "blazing fast" in 2025.
literally b/c the thermal effect on our phones?
Not sure at shopify size, but I highly encourage startups to use cross platform for mobile distribution. React native's OTA update alone is already worth for fast movers.
Two words: Hotwire Native
I'll look this up later tonight. Is Hotwire using the same approach as Capacitor / Ionic?
Cannot recommend RN enough. One code base gives you three apps. Web, Android and iOS. With NativeWind, you have full Tailwind available to you and I had great success to the point where I have been thinking that I should be building customer facing web apps in RN (React Native Web + Tailwind) which at any time can be exported as native apps while already being a great web app.
They could have written a MacOS and Windows app to go along with their web app with React Native but didn't. Such a missed opportunity
Had high hopes for Shopify at beginning of pandemic but it was all hype. Online shopping is still pretty much the same and in some ways regressed.
Why is the Slashdot logo on this article? I'm so confused. What's the relationship between Shopify and Slashdot?
That's Shopify Balance, which also has a /. logo for some reason. No relation to Slashdot.
Ah, thanks! It's wild that they picked the same logo and the same color!
Oh it's meant to be a balance board / seesaw. Duh.
Personally I miss the old QT interface with plugins capabilities
> Our apps are blazing fast (<500ms screen loads)
I frequently encounter Shopify e-commerce in the wild, and it’s my most disliked experience. From browsing the stores to checkout, it always feels clunky.
I always shrugged it off as iOS bullshit but now I know the real reason. It’s just slow enough to make you doubt yourself - it’s not the website, it’s probably my shitty {phone|poor internet|computer}
[dead]
So many of you are yapping about how the performance is not good enough. Yet none of you are talking about how Shopify literally could not develop their mobile app without it. The 3 minutes to compile the app just to do a trivial change makes it near impossible for devs to be productive. Hot reloading is what got me hooked to react native, I literally cannot allow for my brain to rot waiting for minutes waiting for Xcode to compile for a simple border radius change.
How did they manage to achieve the literally impossible thing for many years before this transition?
> I literally cannot allow for my brain to rot waiting for minutes waiting for Xcode to compile for a simple border radius change.
You can literally think about/edit other things while your simple border radius is being updated. No rot involved
this is an unserious reply. and if you are serious then you're likely not a frontend developer. often you want to test if a certain kind of hack fix works. your mind becomes glued to thinking about "does that fix it?" - hence why it's not easy to branch into a new line of thought then just come back to the change you pushed minutes ago. You're pretty much suggesting that the developer context changes into another thing for anywhere between 1 and 4 minutes and then context switches back to see if the build worked. The task that you'd be context switching into for 1-4 minutes will be interrupted by another thing and you'll likely make no progress doing it
And yet somehow, devs dealt with this tragedy for decades before us, cranking out software that was 100x smaller and 100x faster. Weird.
In what imaginary world you’re living, where basic Android app or iOS app are 100x smaller and 100x faster than RN?
I was referring to PC programs, long before the term DX had become a thing.