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.
Full transcript
Federico Ramallo (00:01.356) Yes, so we had a little bit of Internet issues, but we’re back.
Cameron (00:06.956) Yes, my home internet connection decided just to stop working. Shout out Comcast.
Federico Ramallo (00:11.192) Yes, it’s part of whole experience of doing podcasting remotely.
Cameron (00:17.262) Yes, although Riverside, which is what we’re using to record, think records on each end locally in your browser, right? So you don’t, there’s not quality issues from the listener’s perspective, right? It’s all just like from our perspective.
Federico Ramallo (00:32.002) Yes, yes, the only thing we need to… I need to remember the guest is to leave the tab open for a little bit so the upload completes, yeah. But other than that, it’s good, yeah. I had to call a few times to a guest that just closed and there was a few seconds left needed to upload, But I think it’s a trade-off worthwhile, yeah.
Cameron (00:38.139) Mm-hmm. Yes, totally. Yeah.
Cameron (00:49.944) Yep, yep, for sure.
Cameron (00:53.922) Yeah, for sure. Yeah, not a bad trade-off at all.
Federico Ramallo (00:58.818) Yes, yes. So we kind of were talking about front ends and I wanted to take the opportunity to wrap it up with what are your recommended front end, I don’t know if it’s to say architecture, but approach tools. What do you think is now the best balance of Omakase and okonomi
Cameron (01:21.976) Yeah.
Cameron (01:26.764) Yes. Yeah, that’s a good question. So I actually, I’m going to open up my presentation because I actually have like a bunch of, except that I don’t have a different computer. Hold on one second.
Federico Ramallo (01:40.704) you
Cameron (01:43.17) my work machine right now.
I think, I mean, can, I can sort of start without having the deck in front of me. the, so the, bunch of like recommendations that I’d made as part of my talk, was like, you know, I said opinions, you know, kind of incoming and,
then proceeded to sort of like list a ton of opinions. And like, I do want to say not all of these are gonna like make sense for everybody, right? I do think like Rails, my big point in the talk was that Rails could probably, you know, do make a lot of these same recommendations because, you know, I think a lot of people would benefit from having a bunch of opinions as, you know, front end opinions built into Rails more so than they have right now.
So let me actually just…
So what I said was like for a better time use NPM. So my argument was that NPM is actually pretty good now. People used yarn I think and PNPM a lot and I think both those tools are also great. NPM is just nice because it’s kind of the OG tool. I find it to be a little simpler than the other two, especially yarn.
Cameron (03:02.381) It’s just a good, it’s just a good tool. used to be terrible and now it’s much better. I just say use, use NPM. I say use a build system. So, you know, even though Rails has kind of promoted this no build concept, I think no build works for like maybe 10 % of the apps out there and the other 90 % are going to need some kind of build system. Like even if you wanted to have some TypeScript in your app, you would need a build system because no browser and no, I think node is getting the ability to.
understand and interpret TypeScript at some point, but that’s not there yet. So even if you wanted to do something as simple as that, you would need a transpiler and therefore a bundler, a build system. I said use Vite. So I really think a lot of the problems that at least I have experienced when it comes to, you know, bundling for the web, you know, which includes a lot of history. like not just bundling via
webpack but also bundling just by delivering jobs to the front end free of static files maybe you know using the asset pipeline like I’ve gone through a lot of different phases you know in my web development career delivering assets to the browser and
You know, I would say none of those have been as easy as Vite. Like even delivering flat files to the browser was actually more complicated than just using Vite because Vite is so fast and so good at what it does. I have just had such a experience with that. And I think like in the, in the deck, I also talk about, show a couple of tweets from Dave Thomas, who was also trying to set up a new app and,
You know, used feed and had a great experience with it. There’s a Vite rails gem that you can just drop into your, your app. you run like a single command, which sets it up for you. And then you just write TypeScript or you write JavaScript and it magically appears in your browser. it’s like, you know, like, like it’s supposed to, and it handles, you know, everything you might want sort of out of the box. Like it’s got TypeScript out of the box, which of course you can configure, but you don’t really need to, cause it’s very turnkey that way.
Cameron (05:11.425) I think can also handle CSS, although I haven’t, I haven’t personally tried that, but yeah, it’s, it’s just extreme. It’s just exactly kind of that’s if, if you took nothing else away from my talk, I wanted you to take away that Vita is great and you use V. I also say, I use post CSS post CSS is like a, it’s actually what tailwind is built on tailwind is actually a CSS or post CSS plugin. I post CSS is just, it’s just industry standard at this point. It’s just really good at what it does.
processing CSS, know, flattening it in some cases, right? So if you’re using nesting and things like that. So yeah, use both CSS. Although I think eventually my sort of main or my sort of hope for CSS is that eventually you won’t have to, you know, bundle it at all, or you’ll have to just bundle it.
just stick what prop chef does, like stick a digest on the end of it to keep the browser fresh. Right. So that requests the next version. If you change it, because like CSS, the native CSS is getting so good that you almost don’t need SAS. You know, it’s, everything sort of already baked into it. There are going to be some things I think that maybe some people will want to use and continue to use some things that are not sort of available in native CSS, but, for most applications, I think it’s so capable.
now there’s not really much reason to or it will be very capable in the near future you won’t need to use something like post CSS. I say use TypeScript. I think TypeScript is amazing. I really enjoy using it. Like yes there are definitely times where
depending on what you’re writing, where you might run into the need to create some extremely long and hairy and hard to read type, but I’ve found that that’s not very common and sort of only happens in libraries, not really applications. So use TypeScript. I think there’s also like a big…
Cameron (07:03.417) There’s a big caveat to that though, I would say, and that is maybe don’t use TypeScript if you have a small team. I guess it depends on your preferences there. But I mean, can tell you that like at GitHub, at Meraki, and then also previously at Quip, which all three of those were very large React code bases, TypeScript can really save you and help you understand your code base better. So I definitely recommend it. Just being able to refactor things is just amazingly nice.
And other than that, I would say, you know, just use the web platform, right? Use web components, use stimulus, use hotwire. All these things are sort of built on top of the web, unlike React, which is kind of like trying to replace the web, right?
I say also like avoid certain tools. So avoid import maps. Like no build is very cool, but I just don’t think that we’re there yet. I think there’s lots of sort of negative aspects to that. The most applications are not going to be able to use or it won’t be good for them. Don’t use webpack. Webpack, I think had its day in the sun. I think it was fine when it came out or whatever, but it is, it just introduces so much complexity to an application.
And I personally have just spent days wrestling with web pack and fig and trying to get things to work and getting opaque. It’s half the reason that there are upgrade problems is because web pack exists in, so many, you know, rails apps out there. Stop using web pack. Please, please. I beg of you stop using web pack.
Federico Ramallo (08:24.354) hahahaha
Cameron (08:26.317) And then don’t use a JavaScript framework. I think if you’re going to use, you know, if you’re using web technologies like hotwire stimulus and I say, I say web technologies, those are not web technologies. Those are built on top of web technologies though. They leverage the web in a way that like react and view do not, right? I think that 99 % of applications out there, especially rails applications are not.
actual applications. are web, they’re, they’re document based web pages, right? There’s a request response cycle and that’s going to be fine for most of them. If you are truly, truly, truly building something that needs the level of interactivity like Figma thing was actually a great example. If you’re building Figma, then yes, you absolutely should use react. If you’re building, even if you’re building, I don’t know, Gmail or you’re building something that’s super like interactive, then for sure.
use react but if you’re not and that’s going to be like most of the applications out there then don’t use it because it’s going 99 % of your page 90 % of your page is going to be static anyway there is no reason to use a dynamic front-end framework like react to render a blog for example like you’re just just don’t do that just under static HTML okay
Federico Ramallo (09:39.992) you save so much complexity by not using it.
Cameron (09:42.68) You save. my God. You save so much. Right. Yeah. I mean, and also like, again, I’m not going to sit here and say the react is bad because it’s not, it’s, it’s actually very cool. It’s just that I think most applications do not need the level of dynamism that it gives you. Okay. I think that’s pretty much it from the talk. So yeah, the takeaways are. What is it? Let’s see. Yeah. NPM V what’s that?
Federico Ramallo (10:07.319) We say byte, bit, npm, typescript and post CSS.
Cameron (10:10.507) Yes, yes. NPM V POSSS TypeScript Rails defaults. Avoid React. Do engineering. Yes.
Federico Ramallo (10:14.883) Right? Yeah, and if you’re building a React app, then it doesn’t make sense to build it within Rails. You can build it as a separate app, and then you can have a frontend app, and Rails can be a backend API-based app. Right? Yeah, yeah.
Cameron (10:25.389) sure.
Cameron (10:30.817) Yeah, yeah, for sure. Yeah, absolutely. That’s a totally valid architecture.
Federico Ramallo (10:36.099) Yeah, and that makes sense when you’re building a complex app like the one we’re talking about at Cisco Meraki, right? Or even a GitHub or many projects like that. It makes sense to have a front-end team and a backend team, right? But if you’re a one solo startup or a small team of two people, three people, then it makes more sense to, well, what I called static HTML
sprinkle with JavaScript, right? Yeah, and that’s good enough. Yeah. Yeah.
Cameron (11:08.203) Yes, that’s right. Yes, totally. Yeah. I think there’s absolutely for a lot of applications. That’s enough. Yes. you know, I used to work on the primer team at GitHub where we built view components and we got components and, like an implementation of the primer design system. And there were definitely components that we were building, like the select panel comes to mind that
would have been much easier in React. They were honestly quite a pain to build with Web Components because they just, there was so much complexity, so many things they did, so many edge cases, right, that they weren’t really well suited for something like stimulus or something like Web Components with the JavaScript sprinkle approach, because you can’t really render a template with a Web Component, or you can, but it’s more annoying.
is not like the same. You can render on the server, but then you also have to duplicate that same logic, you know, on the front end to get the same behavior. And so, you know, that was a much more annoying and difficult to build than it would have been in react. And so I think we also, it’d be very cool if at some point we could get to a point where, know, again, I’m not anti-react. I think that some, some things, some apps maybe, but even just some small components might be better served. You know, they need that reactivity. And so I think it’d be very cool if we adopt
more and I’ll almost say islands architecture necessarily but I want to say like stick with you know static HTML for the 90 % of the page that needs it and then render a single react component where it needs to be rendered rather than doing the entire page in react and there’s a lot of sort of barriers to doing that like react kind of takes over the whole page and one of the reasons for that is because of this kind of prop passing approach if you update I think I think this is true it used to be true if you update the
you know, HTML attributes on whatever element, you know, reacts anchor to that won’t necessarily update the props and the components. So like you, you, you do sort of lose some of that reactivity. but, also getting data out of it might be a little more challenging than if you were in react, the whole page was in react, right. but, but if I was going to sort of, think about like what could be improved for the future, that’s one of things I would think of is like thinking about how we can get.
Cameron (13:28.812) these little components to render here or there where we actually need react and the rest of page can be static. I mean, as it stands now, doing that, I think would be quite heavy, right? Cause you have, let’s say you have one react component on the page, that’s fine, but you’re bringing all of react with you to do that.
If you have another component on the page that is also a React component and needs to render separately, then that’s another copy of React essentially running in the browser. So it’s kind of expensive to do that now, but I would think that there’d be ways to make that better. So maybe one day we’ll have that.
Federico Ramallo (14:03.715) Yes, yes, I think the dream is to have a nice isolated little environment where we can run these components and then a standardized API that we can use to interact with it, whether data or events, and that way you can test that in isolation, which is kind of… We don’t have enough time to talk about a view component, right? But that’s, you know, that concept of…
tested in isolation, I think that’s great. And then that way you can still use the Static HTML with just the sprinkle around approach, but also you can, if you need some more elaborated, bigger components, where you have a lot of reactivity, then you can go with a more full-fledged framework.
Cameron (14:51.726) Mm-hmm.
Cameron (14:57.624) Yes, yes, totally.
Federico Ramallo (15:01.463) Sounds great. Looking forward to see when that happens. Yes, yes. So thank you very much, Cameron, for being here, and I’m looking forward to continue the conversation.
Cameron (15:14.776) Thank you, Federico. Thanks so much for having me on and for letting me just wax so poetic about all these things and talk at length about them all. Thank you.
Federico Ramallo (15:23.821) Yes.