React and Angular are all part of the ECMAScript ecosystemWhat I learned from React after a month of dedicated learning and creatingFrom an Angular developer’s perspectiveAphinya DechalertBlockedUnblockFollowFollowingMar 15About a month ago, I decided to take the plunge into the world of React after years of working with Angular.
My entire career as a developer has been built on the Google backed framework – until no one seems to want it anymore.
Globally, Angular is still going strong but locally, React is the thing that’s in demand.
Due to financial survival reasons, I decided to put my personal preferences and code prejudices aside.
Here’s what I learned about the Facebook created and backed library after 1 month of working with it.
It’s not all JavaScriptReact is not pure JavaScript.
However, it follows the same standards as set by ECMAScript (which is the governing standard for JavaScript) — leading people down the path of mistaking React as JavaScript.
Sure, it looks, smells and tastes sort of like JavaScript but it’s not.
In fact, React uses JSX, which stands for JavaScript XML.
This makes it more like a hybrid between HTML, CSS, and JavaScript with its own quirks and perks.
JSX is actually an extension of ECMA Script that allows you to weave you HTML code with what looks like JavaScript.
In a way, this reminds me of PHP templates in WordPress — but with JavaScript and {} instead of <?php >Bringing back the 90sReact is the ultimate single state DOM manager.
No.
That’s incorrect.
It’s more what you write is what you get kind of deal.
Angular solved the annoying part of manually manipulating the DOM and telling the web page exactly what to do, React takes us back to the 90s and force us into a conscious coding mindset rather than letting pre-configured defaults deal with it.
This can be both a blessing and an annoyance.
When you are able to dictate every single action inside a web app, it reduces the overall load, unnecessary memory space taken and writing overrides.
However, for those who have become accustomed to the new defaults, going back to the 90s default forces you to learn (or re-learn) a new set of default rules.
You can’t just put in an input field into React and expect two-way binding to occur automatically.
That’s something you have to tell React to do.
State management is requiredPreviously, I voiced my suspicions about React being too easy.
My suspicion has now fulfilled itself.
Being a library instead of a framework means that you only get a slimmed down, almost bare-bones set of features and functionality that you can use.
Apart from size, the difference between a library and a framework also determines how you code.
A framework determines your workflow while it is the opposite when it comes to a library.
You control your code — calling a bunch of classes and structuring everything however you want.
Perhaps this is why it appeals so much to people, especially newcomers.
However, a library is often incomplete by itself and requires other things to help you create your application.
This React’s case, it’s the inability to effectively manage states.
Redux solves this.
But Redux is external, which can cause incompatibility issues at times.
Less code does not always remain smallReact can be as small as you want it to be.
In a way, it reminds me of Angular 1, where you can just add it to any project and isolate the React part from the rest of the application without much issue.
However, less code does not always remain small.
Applications grow and code bloat can occur, especially for those who are learning to code or are not aware of coding practices.
While Angular is like Lego blocks, React is more akin to play dough.
You can make a lot of cool and awesome looking things with play dough but it can go disastrously wrong if exposed to sun or mushed into the carpet by accident.
Architectural principles are requiredIt’s easy to boot up a React app.
You don’t need to learn much to get started.
It’s a genius way to get people to take it up, especially for newbies looking to create something quickly.
However, under the guise of simplicity is the higher chance of writing in complexity.
Angular’s weak points become the strong points once an app gets to a certain size — especially for non-veterans.
In a way, Angular 2 learned some things from Angular 1 and that is simplicity doesn’t always guarantee that things will stay simple forever.
React is similar to Angular 1 because it is structureless.
Angular 2 expects that your app will eventually grow to a size where the structure will be required and enforces a manifesto for developers to follow — either that or your code won’t compile.
While you can technically de-structure Angular and have everything in one file, most people just use the CLI to make life easier and faster.
With React, your syntax just has to be correct and you’re good to go.
Angular vs ReactSo far, I’ve only had experience in creating a series of small projects.
I’m talking CRUD with auth and a few routed pages.
It would be interesting how it is for larger applications like a dynamic shopping cart system.
Angular can sometimes feel like overkill with its multiple files, imports, and configurations.
However, it all comes in quite handy once your application reaches 10+ views, routes and components.
React, however, is the opposite.
It’s easy to kickstart a simple and working prototype but can get messy once you start having more states to track.
An architectural plan is required if you don’t want to code yourself into a corner.
In a way, that is how things are supposed to be done — plan first then code — but we all know that’s not the case in a lot of projects.
I would like to try out React on larger applications and see how it works architecturally.
Angular solves the issue of being structureless in Angular 1 and perhaps it is why version 1 and 2+ looks so unrelated to each other.
However, Angular 2 can some times appear overly complex for no needed reason.
React takes us back to the simpler days.
Final WordsReact is a library.
This means that unlike Angular, you are in complete control of how you write your code.
You call the functions in the library to make things work.
In a framework, it’s the other way around — the framework calls your code to make things happen.
In contrast to working with libraries, this means you’ll need to learn and conform to the requirements of the framework.
But that’s not always a bad thing.
Frameworks act as a guideline that enforces a certain structure upon what you’re building — sort of like council safety requirements for houses.
Libraries give you a bit more freedom to do as you please with the code.
That’s more like a person living in a small mobile container home — while portable, it won’t have all the amenities like a full-sized house.
Both types of homes have their pros and cons and are suited to different kinds of people.
It is the same with Angular and React.
I think that businesses and startups should pause and assess what they want to achieve before jumping onto the latest Internet trend.
Some projects may be better suited to Angular.
Some projects might just work better with React.
Factors such as size, extendability, 3rd party plugins support, future features and growth often make a good starting point.
We are always biased towards the technology we’re most knowledgeable about.
I hope that in learning React and using it while maintaining my expertise in Angular will help prevent this issue for me.
.. More details