My struggle to learn React

I’m going to be honest: I’ve had a hell of a time getting my head around React. More than any other technology I’ve touched over the last 10 years of my career, I just haven’t had it click for me. It’s very frustrating as I really want to learn it, and it’s clear the library has legs.

Thankfully, Dan Abramov reached out to me when he saw me tweet in frustration about learning the library. He’s been hugely helpful at helping me unpack React, its ecosystem, its syntax, and its conventions.

My first conversation with Dan allowed me to do some soul searching as to why I’ve been having such a tough time learning React. Turns out, the reasons for my inability to wrap my head around React are many:

1. I haven’t invested enough time on learning it.

My job has me splitting my attention in 7,000 different directions. I travel between a lot of different worlds: helping sell the suits on design systems, getting designers and devs to collaborate together, helping frontend teams establish sane frontend guidelines, doing a bunch of workshops and public speaking, and writing prototype and production frontend code. And I’m not above playing the new dad card.

But wow, those are a lot of excuses! I’m fully aware that in order to learn React properly, I recognize I’m going to have to Do The Work. I have done some stuff already: I’ve done a CodeAcademy class, completed Wes Bos‘s React for Beginners course, bought books, listened to podcasts, and read tutorials. Hell, I even paid someone to build a side-project app I designed in React so I could learn how it works. Still not clicking. But I haven’t really built real production stuff with it. I have some stuff in the works that I’ll share another time, but ultimately this all boils down to me jumping in the water and swimming. I know I’m never going to be able to dedicate my whole work week to working in React, so that’ll be something I’ll have to overcome.

2. React and ES6 travel together

…and I’m not really up to speed on ES6 conventions. While I was head-down flexboxin’ and gridding’ and Sassing’ and componetizin’, the JavaScript community was promisin’, lettin’, =>’in, and creating a whole bunch of other jazz. Because React and ES6 are very much intertwined, I have a hard time digesting any given block of code. What’s coming from React? What’s just ES6 JavaScript? It’s hard to unpack multiple things at once, like trying to read a restaurant menu in a country that has significantly different cuisine and uses a totally different language. It’s a lot to process.

3. Syntax & Conventions

This is related to me not knowing ES6 very well, but I feel overwhelmed by all the {{}}, single {}, ${}, arrow functions, backticks and a bunch of other syntax. I keep tripping myself up. I’ve been writing code with Mustache for a good many years, which has fairly straightforward conventions. Everything dynamic lives inside these {{}} braces (hence the name “Mustache”), and everything outside that stuff is run-of-the-mill HTML markup. While I have no doubts there’s a lot of power that comes with this syntax, it’s been a struggle for me to know what to use and when.

4. Getting lost in `this`-land.

I find myself getting hopelessly lost when dealing with this and figuring out how to pass stuff around a React codebase. There’s super() and constructor() and a bunch of other things that I get tripped up over, despite having completed tutorials and courses. No doubt this is related to truly investing the time to learn the library’s conventions, but for now I haven’t found an intuitive way to think about all this (ha).

5. I haven’t found sample projects or tutorials that match how I tend to work.

In a popular course, you create a “fish” component, which immediately limits what kind of content can be poured into that component. I tend to create fairly dumb, reusable components (i.e. media-block, card, hero, etc) and keep specific business logic, content, and context away from that file to help ensure components can be portable and versatile. I know this is possible in React, but again I just haven’t really come across any projects that I feel set things up in this manner. I’d love to see projects that feature a library of dumb, abstract components, which then are consumed by more application-specific components.

Regarding tooling, I helped create a tool called Pattern Lab that allows teams to visually see how smaller components are included in bigger and bigger components to ultimately create entire screens. Over the years I’ve built up what I feel to be a healthy workshop environment that allows me to build production-ready frontend code without necessarily having to stand up the entire application environment. I’d love to work that way in React. I know there’s Storybook, but in my experience I’ve only seen it focus on individual components rather than drawing a line between how those components build whole UI screens and populate it with different dynamic data.

6. I’m less competent at JS than HTML and CSS

Fun story: once upon a time the Chrome Developer Relations folks reached out to see if I wanted to join their team. I was excited about the opportunity, and we set up a time for me to fly out and go through the interview process.

One of the dev advocates wasn’t available when I’d be on-site, so we set up a phone interview with him before I traveled out to California for the big interview. I’ll never forget that phone call for the rest of my life. He asked me extraordinarily hard, specific questions about JavaScript. Now, I’ve always been able to bullshit my way through school tests and questions, but I found myself at a complete loss for words. “I…don’t know” I remember myself saying repeatedly. The dude just absolutely eviscerated me. It was bad. Like crying afterwards bad.

I immediately bought as many JavaScript books as I could, and then crammed like I’ve never crammed before on my flight. I wanted the job, but by this point I mostly wanted to survive the interview without collapsing in front of a bunch of people.

I didn’t end up getting the gig (in retrospect, it was the best thing that could have happened to me; I’m extremely happy and fulfilled doing my own thing). I remember them explaining why: they loved everything I talked about; I could talk strategy, semantics, and style. But I just didn’t have a programmer’s mind and the requisite chops that come with the gig.

I’ve written elsewhere how I’ve never had a computer science course in my life, and I call myself a frontend designer, deliberately avoiding the title “developer” to avoid all the connotations and expectations that come with that label. I can and do write JavaScript, and the vast majority of that JS focuses on manipulating the DOM. I strongly believe there’s a lot of value in people who specialize in crafting amazing UI code, the same way I strongly believe there’s a lot of value in people who craft logical, beautiful programmatic code. The frontend pool is huge and there’s plenty of room for everyone.

So what?

Why did I just share all of this? I’m not totally sure. I know I have a lot of work to do to get better at React, and JavaScript in general. That said, I don’t think I’m alone in how I tend to think about & approach frontend development. I’d like to think I’m a good frontend designer, and I think I simply have a different perspective than someone with a JS/programmatic perspective. I have a hunch there are lots of people who are dedicated to writing great UI code but may feel intimidated swimming in JS-only waters.

There’s a giant, great JavaScript community out there, but I feel like a lot of times there’s an implied (or sometimes explicit) “OBVIOUSLY” or “just” that comes with a lot of the territory. For instance, I was confused why there are different ways to create components in React, and several people tersely responded “it’s common knowledge that you use functions for simple components and use classes for managing state.” I had no idea! I didn’t see an explanation of that stuff in the docs. If that’s what the convention is, that’s totally fine. Just don’t assume everyone has that info downloaded.

JavaScript is eating the world and the rest of the frontend stack with it. Those server-side languages people used to write in? Node. HTML? JSX. Styling? We do that in JS now too. HTML, CSS, and JavaScript are three sturdy, capable languages that each have their own histories, nuances, and best practices. I do worry that as we author more and more in JS we risk losing those hard-won HTML/CSS best practices. Of course, it’s totally possible to preserve those HTML/CSS best practices even as we write everything in JS, which is why I want to make sure libraries like React are accessible to frontend people like me who don’t come from a JavaScript/programming background.

This is why I’m so thankful for Dan reaching out to me. He’s been kind and patient with me as I get my head around everything, and I appreciate his willingness to listen. He asked my thoughts on the Introducing JSX page, and I said jumping straight into “Embedding Expressions in JSX” might not be the easiest for beginners to understand. Perhaps there’s a basic example of making a static component just a little bit dynamic (such as taking "Hello World" and turning into "Hello { name}").He quickly filed an issue. It’s stuff like that that has me hopeful that developers like (and including!) me will be able to master React. I’m looking forward to sharing my journey as I learn and progress.