React: Maybe Just Once

At the start of my professional webdev career, I firmly considered myself an Angular guy. I had started out with AngularJS, I had accepted it as “what HTML should have been”, and had it felt like the best solution I could ever think of after writing loads of vanilla javascript.
Then came the react hype. I found myself agreeing with a lot of the “concerns” people around me had:

Mixing 3 programming languages in a single file? That can never work!
Components in single files? What about separation of concerns?
What’s that weird syntax?

Actually, now that I think about it, most of these are basically about the outlandish look react code can have.
Anyways, I was so used to Angular that I didn’t feel any need to explore react any more. I felt strangely vindicated when the whole Licensing drama came up because Angular was “my camp” and react were “the other guys”, and I wasn’t a fan of facebook in any case.

Staying in your Lane

The thing is that this strategy totally worked! It’s easy to limit yourself to your own ecosystem if you really want to. Most libraries have counterparts in either community, and you’re not really missing out on anything if you stick to one framework or library. (There are notable exceptions such as the amazing react-beautiful-dnd, which prompted my to make my own vanillajs version.)
Most workplaces will settle on one major framework, so the only time you’d get to try out others is your own, and beyond curiosity there’s no real incentive to try other things.

It’s also easy to assume that you’ll just indefinitely get better at “your own thing” if you just keep to it. If you want to be a professional tennis player, it won’t help your career to try out other sports, right?

Another thing is that sometimes, certain techniques from frameworks will “spill over” to the rest of the ecosystem. React actually had a few things here, one of which was the redux pattern and react’s general approach to state management - i.e. unidirectional data flow.
I’m using ngrx for state management in most apps I develop for my work, and even though I’m benefiting from the groundwork the react community has laid down here, I was always convinced that it was just “the good parts” of react that had made it out to the larger ecosystem of web development; the rest of react was probably still “not for me”.

Obligatory Drake Meme

Trying out Gatsby

Funnily enough, the thing that led me to try react in the end was static pages. I had tried out most static site generators such as hugo, zola or even just gulp scripts using parcel backed by prismic for the content, and the last big one I hadn’t tried yet was Gatsby.
My fiancee was going to a conference the next day and wanted to be able to refer people to her website, and since we had already made some sketches for the look of the site, I took it as a challenge to make it in Gatsby - meaning I would have to dive into react.

And boy, was I surprised!
The first thing that surprised me was how fast I was able to get into it. With Angular (especially 2+) you essentially need to learn the entire application structure to get anything noteworthy done. In react, components are cheap - you can define them anywhere, not just in modules; you import and export them like you would anything else. A single line can be a complete component! And a useful one at that:

const Section = ({ children }) => <section class="container">{children}</section>

Libraries like styled components or Emotion use this to implement easy means of styling your components with auto-generated classes. They leverage the template string syntax to essentially provide you with the full power of CSS preprocessors like SASS or Less - AFAIK, they’re actually powered by Stylus. Again, the syntax might seem a bit weird here at first but it’s very intuitive once you get used to it:

const primary = "#ddd";
const accent = "#f33";

const Section = styled.section`
    background-color: ${primary};

    ${props => props.isAccent && css`
        background-color: ${accent};
    `}
`

// Primary background color
<Section />

// Accent background color
<Section isAccent={true} />

The second thing that popped out to me is that there’s not actually 3 languages, but just one. Jsx feels way more coherent to me than the separation of languages in Angular, and even the single file components of Vue.js (Which had I previously thought to be “the right way” to do single file components).
There’s just 2 modes - code and tags. You switch between them by respectively using a tag (surrounded by parentheses if it’s split across lines), or {} inside a tag. The brilliant thing about this is that you don’t end up needing to learn a templating language, you already know the templating language and it’s javascript!

Consider the following angular template:

<ul>
    <li *ngFor="let item of items; trackBy: trackByFn">
        {{ item }}
    </li>
</ul>
// in component class:
trackByFn(index, item) {
    return item.id
}

In react, you can do the same by just transforming the list as you normally would:

<ul>
    {items.map(item => (
        <li key={item.id}>{item}</li>
    ))}
</ul>

The last thing I want to point out is that this actually does something to the way you structure your code. You’re not required to have a specific structure, and can perfectly match the structure of your directories and code to your needs. Separation between controllers, services and models used to be the way to go, but more and more people are moving towards grouping things by their domain instead of their type. React welcomes changes like these with open arms because it doesn’t impose anything on you; it doesn’t penalize you for structuring things differently than the developers intended.
The official react guide actually points this out specifically!

By-Domain vs By-Type

A lot of people will say at this point that “Duh, that’s obvious, react is a library and not a framework”. And while that’s technically true, I don’t believe that statement is quite fair. While you can definitely use react in any project, it encourages a certain architecture and works best when used that way. You are, however, completely free in how you want to organize your code, which is the point I’m trying to make.

What did we learn from this?

For me, the main takeaway here is that different is not always automatically better, but different is always valuable. While I’m impressed with react and had a lot of fun learning it, I’m not going to turn into a react evangelist, spreading the good word among non believers.
Understanding why so many people liked react so much has taught me more about web application architecture in general, why the big push towards component-based systems made so much sense, and to not write things off because they look outlandish to me. Thinking back on my first programming module in university, I hated haskell - but now, after using lots of functional patterns in other languages, I’ve actually become a big fan of erlang/elixir, elm and probably also haskell if I went back and gave it an honest try.

Be open and try more and different things, especially if they look weird at first. Even if you don’t find your new favorite language or library, you’ll probably learn something valuable along the way!

Comments

comments powered by Disqus