:heart: React

Thoughts on React after the first commercial project

July 31, 2019

It’s the future. It’s expensive. It’s unstable. And all these (will be) manageable.

The project

I was commissioned to redesign and rewrite a photo portfolio site by an old client. One of the requirements was to update the old stack and make it future friendly.

I choose to go with React and used the relaxed timeline to get the most out of it.

Up until now I was just playing with small projects to learn parts of the ecosystem — and I’ve really enjoyed. Diving seriously into React taught me some interesting lessons.

1. React is the future

I’ve been working with the web in the last decade pretty extensively.

I’ve built my own stack and learned frameworks, languages and paradigms like MVC, Ruby, Ruby on Rails, PHP, WordPress, Yii, BEM, Compass, SASS, Bootstrap, Javascript, jQuery, Foundation, Jekyll, Grunt / Gulp / WebPack, Semantic HTML — you name it.

Among all React is the first paradigm which felt truly complete.

By ditching the concept of web in favor of user interface and betting all on a real programming language — it’s the first time:

I do programming instead of hacking and tweaking.
I do think visually about a design instead of using some abstract things like url.
I do think purely about the data with GraphQL, fragments instead of being constrained by anything like REST or API.
I enjoy the isolation offered by colocation: all stuff — data, style, logic, markup, behavior — in one screen under my fingertips.
I feel confident about my code. Since it’s pure Javascript (no HTML, no CSS) I’m sure edge cases can be spotted, tested and made it work.
I feel confident that I can do anything I wish for, easier than before.
- I’ve generated a requirement specification document from code comments.
- I’ve extracted inline comments to a markdown document and added to Storybook to get a complete API documentation.
- I’ve created a complete Styleguide powered by a simple component.
I see how code syncs itself with the latest developments in both HTML, CSS and Javascript.
- One of the best moments during the project was when struggling with the slider / carousel and after lots of thinking / refactoring / doing it the React way the final solution implied the usage of the CSS scroll snap technique which is a newly added browser feature.
I know the framework / community / ecosystem will do the heavy lifting for me to assure web design and development best practices are automatically met; I just need to focus on my job, the common knowledge is given.

Overall I feel all the shit was cut and it’s the first time when I really do user interface design and development — which might happen to work on the good old web. Or anywhere else. It doesn’t matter.

2. React is expensive

Good things come at cost. Learning and running React was so far the most time-consuming adventure in frameworks.

2.1 Learning

React is famous about its steep learning curve. And controversies. No wonder — there are lots of things to learn and many of them are revolutionary.

To get into React one has to forget any prior web experience and learn the following new paradigms:

Thinking in React.
Typechecking.
Co-located data requirements, data-driven applications.
CSS-in-JS.
Hooks and the async data flow.

These are for starters. Dare to check out the current state of the art, the Facebook 2019 redesign and rewrite.

2.2 Ecosystem

Every new framework / paradigm shift is so huge it lefts room for interpretation, deviation, experimentation. This is called the ecosystem around the new thing.

Ecosystems are chaotic. Individuals, shops pop up and come up with a better or not solution, plugin, package, module, style guide — then start evangelizing their approach and made people stick to it.

Even if there is an official way it is skipped, many times, unfortunately.

I’ve been actively involved in two such ecosystems, one around WordPress the other around Ruby and Rails. Even if these frameworks are strongly opinionated I’ve seen many strange cases when people thought themselves smarter than the original creators.

I’ve heard things like “We can’t follow the official guidelines because our company has special needs” — and saw the wheel reinvented then the result burying entire teams, products and carriers.

What I’ve learned for life is: Stick to the standards.

The twist is React has no official way. In fact it has (”Thinking in React”, ”Rules of Hooks”) but it keeps calling itself opinionated.

I don’t know the motivation behind but I understand it. Facebook gave free to the world the fantastic React, supports it heavily, nurtures it to be the best tool for UI development. That should be enough. It’s already a real bravery and we can’t expect more — the same treatment for all other parts of the ecosystem.

This ignorance / strategy (?) lead to:

Typechecking with Flow was so badly supported ~~opportunists like~~ Microsoft took over with Typescript / VSCode.
Data driving applications with Relay — again, not properly supported — was replaced with simple “Do GraphQL Right” by Apollo.
CSS-in-JS was treated as a stepchild forcing the community to take over and give back the enjoyment of styling UIs. I’ve tried 6-7 frameworks and only one single survived. What a waste of resources.

2.3 Costs

Combing the learning and ecosystem difficulties we can affirm React will be costly.

I’ve re-written three times my current project to reach a level of confidence. The first two versions were working perfectly, no doubt, but somehow at the end I felt something is missing, something is wrong. I knew the result might work now but it’s not sustainable on the long run, it’s not done the React way.

There will be many like me re-writing a project until it fits all, and there will be others who won’t. In the latter case the cost will be immense for the company paying the bills. The beneficiary will get something particular, not following standards, and if by chance the dev team is changed, perhaps the whole codebase has to be rewritten.

React is all about rewrites and migrations, anyway. Currently in the direction of away from the Facebook stack — but after the (potentially highly successful) 2019 Facebook rewrite/redesign and Facebook’s wake up — back to the Facebook stack.

I have to mention the Hooks controversy. After five years the core of the language was changed in a way that it makes the old approach — classes with boilerplate — unrecognizable for those who learned React the new way — with hooks and function components.

Billions and billions lines of old code to be thrown out.

3. React is not stable

It was terrifying to feel again something is not right inside the core of a system.

The last time I felt the same was long time ago during MS-DOS times and BASIC, maybe the first years of Windows. Since then all went smooth with PHP, WordPress, Ruby, Rails, and co.

If there was an error message it didn’t disappear suddenly next time — like it does now in my current project built with the official Create React App.

An error message could be easily googled and perhaps solved. Now one gets different messages for different browsers making error fixing a bit surreal.

Surreal like a current experience with Storybook where again errors come and go without explanation.

These flicks were spotted in mature and even official React projects making the warning stronger against React. The good news is the solution might be on the way and perhaps is called Reason.

Summary

Will the future be expensive and unstable? It sounds like the current global affairs, so it might be.

Personally I believe the opposite.

I’ve found in React and the ecosystem around a real tool for user interface design and development at scale.
Clearing the waters and sticking to the upcoming official Facebook stack (React, Redux, Relay, Flow, ReasonML) will make code re-usable across projects and teams. And stable, perhaps, too.
Building up personal experience distilled into a framework of re-usable components will cut project execution time back to normal, then less.

Resources

To React with best practices. Written by @metamn.