C# engineer's R3F checklist

In C# / MVC you think in requests and views. A user does a thing, the server runs code, the view renders. Discrete, event-driven, stateless between requests.

In R3F you think in frames. The runtime loop runs sixty times a second. Every frame, your code is asked: what does the scene look like now? The state of the scene at frame N+1 depends on the state at frame N. Time is a first-class input.

That swap takes about a month to feel natural. Until it does, R3F tutorials feel like they're skipping steps because they're operating in a paradigm you haven't internalized yet.

The bridge that helps: React is already a state-of-the-UI-at-this-moment system. The bit that's different in R3F is that the moments come 60 times a second instead of in response to user events. Same react principles; tighter clock.

A few fears that made R3F feel inaccessible to me, that aren't actually obstacles:

"You need to know GLSL." You don't, for a long time. Drei (the R3F helper library) abstracts the shader-level work for 90% of common cases. You can ship a complete portfolio R3F surface without writing a single line of GLSL.

"You need to know matrices." You don't. R3F's component API hides the matrix math behind props (position, rotation, scale). The matrix layer becomes useful only when you're doing something custom enough that the prop API doesn't cover it.

"Performance is hard." The default is good enough on modern hardware. R3F's react-reconciler is efficient out of the box. Performance becomes a real concern only at scenes with thousands of meshes or complex shaders. Below that scale, you can ship without thinking about it.

"You need HDR lighting setup." You don't. Drei's <Environment> component takes one prop (preset="city" or similar) and gives you defensible studio lighting. Spend zero hours on lighting until the default is provably wrong for your scene.

The traps that took me real time:

HDRI loading and licensing. The free HDRIs you find on Poly Haven are wonderful and license-cleared. Random HDRIs you find on Google may not be. Check the license before shipping any HDR you didn't generate yourself.

Hovers + raycasting in production. R3F's onPointerOver / onPointerOut events look like React events. They aren't quite. Multi-object hover states, hover hierarchies, and the interaction between R3F hover and DOM hover all have edge cases. Plan for an extra day debugging hover behavior on the second R3F project.

SSR-safe canvas mounting. R3F's <Canvas> doesn't work in SSR. Wrap it in a dynamic import with ssr: false, or use next/dynamic. Forgetting this produces a confusing build error.

Controlling drei OrbitControls vs. your own camera. Drei provides camera controllers that work great until you want custom behavior. The migration from drei controls to a hand-written camera controller is harder than it looks. Decide early which path you want; the cost of switching is real.

Mobile WebGL context limits. A page with multiple R3F canvases will hit WebGL context limits on iOS Safari. Consolidate into a single canvas with multiple scenes, or accept that some pages don't load on iOS.

Before shipping any R3F surface, confirm:

• HDR or environment lighting is preloaded, not requested at first paint
• useFrame callbacks are paused when the canvas is offscreen (intersection observer)
• Canvas is wrapped in dynamic import with ssr: false
• Mobile fallback exists for browsers without WebGL2 support
• Memory cleanup: every loaded geometry, material, and texture is disposed when the component unmounts
• Pointer events are unbound when canvas unmounts
• Reduced-motion preference disables non-essential animation
• HDRI / model assets have valid licenses
• The scene works on a Redmi Note 9 with 2 bars of signal (or whatever your 80th-percentile device is)
• Bundle size impact has been measured (three.js + drei + matter-js + GSAP all together is heavy)

The list is short on purpose. It catches the failure modes I've actually hit in production. Longer lists with theoretical concerns waste time on issues you'd never have shipped.

In the interest of honesty:

• Custom shaders. I've shipped two scenes with light custom GLSL. Anything more ambitious — a real shader-painter project — I'd still need to learn.
• Game-loop architecture. R3F for portfolios and decorative surfaces I'm comfortable with. R3F for a game with collision detection, AI, real input loops — different problem set I haven't built in.
• Multi-canvas orchestration. I've worked around iOS's WebGL context limit by consolidating to single canvases. Whether there's a cleaner way to ship multiple canvases on a single page on iOS, I haven't solved.

The list will get shorter. The point of writing it down is that what I don't know is information for the reader: don't assume the post's author has solved problems past where the post stops.

The path from C# to R3F isn't about the technical skills. It's about paradigm flexibility — the willingness to set aside the request/response model that years of MVC has trained, and operate in a different one for a few months until the new model settles.

Most engineers don't make this transition because the first three weeks feel bad. Tutorials don't land. Code feels wrong. The instinct is to retreat to the familiar paradigm. The trick is committing to the discomfort for a month — long enough for the frame-based model to feel native.

Once it does, R3F isn't harder than MVC. It's just different. And the surfaces it lets you ship — three-dimensional craft work, motion-rich interfaces, the work that makes a portfolio actually stand out — aren't reachable from the MVC paradigm alone.

The cost is a month of feeling stupid. The return is a tool nobody else in your immediate engineering circle has. Whether that trade makes sense for you depends on what kind of surfaces you want to ship.