Digging into the library that’s taking over the frontend development scene
As I start my 8-week #buildinpublic challenge, I find myself back on the React gravy train. React as a library has exploded and taken over the Internet, especially in the frontend space. It’s a requirement on every frontend job advert I’ve seen and supported by every integration I’ve encountered.
But is React really that great?
I started out in Angular and have recently and properly moved into React development over the past few months. Here’s what I’ve discovered so far.
Mindset is everything when it comes to React
React is weird — especially if you’re used to working with frameworks and full stack setups. There isn’t really much to set up, except for the way you look at things.
The way you structure your project can impact how cohesive and modular your final code is. For many front-end frameworks, the workflow and management thoughts start with the data — how you’re going to manage it, how you’re going to call it, and how you’re going to consume it.
React, however, inverses this by forcing you to focus on the UI first. Why? Because it is a UI management library.
The major difference between React, Angular, and frontend supported frameworks like Java Spring, is that React is not trying to be everything. This is not saying that frameworks are bad — rather, it is to do with the scope differences between a library and a framework.
When you switch from a framework to a library, it reduces the number of things you need to think about in your overall process flow. React brings the frontend back to its basics by pushing UI first, followed by data.
Bringing back components as components
When it comes to web development, you’re coming in from one of the following directions — backend to frontend, or frontend to backend. For the frontend to backend direction flow, this can also include the group where the developer starts off as a designer.
For frontend development work, there are actually two sides to it — the visual implementation and data connection. If you’re not a design-oriented person, implementing UX/UI can be an interesting task.
The idea of components is not new. But the way React implements it gives a refreshing twist. Rather than arbitrary breaks based on file types, React enforces the ideology of keeping components together based on feature and functionality.
While it is possible to break up the HTML and CSS into its own little files, the way React code is structured and expected to be structured goes against the general trend of doing so. Instead, it puts everything in one place, modularizing the translated visual and logical layers into neatly packaged components as they should be.
React and React Native
Why is this important?
React and React Native is a bit different because there is no wrapper — not in the sense of frameworks wrapping frameworks. Rather, React Native is more an extension.
Wrap up: It’s all the same but not the same
React is a strange but powerful little beast. For many developers, the backlog of information and knowledge we already have is usually the thing that often holds us back from unlocking it for its true potential.
However, for a lot of developers that are new to the game, React can feel much more intuitive to learn.
In a way, I’m somewhat envious of those who only know React. They don’t get to experience the friction that some of us feel when switching into React’s way of thinking.
So is React really that great?
Overall, I personally like React. It is much easier and faster to set up than Angular, and easier to integrate into an existing frontend app. This is not to say that Angular is bad — rather, it has its own time and space to operate in.
At the end of the day and under the hood, it’s all the same — just coordinated differently.