Same React, Different Constraints
How performance thinking made me unlearn the browser
I Used to Think Performance Was About Using the Right Layer
Before React Native entered the picture, I already cared a lot about performance — but very much from a web developer’s point of view.
My mental model was straightforward:
- If something can be done in HTML, do it there
- If it’s about presentation, let CSS handle it
- Bring in JavaScript only when the platform genuinely needs help
Not because JavaScript is bad — but because it’s expensive compared to the other two.
Over time, this approach started feeling more natural as the web evolved. Native elements like <dialog> reduced the need for custom modal logic. Popover APIs made common UI patterns simpler. Semantic HTML wasn’t just about accessibility anymore — it was about letting the browser do work it already knows how to do well.
At some point, I realized I wasn’t “optimizing React”.
I was optimizing how much work I was asking the browser to do.
Performance Makes You Aware of the Browser
In my previous role, performance wasn’t optional.
Organic traffic was a major acquisition channel, which meant Core Web Vitals weren’t abstract metrics — they directly affected outcomes. When INP was introduced, the focus shifted from how fast the page loads to how fast it reacts.
That’s when things got interesting.
There wasn’t a playbook. So we profiled. A lot.
- Long tasks
- Layout recalculations
- Event handlers that felt innocent but blocked interactions longer than expected
The more time I spent in the Performance tab, the clearer one thing became:
The browser wasn’t slow.
It was busy.
And often, it was busy because we made it that way.
Performance work slowly stopped being about tricks and started being about restraint — fewer renders, clearer layout intent, less unnecessary coordination between parts of the UI.
At the time, I thought this was just what “good web performance work” looks like.
Then I started working with React Native.
When the Browser Disappears
In January 2025, after joining my current team, I was asked if I could work with React Native.
I hadn’t before — but I said yes.
At first glance, it felt familiar. Hooks, components, state — all the same ideas. But very quickly, something felt different.
Not missing features.
Missing assumptions.
The biggest shift wasn’t learning new APIs — it was realizing how much I had been relying on the browser without noticing.
Because in React Native, that layer simply isn’t there.
- No DOM
- No CSS cascade
- No layout engine quietly compensating for ambiguity
React isn’t running inside an environment anymore.
React is the environment.
Same React, Different Constraints
React Native often gets described as “React for mobile”, which is technically true — but also misleading.
What really changes is the constraint surface.
React Native is React in a layout-first, resource-constrained environment where work is more visible and more costly.
If React Native feels unintuitive at first, it’s rarely because the concepts are unfamiliar. It’s usually because habits formed in a very forgiving runtime don’t translate cleanly.
Once I stopped expecting the platform to smooth things over, React Native started making a lot more sense.
Where Web Intuition Starts to Strain
The web is powerful precisely because it handles an enormous amount of complexity for you.
Browsers have spent decades getting good at:
- Layout
- Reflows and painting
- Accessibility
- Event handling
That’s a feature — but it also means inefficient structures can survive longer than they should.
React Native doesn’t give you that buffer.
Every View maps to native UI.
Every layout pass matters.
Every render shows up somewhere.
That directness is uncomfortable at first — and incredibly clarifying once you adjust.
From Screens to Layout Primitives
One of the most helpful shifts I made was to stop thinking in terms of screens and start thinking in terms of layout primitives.
Instead of asking how something should look on a specific device, I started asking:
- Is this fundamentally a row or a column?
- Where does spacing come from?
- What actually constrains size here?
- What alignment rules are doing the work?
Once those questions are answered clearly, the UI tends to scale naturally — without special cases or device-specific logic.
Sharing Logic Without Forcing UI
Another lesson React Native makes obvious is where sharing stops being helpful.
- Sharing domain logic, state, and behavior across platforms usually pays off
- Sharing rendering abstractions often doesn’t
Hooks travel well. Views don’t always need to.
Duplicating UI code can feel wrong at first, but in many cases it’s the more honest choice — especially when the underlying platforms behave differently.
Performance Stops Being a Cleanup Step
On the web, it’s common to treat performance as something you revisit later.
React Native doesn’t really allow that mindset.
Small decisions — view depth, render frequency, layout clarity — show up quickly. The feedback loop is tighter, and the consequences are harder to ignore.
Over time, that constraint becomes useful. It forces you to be intentional earlier, not reactive later.
The Thread That Connects It All
Looking back, the through-line is pretty clear.
The same thinking that led me to prefer:
- Native browser features over custom JavaScript
- Clear structure over clever abstractions
- Less work over deferred work
Is the same thinking React Native demands by default.
Different platforms.
Different constraints.
Same lesson.
Make the runtime’s job simpler, and the system gets more predictable.
Once that clicked, React Native stopped feeling foreign — and React on the web started feeling sharper.
Key Takeaways
- React Native doesn’t reduce React — it tightens it
- Performance thinking transfers across platforms
- Layout clarity beats visual cleverness
- Constraints aren’t obstacles, they’re signals
