[HN Gopher] Five years of React Native at Shopify
___________________________________________________________________
Five years of React Native at Shopify
Author : onnnon
Score : 310 points
Date : 2025-01-13 22:08 UTC (4 days ago)
(HTM) web link (shopify.engineering)
(TXT) w3m dump (shopify.engineering)
| nadis wrote:
| 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.
| "
| sdflhasjd wrote:
| 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.
| wiseowise wrote:
| 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".
| JimDabell wrote:
| 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...
| DanielHB wrote:
| 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.
| breckenedge wrote:
| 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.
| mattgreenrocks wrote:
| Curious what you meant by the last sentence there. Does React
| uniquely complicate maintenance as a codebase grows?
| breckenedge wrote:
| 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?
| tensor wrote:
| 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.
| endlessvoid94 wrote:
| 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!
| Calamitous wrote:
| > 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.
| endlessvoid94 wrote:
| 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.
| theendisney wrote:
| 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.
| itsjzt wrote:
| 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?
| nozzlegear wrote:
| > 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-y1. 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.
|
| 1 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.
| breckenedge wrote:
| 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.
| WorldMaker wrote:
| > 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.)
| CharlieDigital wrote:
| > and then I realized that I was basically trying to
| reinvent some of Knockout, but with TSX templates.
|
| You may like Vue with TSX.
|
| 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.
| WorldMaker wrote:
| 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
| gunian wrote:
| 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
| nathanappere wrote:
| "React very much feels like programming using only side-
| effects" this absolutely nails it.
| breckenedge wrote:
| 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.
| nathanappere wrote:
| 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.
| mannyv wrote:
| This is essentially how DOM manipulation works, which is
| JS' main use case.
| HdS84 wrote:
| 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.
| dboreham wrote:
| 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.
| seemack wrote:
| 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.
| Lucasoato wrote:
| Is there any benchmark about Hotwire Native screen response
| time?
| Mystery-Machine wrote:
| 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.
| fidotron wrote:
| 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.
| bloomingkales wrote:
| 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.
| fidotron wrote:
| 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.
| mdhb wrote:
| Flutter does 120fps no problems and has for some time now.
| Its also a lot nicer to work with Dart than Typescript.
| phist_mcgee wrote:
| Entirely subjective and I would disagree with dart. JSX is
| one of the most important things react ever popularised in
| the frontend space.
| bloomingkales wrote:
| 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.
| phist_mcgee wrote:
| >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.
| bloomingkales wrote:
| 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.
| CharlieDigital wrote:
| What do you find attractive WRT JSX versus other
| templating syntax?
| mdhb wrote:
| 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.
| treksis wrote:
| 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.
| zffr wrote:
| > 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.
| canucker2016 wrote:
| 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.
| buzzerbetrayed wrote:
| 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.
| cellularmitosis wrote:
| 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).
| kllrnohj wrote:
| > 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.
| wiseowise wrote:
| > Keeping UI rendering under 16ms is the gold standard for
| native apps.
|
| Not since they've started releasing 120hz screens.
| zffr wrote:
| 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.
| kllrnohj wrote:
| > 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.
| lawgimenez wrote:
| 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.
| charleslmunger wrote:
| 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.
| hombre_fatal wrote:
| 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).
| irskep wrote:
| 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.
| fxtentacle wrote:
| 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.
| fidotron wrote:
| 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.
| x0x0 wrote:
| > 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.
| fidotron wrote:
| 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.
| x0x0 wrote:
| straight off my android phone by disabling wifi then
| moving through my 2 sims
| pinoy420 wrote:
| Don't take the bait. It is a typical hn hyperbole comment
| throw5959 wrote:
| If you have a dual SIM phone, try to swap your SIMs.
| fidotron wrote:
| 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.
| harrall wrote:
| 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.
| gf000 wrote:
| 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.
| fingerlocks wrote:
| 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
| gf000 wrote:
| 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.
| fingerlocks wrote:
| 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.
| fidotron wrote:
| > 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.
| cellularmitosis wrote:
| 100ms to render an iOS screen means dropping 6 frames. That
| would put an applicant in the "no hire" category.
| joaohaas wrote:
| 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.
| andy_ppp wrote:
| 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...
| flohofwoe wrote:
| 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).
| chrisandchris wrote:
| Moorsches Law v2 (/s) states that while computers get
| faster, we add more layers so computers actually get
| slower.
| ezekiel68 wrote:
| Back when "WinTel" was a true duopoly, we used to call
| this "Gates Law".
| flohofwoe wrote:
| "What Andy giveth, Bill taketh away."
| netdevphoenix wrote:
| 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.
| sgarland wrote:
| 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
| netdevphoenix wrote:
| > 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.
| sgarland wrote:
| 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."
| kristiandupont wrote:
| 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.
| flohofwoe wrote:
| 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.
| xmprt wrote:
| > 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.
| gooosle wrote:
| 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.
| bushbaba wrote:
| P75. I can only image the p90 and p99 are upwards of 1
| second.
| akie wrote:
| 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.
| spockz wrote:
| Ah. I see we are spoiled with <4ms queries on our
| database. See, it all depends on perspective and use
| case. :)
| bobnamob wrote:
| > 200ms for round-trip and DB queries is complete bonkers
|
| Never lived in Australia I see
| yxhuvud wrote:
| 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.
| bobnamob wrote:
| 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)
| yxhuvud wrote:
| Probably not, because the if-statement in my post is
| likely false. The Australian user base is likely not high
| enough.
| netdevphoenix wrote:
| 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
| philipwhiuk wrote:
| If the P75 is bad because of Australia that means 25% of
| their customer base is Australian.
| fxtentacle wrote:
| 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.
| sgarland wrote:
| 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.
| e12e wrote:
| 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.
| bluGill wrote:
| 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.
| sgarland wrote:
| > 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.
| reissbaker wrote:
| 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.
| gooosle wrote:
| 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.
| charleslmunger wrote:
| >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.
| sgarland wrote:
| 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.
| ezekiel68 wrote:
| 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.
| sgarland wrote:
| "We're disrupting!"
|
| "Yeah, you're disrupting my sleep by breaking the DB."
| refset wrote:
| > 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!
| sgarland wrote:
| 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.
| refset wrote:
| Explicit query plan pinning helps a lot, alongside strong
| profiling and monitoring tools.
| fxtentacle wrote:
| "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.
| sgarland wrote:
| 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.
| gooosle wrote:
| 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.
| np_tedious wrote:
| What does "DB queries" mean here? The on-device sqlite stuff?
| x0x0 wrote:
| > _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?
| freedomben wrote:
| 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
| epolanski wrote:
| 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.
| irskep wrote:
| It sounds like you're referring to app-launch time, which is
| different from screen-load time. Very different things!
| lelandfe wrote:
| 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...
| pinoy420 wrote:
| 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.
| itishappy wrote:
| Then there's McMaster Carr, which has great service, but
| all anyone seems to want to talk about is how snappy their
| site is!
| lelandfe wrote:
| 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.
| dboreham wrote:
| Even more amazing is that it has always been that good,
| since 20 years ago at least.
| yxhuvud wrote:
| > 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.
| afavour wrote:
| > 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.
| irskep wrote:
| 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.
| lolinder wrote:
| 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.
| ycombinatrix wrote:
| React Native is just a tool, this is Shopify's fault
| irskep wrote:
| 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.
| mustafa01ali wrote:
| author here - the stated screen load time includes server
| round-trip, parsing, layout, formatting, and rendering.
| irskep wrote:
| In that case, I apologize for misunderstanding, and would
| edit my original comment if I could.
| brokencode wrote:
| 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.
| mirzap wrote:
| 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.
| SeptiumMMX wrote:
| 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
| jeswin wrote:
| > 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.
| pjc50 wrote:
| 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)
| tarentel wrote:
| 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.
| tempfile wrote:
| > Our apps are blazing fast (<500ms screen loads)
|
| Hahaha we are absolutely cooked.
| verdverm wrote:
| literally b/c the thermal effect on our phones?
| bigfatkitten wrote:
| Load times I would've considered unsatisfactory in 2010 are
| "blazing fast" in 2025.
| seemack wrote:
| 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.
| no_wizard wrote:
| 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
| seemack wrote:
| 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.
| qt31415926 wrote:
| 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.
| ge96 wrote:
| 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
| bschwindHN wrote:
| 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.
| cosmic_cheese wrote:
| 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.
| humptybumpty wrote:
| 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.
| negative10xer wrote:
| 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.
| gf000 wrote:
| It's also their P75 target load time.
| Twirrim wrote:
| 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.
| eviks wrote:
| 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
| JimDabell wrote:
| > 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...
| allenu wrote:
| 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.
| calvinmorrison wrote:
| Personally I miss the old QT interface with plugins capabilities
| prophesi wrote:
| 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/
| gunian wrote:
| What are your thoughts on Flutter vs Expo vs React Native for
| someone that wants to build a native app for fun?
| EddieRingle wrote:
| None of those will get you a "native" app, but they might get
| you most of the way to a cross-platform app.
| gunian wrote:
| fair point but coin toss it is what I'm getting they are
| all equally good/bad?
| wiseowise wrote:
| Flutter has THE best dev experience out of all platforms,
| including native. Hands down, Dart tooling + Flutter
| tooling are just on another level.
| mdhb wrote:
| 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.
| reddalo wrote:
| > Expo vs React Native
|
| Expo _is_ React Native with some nice things sprinkled on
| top. I 'd go with Expo.
| gunian wrote:
| 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
| oakesm9 wrote:
| 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.
| dboreham wrote:
| 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.
| deergomoo wrote:
| 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).
| sdflhasjd wrote:
| 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.
| methods21 wrote:
| 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.
| te_chris wrote:
| https://skip.tools/ Swift can be!
|
| Saw this the other day and looks interesting
| OccamsMirror wrote:
| Looks interesting! Thanks for the link.
|
| Not sure I agree with this though:
|
| > first-class development environment (Xcode)
| nyantaro1 wrote:
| I have not dived deep into it, but that seems to be the purpose
| of kotlin multiplatform https://www.jetbrains.com/kotlin-
| multiplatform/
| wiseowise wrote:
| 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!
| tarentel wrote:
| 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.
| justinko wrote:
| Two words: Hotwire Native
| grounder wrote:
| I'll look this up later tonight. Is Hotwire using the same
| approach as Capacitor / Ionic?
| hsavit1 wrote:
| 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.
| sgarland wrote:
| And yet somehow, devs dealt with this tragedy for decades
| before us, cranking out software that was 100x smaller and 100x
| faster. Weird.
| wiseowise wrote:
| In what imaginary world you're living, where basic Android
| app or iOS app are 100x smaller and 100x faster than RN?
| sgarland wrote:
| I was referring to PC programs, long before the term DX had
| become a thing.
| eviks wrote:
| 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
| hsavit1 wrote:
| 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
| morelish wrote:
| 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.
| sirjaz wrote:
| 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
| lvl155 wrote:
| 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.
| nitwit005 wrote:
| > 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.
| mcsniff wrote:
| 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.
| danpalmer wrote:
| 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?
| consumer451 wrote:
| 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...
| wiseowise wrote:
| 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!
| assimpleaspossi wrote:
| >>React is legacy technology
|
| https://infrequently.org/2024/11/if-not-react-then-what/#fn-...
| iammrpayments wrote:
| 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
| wg0 wrote:
| 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.
| iammrpayments wrote:
| 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.
| griomnib wrote:
| 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.
| neilv wrote:
| 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)?
| Signez wrote:
| 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!
| nwienert wrote:
| 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.
| echelon wrote:
| Why is the Slashdot logo on this article? I'm so confused. What's
| the relationship between Shopify and Slashdot?
| jsheard wrote:
| That's Shopify Balance, which also has a /. logo for some
| reason. No relation to Slashdot.
| echelon wrote:
| Ah, thanks! It's wild that they picked the same logo and the
| same color!
| jsheard wrote:
| Oh it's meant to be a balance board / seesaw. Duh.
| qazxcvbnm wrote:
| 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.
| byroot wrote:
| 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.
| xyst wrote:
| > 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}
| grandinj wrote:
| 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.
| wg0 wrote:
| 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.
| dep_b wrote:
| 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.
| adityapurwa wrote:
| 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.
| eviks wrote:
| > 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
___________________________________________________________________
(page generated 2025-01-17 23:02 UTC)