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 most popular frameworks that you will encounter in your searches – Angular, React and Vue. As I chose to jump into React development, I would casually encounter every day discussions about which framework is best/better and why.
As a result, that kind of articles 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 its why and what.
In short, 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.
2. React framework commitment
One thing is for sure, when you jump into React development you will be backed with 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 certain that React will be THE library that makes an impact in 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 expanding your horizons and exploring new frameworks, libraries and development concepts.
Don’t be afraid to make framework commitment and become an expert in that area.
Today, frontend development has become such a broad field that if you are a beginner you’ll get bombarded with infinite amount of information.
The best way to become successful in your career is to choose a field that interests you and be recognisable by your work.
3. React community
Again, I mentioned, 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 can be solvable by searching the web.
However, since React is one of the most popular frontend 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 encounter mentioned technologies eventually.
On the other hand, if you are just jumping into React development you’ll get bombarded by new information constantly, 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 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 which are dependent on a specific React feature which 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 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 project 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 organisation, project standardization, good practices, useful 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 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 be changed in the following years.
4. React development
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. Once the base is finished the reusability of your components jumps into action. Then, implementing a new feature with already pre-built components reduces 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 Reacts 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 harder to achieve standardisation.
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 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 into 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.
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.
Thinking, writing down your pseudo code, drawing sketches of your pages before actually coding can reduce vast amount of potential refactoring time.
Finally, with my current experience in React development I still have a feeling that I only scratched the surface of the React library.
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 commiting 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 mentioned frameworks (React, Vue, Angular).
To master React library and call yourself a fullstack React developer means carrying a heavy knowledge stack.
As I mentioned, TypeScript, Flow, GraphQl, Apollo, Relay, Redux, Mobx, Next.js, and React core concepts require a lot of personal time and project development experience to be mastered.
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 standardisation and hype train rides. Further, be prepared on project diversity and being a team player. There are lots of development teams that 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, everything can be achieved with hard work and passion.
Let us know if you tried yourself in React? We would love to hear from you on so don’t hesitate and contact us.