What do you need to know about react development?

Say that you have an idea for a frontend web app that you want to develop with a popular javascript framework. Choosing a framework to ease your work is a smart idea. When searching for the right one, you’re probably going to encounter the three most popular Angular, React, and Vue. 

When I faced that dilemma, I chose React. At that time, React development was a hot new thing on the market, and everyone wanted to jump on the hype train. To be honest, I’m really glad that I did that, even though there were exciting challenges along the way. 

Therefore, in this article, I will cover 5 things that I wish I knew before I chose React. You won’t see any code in this article, only my thoughts, and experiences.

What does a React developer need to know?

01. Holy trinity dilemma and discussions

There are three most popular frameworks that you will encounter in your searches – Angular, React, and Vue. Since I chose to jump into React development, I would casually experience everyday discussions about which framework is best/better and why.

As a result, that kind of article can start an infinite loop of framework doubt, and the project that you’ve started will never be finished. By framework doubt, I mean thoughts like – “Why didn’t I go with Vue / Angular, it does … better than React. 

Let me try it and start from scratch”. You’ll have a constant feeling that it might have been a better idea to solve your problems with other frameworks, and you’ll be thinking that you’re missing out on something. 

To avoid this kind of black thoughts, don’t let the community decide your tech stack. Once you’ve picked it, commit to it. Every framework has “why and what”. 

In short, “larger” enterprise projects mostly use the Angular framework. On the other hand, “smaller” web projects use React and Vue. 

When you compare React and Vue, some say that Vue developers “took React development concept idea and made it better”, hence they are not that different. 

The biggest deciding factor between React and Vue is the learning curve. It takes a little longer to get familiar with React development concept, whereas, in Vue development, you can jump right into work mode if you know CSS, HTML, and JavaScript.

02. React framework commitment

When you jump into React development, you enter a huge community. React library is supported by Facebook and its popularity just continues to grow.

That sounds awesome, but since frontend development is so volatile, we can’t be sure that React will be THE library that impacts setting frontend development standards. 

Frameworks will be popping up every day, and nobody is sure that React will still be popular in the next five years. However, you don’t have to worry. There will always be a demand for React developers in the continuing years. All projects being developed right now are going to need someone to be maintained. If you are going to invest your time into React development, it won’t be a waste.

On the other hand, if you chose frontend development, your mindset should be adaptable. In that case, if React development one day won’t be popular anymore, switching to other frameworks or libraries won’t pose a problem.

In addition, as you gain experience and knowledge, your developer growth path will lead you to expand your horizons and explore new frameworks, libraries, and development concepts. 

Don’t be afraid to make a framework commitment and become an expert in that area. 

Today, frontend development has become such a broad field that you get an infinite amount of information daily if you are a beginner. 

The best way to become successful in your career is to choose a field that interests you and be recognizable by your work.

03. React community

Again, I mentioned, React community is vast. Official docs, examples, tutorials, and blog posts are excellent and well written, making them a great starting point for everybody.

There are many code examples on the web, so I’m sure it can be solvable by searching the web if you encounter a challenge.

However, since React is one of the most popular frontend development libraries, the community comprises developers with different backgrounds. Everybody has their own opinion on how to do things. 

Consequently, there is no reliable standardization you can rely on. What I mean by that is that the knowledge stack varies from project to project. 

For example, some projects are using TypeScript, and others Flow for type checking. This means that you have to know both to be able to jump into every project.

They are similar, but it takes time to get to know them. In addition, some projects can use GraphQL as API middleware which handles project data instead of calling REST services. 

Your knowledge stack should then increase to GraphQL, Relay/Appollo, and Node.js. As your development growth path continues, you will encounter mentioned technologies eventually.

On the other hand, if you are jumping into React development, you’ll get new information constantly, leading to confusion on where to start. 

Furthermore, some project development teams are React trend followers. Those projects are modern and cutting edge, but you as a React developer have to follow every new React feature and be very much in touch with incoming changes. 

That is logical, but take this as an example. You’re working on a large-scale enterprise project which could prolong into 10-year development. If you are following the trends and implementing new things, there could be a case that React development team decides to ditch one of its features (not possible, but let’s say it’s Hooks – as it’s a hot new thing right now).

Your enterprise project depends on that feature and that means a nightmare. The agency that you’re working for now has to invest money and resources or you, as an individual, have to invest refactoring time on re-writing features that are dependent on a specific React feature that is gone.

On the other hand, it could be a case where your development team decides to take a safe route and implement only core concepts of React library. Then, imagine that the React dev team decides to deprecate one of its core library concepts. You are now facing the same problem as before.

What is the best way to take care of that problem? Is that forcing you to use 10% of core library concepts? If that is the case, then it’s best not to use the library because you’re not using its full potential. Should your team then fully commit to a framework? 

In my opinion, they should. If you chose a framework, stick with it and use its full potential. That means that you’re accepting the fact when you write your first lines of code, you’re already writing a legacy project. You are ready for a scenario that some of the projects could be refactored in the next three years.

Besides, it can be sustained by clean code organization, project standardization, good practices, proper design patterns, and overengineering avoidance.

React development community enjoys riding the hype train with new features. It means that once something new comes, everybody starts using it in their project development. 

Imagine that you were searching the web for examples when encountering a problem as a new developer. Every example will then be written in new, cutting-edge code and you will implement it in your project. 

You have been forced to join the hype train ride. Take into consideration the development teams that I mentioned before. As a React developer, you will have to keep up with every core library concept and follow the trends. The community is unpredictable, and many things can change in the following years. 

04. React development

The first thing that made me baffled in react development is JSX. It’s a concept of writing HTML inside JavaScript code. Since it’s an entirely different approach, it might take a while to get used to it.

Some developers are repellent to that approach, but it fits nicely in the whole “component” mindset that React is based on. It allows you to build component-based abstractions.

Imagine it as Lego blocks. If you are making a project from scratch, the development process seems slow. It’s because you’re basically making your base ‘Lego’ blocks. When you finish the base, the reusability of your components jumps into action. Then, implementing a new feature with already pre-built components reduces the vast amount of development time.

Components can maintain internal state data which is the essential part of working with React. Since it’s the most important, of course, it has to be the hardest. This means there must be a library for that. Of course, there is.

Not only one, millions of it. One that sticks out, in particular, is Redux. We won’t go into details, but it’s an external 3rd party library for easier component state management. We can add this to our list of stack knowledge that you will encounter sometimes. Of course, other teams might be using other libraries like MobX. That also means, even though you know Redux, you’ll have to learn MobX if you encounter a project with it.

With Reacts core concept of state management and 3rd party libraries, there’s a lot of variety on the market. We can acknowledge a correlation with the previous statement that there is too much diversity. It means harder to achieve standardization.

Another thing that you don’t think about when creating your web app is server-side rendering. In short, React page does not render HTML code on the server-side which can confuse the web crawlers that search engines use. They won’t be able to crawl the page, and that hurts your page’s search engine ranking. 

But don’t worry, the community solved that too. How did they do it? You guessed it, by creating another library. Of course, there are many server-side rendering libraries on the market, but Next.js comes first to mind. It renders your page on the backend with HTML code which then can be indexed by the crawlers.

Some developers think that react page crawling does not pose a problem anymore. They believe the crawlers are more advanced by now since there are many new pages on the web developed by frameworks and libraries like React.

05. Best practices

As you build your first project with the React library, there is a possibility that you get stuck in your own project. All your time gets consumed by development, and you’re not keeping up with the news in the community. 

Since the React community is young, there are daily topics that could really benefit your project. When you create a new feature in your project, you don’t think about it twice. You feel that your solution is good, but I’m sure that you’d find something to refactor and make it even better when going through it again.

Not rethinking your code results in making Antipatterns. Thinking twice about your code and instant refactoring over the solution may save you refactoring time when you reencounter it again after a few weeks. 

The same thing goes for “code-smell”. Using design patterns the wrong way can also result in harmful code, which can pose a refactor time-consuming problem. 

Furthermore, developing complex state management and coding lots of business logic inside a component results in a bloated component. You can easily pass a 1000 line component, which must be avoided. 

When developing your components, separating their concerns is the best way to avoid bloated components. You can achieve that by extracting some code into helpers, breaking down and extracting HTML code into smaller segments, etc. 

Basically, what I’m trying to say is to think before you jump into coding. Drawing a sketch of the page and thinking about the state management between your components can make a difference. 

Thinking, writing down your pseudo code, drawing sketches of your pages before actually coding can reduce a vast amount of potential refactoring time.

Finally, with my current React development experience, I still feel that I only scratched the surface of the React library.

Start with react development today

In this article, I tried to present my experience so far. With these bits and pieces, I tried to draw a perspective for a reader to alleviate her/his path into React development. Mentioned holy trinity discussions should not scare you when committing to a framework. 

When you choose your framework, try to master it and use its full potential. There is no frontend career mistake with any of the three frameworks – React, Vue, Angular. 

To master React library and call yourself a full-stack React developer means carrying a heavy knowledge stack. As I mentioned, mastering TypeScript, Flow, GraphQl, Apollo, Relay, Redux, Mobx, Next.js, and React core concepts require a lot of personal time and project development experience. 

Your developer growth path is a process, and it takes time. Big React community will certainly help you in that but be prepared for diversity in opinions, lack of standardization, and hype train rides. Further, stay open for project diversity and be a team player. Many development teams are using different development approaches because not every project is the same.

Lastly, and most importantly, always be in the loop. Frontend development is very volatile. There’s a new thing on the market every day, and our career paths can change every year. That’s the best thing, you’re always learning something new.

So, if you want to “survive” in this department, you have to keep an open mindset of constant learning, adapting, and time investment. In the end, with hard work and passion, you can achieve everything.

Let us know if you tried yourself in React? We would love to hear from you, so don’t hesitate to contact us or leave a comment below.