When heavyweights ring in, I take notice.

The devs at TechCrunch recently undertook a total overhaul of their website, and they chose React to power it. They focused their efforts around contextual experience. In other words: they focused especially on a need to give their site more context awareness and greater capabilities for case-by-case intelligent prediction about each visitor’s behavior.

Whereas other teams may still focus on page views, they’re focusing on page engagement.

Our premise was that reading an article should feel enjoyable, and that it should be frictionless and fun to get more context surrounding whatever you’re consuming, whenever you want it. For a while now, behavior on the web has been shaped by the networks. People find links, they click on links and they’re dropped into a story without context. Links aren’t enough, they need to be able to catch up or read ahead and, in general, be better informed by the product. The burden shouldn’t be on them to put the story together.

To provide a truly context-driven experience, we need a context-driven interface. We need to be able to make things happen as quickly as our visitor’s mind is running. So, we need our service to become more contextually aware, so our our communication between our services, and our interface’s conversation with the user, will carry less overhead. Minimal overhead via optimal compression — that’s what we’re aiming for.

Graph showing impact of message vs. time taken to communicate
Hit that sweet spot.

This is why I’ve turned my attention into React. As I look for ripe areas for growth in my skill set, I see a field of delicious fruit here. React was a newbie just a few years ago, and Angular was gaining popularity, but neither were deployed on a mass scale. Nowadays, half of the unsolicited messages I receive from recruiters specifically mention React in their desirable skills list. It’s harvest season, yo.

So, what’s so great about React?

More than a fad, React delivers more front-end potential.

The street cred of making a React site is obvious. Every developer loves the opportunity to show-off their front-end skills. (Just take my site as an example: I’ve refreshed it three times already over the last year. Flexing muscles is super fun work!)

But for a tech to gain a critical mass of support, it needs to deliver real, measurable advantages. They need to be seen and felt by those who get to make the calls. You need to draw up bullet points and put them in front of the people who decide when and how the web’s major properties undergo an overhaul. Then, the magic can happen.

How to make the case?

So, how do we determine whether React is an appropriate tech for our web properties? React is a very magical thing indeed. But the benefit isn’t as tangible as some other front-end features.

Easy sells: low friction + high benefit

Here’s an example of a tangible feature: grid frameworks. (btw: you’re currently reading a page gridded up with Bootstrap 4.1. #tmyk)

A grid with ultraviolet colored lines and a bright horizon
Ahhh, this grid. So beauty simplict. More lovely yas.

Grids immediately make our life less painful: no more carrying around ad hoc sets of CSS rules. We won’t have to manually cobble them together for each project we undertake. Grids impart a foundation for a common style guide. Those guides help us to deliver us a consistently familiar, relatively easy means for prototyping, theming, and delivering on a schedule. Wins all around.

It’s a no-brainer decision: Learn a few more rules and workflow modifications in return for a huge boost in productivity.

Tron grid, light cycle, and competitor in a glowing suit
… and win enough of the dollars to afford your very own Tron suit and grid land. Neon EVERYTHING.

Less-easy sells: paradigm shifts

Sometimes, the new awesome tool doesn’t make itself easy. React is one of those. It reveals its secrets only after you’ve taken some time to learn it. That’s because it isn’t a wham-bam-thank-you-ma’am technology, bro. It has some self-respect! It doesn’t sacrifice its complexity for the sake of easy comprehension. It’s complicated — and it’s lightning. (Not as complicated as Angular, though, thank god.)

But that’s a good thing. We don’t want React to sacrifice its awesome parts for the sake of our laziness. Its awesome parts will help us to stay on top of future progress.

We’re already seeing how most of the web’s visitor traffic happens now over-the-air. It’s all about the wirelesses: smartphones, tablets, hotspotted laptops, the IoT things, and whatever else humanity cooks up tomorrow for the wifis.

In order to really understand the case for React, one needs to have a better understanding for the full potential of React in this future world (and by future, I mean as soon as a year or maybe two but also maybe just 6 months from now, because progress of the unpredictables + Moore’s Law + some unknown constant. i.e. Don’t #underestimate).

Possibly even harder sells: the subconscious effect

Cross-sectional depiction of a typical iceberg in a body of water
To find this prize, were going to have to go deeper.

So, let’s consider what we’re really going for with a React approach. The React framework is transparent to a website’s visitor. So, we won’t be selling eye candy. So… now we have another dilemma: Not only is React going to be potentially difficult for us and our team to wrap our heads around, it will be even more difficult for a non-dev to understand why we want to overhaul the things on the company’s time and dime.

We’re selling benefits that accrue at the subconscious level — the intangible qualities of experience. We need to communicate those things effectively. But how?

Whenever you encounter doubt about the benefits of investing heavily in your users’ subconscious experience, point to Google. The brains of Mountain View spend a ton of time and money working to shave milliseconds off the load time for their SERPs. A millisecond is a small fraction of the amount of time it takes for us to blink, but the data compiled from billions of searches shows that human behavior does change on the order of milliseconds of wait time. Not a conscious reaction, yet it’s a very significant one — it’s one that some people at Google regularly lose sleep over.

Google's survey on a 5-point scale asking users "How fast or slow is Google Search?"
If your users feel your site is slow, where else does that affect their opinion? How else may they think you’re slow? :thinking_face:

Likewise, we should pay attention to our users subconscious. The experience is where magic truly happens.

How is React different from anything that’s come before it?

React is a paradigm shift for front-end developers.

Remember when 1998 brought us XMLHttpRequest and gave us our first real taste of dynamic pages? Yeah, we had JavaScript already, but now we could load assets long after the page had loaded. It was a game changer. Dude. It was POWER.

Well, it’s like that again. React is another leap of that magnitude. And *drum-roll* with such an increase in power, comes…. an increase in complexity.

Remember that time when you jumped into Node and nothing made sense anymore, because all the things became asynchronous?

Asian boy coping with a headache
Yeah, it can be like that.

Yeah, it can be like that.

Now, everything is objects.

React is a framework that formally brings object-oriented (OO) process down to the HTML level of front-end web page construction. If you’ve ever gone from a language like C (which is non-OO) to a language like Java, where nearly everything is strictly an object, you remember the headaches delivered to you ad nauseum when you learned that the object-relationship model was now your pesky BFF. (And if transitioning to OO didn’t make you pain, I dare you to tackle a purely functional language, like Lisp, and avoid headaches then. It eventually happens to all of us, buddy.)

Pages are obsolete.

In The Land Of React, what you’re so used to calling a “page” is no longer a page; it’s now just an initial state of the DOM. The “page” your server sends a client is now just a bare shell that contains a div sporting a unique id attribute — nothing you’d call “content.” The shell is filled dynamically, according to your design, which you define meticulously using React’s object-oriented infrastructure. The page you intend to display to your visitors is now just a constellation of structured React components, with each having the capability to govern its behavior and its children’s behavior, and to interact with components up and down its family chain via life-cycle methods, props, and properly-crafted callbacks.

It’s practically like having a program, rather than a page, running in your browser. When you hear the terms single-page app (SPA) or progressive web app (PWA), it’s likely driven (or should be driven) by a framework like React.

All the pain, all the gain

So… yeah. Initially, there’s likely going to be pain for your brain.

The flip side is nice, though. Once you get over the Hump Of Conceptualization, you get to enjoy the yummy benefits:

  • Your site’s time to first byte is now near zero. Count on happiness increasing in all the things around you.
  • You now have greater control over the time to first meaningful paint.
    • That’s a hugely important metric for search. Google notes it in dev docs here, and discusses it here specifically referring to SERP signals for mobile visitors. Google’s AMP initiative is practically forcing the entire web to think about TTFMP and TTFB as major considerations of SEO.
  • You’ve offloaded the weight of your site’s presentation and controller layers. Now they’re on the client’s hardware, where you now can take way more advantage of those languishing CPU cycles.
    • Want to emulate a native app? Go for it. Leverage HTML5! The power is now yours.
  • Since you’ve decoupled your data layer from the other things, you’re now free to develop any front-end experience. You can formalize your data layer’s exposures as a versioned API spec, which is also now free to develop independently of any of your front-ends.
So yummy
Soooooo yummy.

That’s just a highlight of the benefits I’ve uncovered. I’m finding more of them while I continue to learn and play with React, and I expect I’ll write in more detail about some of them as I make more progress.

Yeah, it’s also a super-fun power tool!

Let’s be real here: Power tech is adrenaline. If I had unlimited time in the day, I’d go beast for stuff like React, consumer APIs, variable-centric style sheeting (incidentally, I’m currently working on one as a stealth hobby), SVG visuals… and the list goes on.

So, yeah: consider the immense upside! Take up React, get through the growing pains, and enjoy being in the ranks of devs in high demand and great prospects for future employment. 🙂