From Incidental CSS to Component Architecture
Mina Markham did not set out to become a React specialist. Her journey began in email design, moved through CSS architecture, and eventually landed her at Slack, where she led the design system effort for several years before joining Twitter. It was at her first job out of college that she first encountered React — and, by her own admission, did not fall in love with it at first sight.
Learning a second framework is a different challenge from learning a first one. Markham argues that experienced developers often bring useful baggage to the process: they already understand core JavaScript concepts, know how to debug, and have a sense of what good code looks like. The hurdle is not understanding the technology, but unlearning assumptions from whatever stack they came from.
Where to Start
Markham's advice to developers coming from other frameworks is to set aside the effort to "master" React immediately. The library's official documentation is the first stop — not because it covers every edge case, but because it establishes the mental model that everything else builds on. From there, she suggests building small, functional prototypes to internalize the hook-based model, and treating state management libraries like Redux as a later addition rather than a starting point.
A common pitfall for newcomers is over-engineering the first attempt. Markham warns against assuming that a complex state solution is necessary before an application actually demonstrates that need. Modern React with hooks — useState and useEffect in particular — handles most of what beginners need.
The Shift in Mental Models
Markham describes her own mental transition as a move from template-based thinking to component-based thinking. In server-rendered or traditional MVC applications, the file structure implies the data flow. React inverts that: components are self-contained units that own their state, and the tree structure determines behavior, not the other way around.
That inversion is often the most disorienting part for developers coming from Django, Rails, or PHP-based systems. Markham recommends leaning into React's browser-based tooling and developer experience to accelerate the adjustment. The immediacy of hot reloading and the clarity of the DevTools make experimenting cheap — a quality that she believes appeals to frontend developers the same way visual feedback in CSS once did.
What React Does Well — and Where It Struggles
Markham sees React's core strength in its large, maturing ecosystem and its strong community support. When a developer hits a wall, the answer already exists somewhere within the library's extensive documentation or in an issue thread from someone who encountered the same thing.
The weakness, in her view, is not the framework itself but the speed at which the ecosystem evolves. Keeping up takes active effort. That is less a criticism than an honest appraisal: technology moving this quickly requires intentional time spent staying current.
Practical Advice
Markham closed the conversation with practical tips for established developers:
- Improve the code you already have before rewriting it in a new framework.
- Treat the official React docs as a reference guide, not a one-time read.
- Build something real — not a tutorial copy — to force yourself into the states and edge cases you'll encounter in daily work.
- Count on ongoing learning as an inherent part of frontend work; it never really ends.
Markham's core point is simple: few developers fall for React immediately, and that's normal. Learning it is less about acquiring a magic skill and more about building a working mental model through consistent, hands-on practice.
Learning React as an Experienced Front-End Engineer
Mina Markham is a front-end architect and senior engineer at Slack, best known for her work on design systems — including the Pantsuit pattern library for Hillary Clinton’s 2016 presidential campaign. But when Drew McLellan sat down with her for a recent Smashing Podcast episode, the conversation turned to a subject she’s newer to: learning React after years of working primarily with vanilla JavaScript.
Markham’s background is telling. She spent the bulk of her career building static marketing-style websites rather than complex web applications. That meant she never faced the state management challenges that React was designed to solve. Her toolkit until recently was jQuery, then plain JavaScript (ES6 and beyond). She had no stake in what she calls the "framework wars."
First React Project: Inside an Existing Codebase
Markham’s current React work is a single project at Slack — an interactive product where users enter data, save it, manipulate it, and generate output. The interactivity rules out a server-side approach, and the data handling goes well beyond simple DOM manipulation. That pushed her toward React, which Slack already uses elsewhere.
Coming into an existing, mature codebase as a newcomer has its own hurdles. Markham notes that she’s not just learning React; she’s also having to absorb Redux, which she initially assumed was part of React itself. "I didn’t realize they were two different things," she says, "I didn’t know which part handled which." Senior colleagues warned her that Redux would make it harder to learn React from scratch — advice that only made sense once she was inside the code.
There’s also the mismatch between tutorials and production reality. Tutorials teach current best practices, but a years-old codebase often contains patterns that have since become anti-patterns. Markham finds herself balancing a desire to write modern React against the need to avoid breaking established code.
JSX and the Separation of Concerns Debate
For a developer steeped in progressive enhancement and the separation of presentation from interactivity, JSX is a bitter pill. "A little small piece of me dies every time I open one of those files," Markham admits. Writing markup inside JavaScript files still feels like sacrilege to her. "Separation of concerns — it is a thing. I’d like it back, please."
That said, she sees real value in React’s component model, especially given her design systems background. Coupling component-specific CSS to a single React component makes it far easier to extract what you need for a pattern library, rather than taking an all-or-nothing approach to a monolithic stylesheet. The trade-off: React exchanges technological separation for functional separation. Everything that makes up a component lives together, and deleting that component leaves no footprint.
At Slack, the CSS approach is pragmatic. Markham writes Less files attached to individual components, bundled via Webpack. Namespacing uses a BEM variant called BEMIT, which layers ITCSS conventions and Hungarian notation on top of BEM to distinguish components from layout objects from larger patterns. Adherence to the naming scheme varies by author, and naming components remains a perennial struggle — Markham advises naming for function and purpose rather than ephemeral feature names to reduce later confusion.
Utility Classes and the Tailwind Question
Markham hasn’t seriously explored styled-components or Tailwind. But her experience building utility classes within Slack’s design system has softened her resistance to that approach. She used to prefer a single class carrying all the styles for a component, viewing utility-class frameworks as little more than inline styles. Increasingly, though, she finds herself layering utility classes on top of component classes, and she concedes that the "one declaration at a time" school of CSS deserves a second look.
When React Is the Wrong Tool
The conversation took a contrarian turn when discussing overreach. Markham worries that developers reach for a hatchet when a butter knife would do. She remembers being "viscerally angry" when sites rendered nothing in the face of a single JavaScript error — no progressive enhancement, no graceful degradation. She points to websites that present historical or informational content which could be served as plain lists, yet are built as client-rendered applications that fail completely without JS.
Her verdict: If a site is mostly static — presenting information without requiring complex state management — React doesn’t add value. It was built for software running in the browser, not for marketing pages. She cites Gatsby as a head-scratcher: static sites built with a React front end and React-based themes feel like an unnecessary layer for content-driven blogs and portfolios that could be server-rendered and progressively enhanced instead.
Markham acknowledges that much of web development has lost the tradition of static-first, progressively enhanced sites, and she would like to see more of that craft return.
Making Peace with "Meh"
Throughout the episode, Markham walks a careful line. She’s been diplomatic about React, partly because the community can be "a little mean sometimes." Even her measured statement — that she "doesn’t love it, but doesn’t hate it" — prompted defensive responses from fans. "I didn’t say it was bad. I just said I’m meh about the whole thing. But apparently being meh is not okay."
The tribalism extends beyond React into CSS preprocessors and other technical choices, where identity gets wrapped up in tool selection. Markham, who confesses to having been dogmatic about Sass in the past, now advocates for picking the right tool for the job, and she places herself in the camp of "strong opinions, loosely held."
Her journey with React has moved from indifference, to active frustration at its prevalence, to a grudging neutrality. "I don’t get really invested in any particular language or technology," she says. "Up until recently, there was no real time or place for me to use this React library, and now there is."
Alongside React, Markham has been learning Hack — another Facebook-originated language — for her daily work. The parallel patterns between the server-side Hack and client-side React made each easier to understand. Broadening into back-end logic, API development, and data modeling has made her a better engineer even when working on the front end, giving her a clearer view of the full pipeline from data to client.
