← Back to writing
Resume Evolution 7 min Part 3 of 7

First Steps with React: A New Paradigm

My first React CodePen — apullman/ZKmXEj. Why I reached for a framework, what component thinking changed about how I saw web pages, and the gap between understanding React's syntax and understanding its model.

The timestamp says May 20, 2017 — one day before the second HTML/CSS pen. I don’t remember which I actually started first. What I remember is the feeling: I’d heard about React, understood that it was how “real” web apps were built, and wanted to prove I could use it. The pen is apullman/ZKmXEj.

Why React

In mid-2017, React was the answer to every frontend question. Not because it was always the right answer — but because the industry had decided it was, and as someone trying to break into the field, I followed the signal. jQuery was legacy. Angular 1 was dying. Angular 2+ was confusing. Vue existed but didn’t have the hiring momentum. React was the thing you put on your resume.

So I put it on my resume by building my resume in it.

What Component Thinking Changed

The vanilla HTML resume was a single file. Header, sections, footer — one continuous document. The React version forced me to think differently. Not “what goes on the page” but “what are the parts of the page?”

function App() {
  return (
    <div>
      <Header />
      <About />
      <Skills />
      <Portfolio />
      <Contact />
      <Footer />
    </div>
  );
}

This looks trivial. It is trivial. But for someone who’d been writing HTML as a continuous stream of divs, the act of naming a section <Skills /> and putting its markup in a separate function changed how I thought about web pages. A page isn’t a document — it’s a composition. Each part has a boundary, a responsibility, a name.

I didn’t understand React’s state model, its lifecycle, or its rendering strategy. I understood that <Skills /> was a better way to think about a skills section than <div id="skills">. That was enough to keep going.

The Gap Between Syntax and Model

I could write JSX. I could pass props. I could map over an array to render a list. What I couldn’t do was think in React.

The resume data — my name, job history, skills, project links — was hardcoded directly in the component JSX. Not extracted into a data file. Not passed as props from a parent. Just strings in the render function. I was using React’s syntax to write what was essentially static HTML with extra steps.

This is the most common pattern I see in developers learning their first framework: you learn the how immediately (JSX compiles, components render, props flow down) and the why over months of building things that don’t quite work the way you expected. The “why” of React — unidirectional data flow, the component tree as a function of state, the idea that UI is a projection of data — wouldn’t click for me until I was working on a real application with real state management problems.

For a resume site with zero interactivity, none of that mattered. The pen worked. It rendered my name and my skills. It was “built with React.” Mission accomplished, lessons deferred.

CSS in the React Era

The styling approach was revealing. I used a regular CSS file alongside the React components — no CSS-in-JS, no styled-components, no CSS Modules. Just a global stylesheet with class names that the JSX referenced. The same legacy.css palette. The same gradient hero.

I didn’t know that CSS-in-JS existed. I didn’t know that component-scoped styling was a thing people had opinions about. I just wrote CSS the way I’d always written it and imported it. This is the correct instinct for a resume site, but I arrived at it through ignorance rather than judgment.

It would take until Svelte — years later — for me to find a styling model I actually preferred: scoped <style> blocks in single-file components, no runtime CSS-in-JS, no global class name collisions, no build-time extraction debate. Svelte’s approach is closer to “just write CSS” than any React styling solution, which is probably why it felt right to someone whose first instinct was always to reach for a stylesheet.

The Five-Year Gap

After this CodePen, I didn’t rebuild my resume site for a long time. I got a job at GDIT. Then another role at GDIT. IT support, then security, then DevSecOps. I was writing RHEL shell scripts, not React components. Implementing NIST 800-53 controls, not CSS animations. The resume sat as a static page somewhere, unchanged.

The next meaningful frontend work wouldn’t come until September 2022, when I started contributing to Meshery. That’s a five-year gap between “I can write React” and “I’m building production React components for a CNCF project.” The gap wasn’t wasted — the security and systems work gave me depth that most frontend developers don’t have. But the portfolio was frozen.

What This Pen Taught Me

  1. Frameworks are thinking tools, not just syntax. React didn’t make my resume better. It made me think about my resume as components instead of as a page. That mental model outlasted React in my stack.

  2. The first version in a new technology is always the old version with new clothes. My React pen was HTML with angle brackets. My first Svelte components would be React with different syntax. The real learning happens in the second or third project, when you stop translating and start thinking natively.

  3. There’s no shame in a gap. Five years between hobby CodePens and production open source contributions. The work I did in those years — on systems, on security, on infrastructure — is what makes my frontend work distinctive now. I don’t just build UIs. I build UIs with opinions about the systems underneath them.

This is Part 3 of 7 in the Resume Evolution series.