Why you need React for your site’s UI: contextual awareness
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.
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)
- 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.
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. It doesn’t sacrifice its complexity for the sake of easy comprehension. It’s complicated — and it’s lightning.
That’s a good thing. We don’t want React to sacrifice its awesome parts for the sake of any laziness.
We see most of the web’s visitor traffic happens now over-the-air. It’s all about the wireless devices: smartphones, tablets, hotspot-ed laptops, the IoT ecosystem, and whatever else humanity cooks up tomorrow.
To really understand the case for React, have a better understanding for the full potential of React as a force of technology in the future world.
Possibly even harder sells: the subconscious effect
So, we want to use React for our next project. Let’s consider how to achieve our goal.
We won’t be selling eye candy. Though we can manipulate our new React-driven UI’s components however we see fit, React still remains transparent to a website’s visitor.
… Which causes us 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 these things on the company’s time and dime.
We’re selling benefits that accrue at the subconscious level
With React, we actually sell the intangible qualities of experience. How do we communicate those things effectively?
In doubt about the benefits of investing heavily in your users’ subconscious experience? Look to Google. The brains of Mountain View spend a ton of time and money working to shave milliseconds off the load time for their results pages. A millisecond is a small fraction of the amount of time it takes for us to blink, but it’s an unprofitable delay to Google’s ad-selling rate. Data compiled from billions of searches shows that human behavior does change in terms of milliseconds of wait time. Perhaps the user never consciously has such reaction. Yet, it’s a very significant one that some people at Google regularly lose sleep over.
We should pay attention to our users subconscious as well. The user’s 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 1998 brought us
React is another leap of that magnitude.
Remember that time when you jumped into Node and nothing made sense anymore, because all the things became asynchronous?
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, but with sweet benefits!
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 time to first byte (TTFB) is now near-zero. Happiness will increase in all things around you.
- Also, you have greater control over the time to first meaningful paint (TTFMP). This number is a hugely important metric for search. Google specifically mentions TTFMP in dev docs here, and in discussion here about SERP signals for mobile visitors. Through its AMP initiative, Google continues to force the entire web to move forward on the leading edge, as they must think about TTFMP and TTFB as major considerations of SEO.
- Now, thanks to the natural separation of your site’s presentation and controller layers from the API and other back-end services, your front-end’s production environment is handled on the client’s hardware. It doesn’t run any expensive IT infrastructure you may or may not have bought for this exact moment in time. Be sure to make more advantage of client’s languishing CPU cycles, by the way. (Want to someday emulate a successful native app? Go for it, and leverage HTML5! Now you have the power, literally.)
- As a bonus from your hard work separating the front-end and back-end constituents of your app, you’re now free to develop any front-end experience. With a considerably lower cost of startup overhead, you can formalize your data layer’s exposures as a versioned API spec, and develop the front-end with confidence in your team’s capability to experience no unintended breaking changes. (
wp-json, anyone? data as a service, amirite?)
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. 🙂