5 Things I Wish I Knew Before Starting With React

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.

Quick note: This article is written by our react developer Tarek Saghir!

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 with you, I’m really glad that I did that, even though there were interesting challenges along the way.

Therefore, in this article, I would 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.

1. Holy Trinity Dilemma and Discussions

As I said, there are three popular frameworks that you will encounter in your searches – Angular, React and Vue. As I chose to jump into React development, every day I would casually encounter discussions about which framework is best/better and why.

Those kinds of discussions 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 these kinds of black thoughts, don’t let the community decide your tech stack. Once you’ve picked it, commit to it. Every framework has its why and what.

In short, the Angular framework is mostly used for larger enterprise projects. On the other hand, React and Vue are used for smaller web projects. 

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 bit longer to get familiar with the React development concept whereas with Vue development if you know CSS, HTML, and JavaScript you can jump right into work mode.

2. React Framework Commitment

One thing is for sure, when you jump into React development you will be backed with a huge community. The 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 certain that React will be THE library that makes an impact in setting front-end 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 of the projects that are being developed right now are going to need someone to maintain them. 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 to explore new frameworks, libraries and development concepts.

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

Today, front-end development has become such a broad field that if you are a beginner you’ll get bombarded with an infinite amount of information.

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

3. React Community

As I mentioned, the React community is very big. Official docs, examples, tutorials, blog posts are amazing and well written which makes them a great starting point for everybody.

There are lots of code examples on the web so I’m sure if you encounter a challenge it will be solvable by searching the web.

However, since React is one of the most popular front-end development libraries, the community is full of 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 eventually encounter the mentioned technologies.

On the other hand, if you are just jumping into React development you’ll get constantly bombarded by new information, which can lead to confusion on where to start.

Furthermore, some project development teams are React trend followers. Those projects are modern and cutting edge, but that means that you as a React developer have to be following 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 a 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 will 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 the core concepts of the 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 it forcing you to use 10% of core library concepts? If that is the case then it’s maybe best not to use the library at all 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. It cannot be avoided if you want to follow tech trends.

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

The 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 as a new developer are searching the web for examples when you encountered a problem. Every example will then be written in new, cutting edge code and you will implement it in your project.

Basically, you have been forced to join the hype train ride. If you take into consideration development teams that I mentioned before, you as a React developer will have to be keeping up with every core library concept and follow the trends. The community is unpredictable. A lot can change in the following years.

4. React development

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

Some developers are opposed 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. Once the base is finished the reusability of your components jumps into action. Then, implementing a new feature with already pre-built components reduces a vast amount of development time.

Components can maintain internal state data which is the most important 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 one, but 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 React’s core concept 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 it’s harder to achieve standardisation.

In short, the 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 pages 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 think the crawlers are more advanced by now since there are a lot of new pages on the web that are developed by frameworks and libraries like React.

5. 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 think that your solution is good, but when going through it again I’m sure that you’d find something to refactor and make it even better.

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

The same thing goes for “code-smell”. Using design patterns the wrong way can also result in bad 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 its 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 components, etc. 

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

And here I am, starting from the sketch, (before coding) as I said 🙂

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

Check out final thoughts on this topic and conclusion in our article at Async Labs.

And let us know if you tried yourself in React? We would love to hear from you on hello@asynclabs.co.