What we talked about
Cameron Dutro, software engineering technical leader at Cisco Meraki (previously GitHub, Salesforce, Lumos Labs, Twitter):joins us to reflect on Rails’ omakase roots, the trade-offs of JS tool churn, and how shared interfaces make teams faster. With 15+ years in tech and a master’s in CS from Johns Hopkins, Cameron brings a pragmatic lens to frontend choices and when heavy frameworks are truly warranted. Off the clock, he’s with his wife and two daughters in Northern California.
GitHub: https://github.com/camertron
Show notes
Cameron Dutro has spent years inside some of the largest React codebases in existence, at GitHub, Cisco Meraki, and Quip, and his conclusion is that the vast majority of web applications should not be using React at all. His recommended frontend stack is a specific, opinionated set of tools, and React is explicitly absent from it.
What we covered
- Cameron’s central argument: 99% of Rails applications are document-based request-response pages, not interactive applications. Rendering a blog or a typical CRUD app in React is using a framework designed for Figma-level interactivity to solve a problem that static HTML already solves better.
- His recommended stack comes down to five choices: NPM (simpler than yarn or pnpm, good enough), Vite (the single most impactful recommendation, faster, easier, and more turnkey than anything that came before it, including asset pipeline delivery of flat files), PostCSS, TypeScript (with a caveat for small teams where the overhead may not be worth it), and Hotwire/Stimulus.
- He argues against both webpack and import maps. Webpack has introduced years of opaque upgrade pain into Rails apps and he explicitly asked listeners to stop using it. Import maps, while philosophically appealing with Rails’ no-build direction, only work cleanly for about 10% of apps, anything needing TypeScript needs a transpiler and therefore a build step anyway.
- At GitHub’s Primer team, he worked on building complex components like the select panel using Web Components and found that certain high-interactivity components genuinely were harder without React, not because React is better in general, but because some components need the kind of client-side template rendering that Web Components make awkward.
- His forward-looking idea is an islands architecture variant: keep 90% of the page as static HTML and render a single React component only where genuinely needed, rather than letting React take over the whole page. The current barrier is that each React component brings the full React runtime with it, making isolated islands expensive.
- The practical implication he kept returning to: if you are building a React app, separate it from Rails entirely and use Rails as a JSON API backend. That architecture makes sense for complex SPAs. But for most Rails apps, the overhead of a JavaScript framework is a liability, not an asset, every dependency that changes means code you have to touch.
About Cameron
Cameron Dutro is a software engineering technical leader at Cisco Meraki, with previous experience at GitHub, Salesforce, Quip, and Twitter. He has contributed to large-scale Rails and React codebases and has spoken at Rails conferences about frontend architecture and tooling choices.
- LinkedIn: https://www.linkedin.com/in/camerondutro
- Website: https://camerondutro.com
Episode 25 of the PreVetted Podcast.