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
At the end of the day, it’s all JavaScript, and React is just another translation and rearrangement of it. However, what makes React interesting is that the ideas learned can be extended to React Native.
Unlike other cross-platform enabling frameworks like Ionic, React Native is an extension of React that bridges the gap between mobile devices and JavaScript code. In contrast, frameworks like Ionic and NativeScript act more like JavaScript wrappers than actual bridges that translate into native code.
Why is this important?
It’s mostly to do with the processes and efficiencies surrounding native mobile phone apps. When an app is wrapped rather than compiling down to machine code, it’s basically a browser masquerading as a phone app. Device tools such as camera and file access performance can be impacted when using wrapper frameworks. It’s also a reason why developers advocate for proper native app building in contrast to using JavaScript frameworks to wrap around another JavaScript framework.
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.
While it’s all JavaScript under the hood, React does have its own translation of it — aka JSX. But JSX itself is more a templating system that’s optimized to work with the way React wants you to construct your components.
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.
For those who are picking up code, React’s focus on UI makes it less distracting to learn and get things up and running on a prototyped and visual level. You also don’t get bombarded by a steep learning curve. However, you still need to know the trio stack — JavaScript, HTML, and CSS. These are the things you cannot avoid when it comes to frontend development, regardless of whatever it is you’re using.
At the end of the day and under the hood, it’s all the same — just coordinated differently.
