Comparison between the most used frontend frameworks | React vs Angular vs LIT vs Svelte

React vs Angular vs LIT vs Svelte

Are you a developer/architect starting a new project and wondering what is the best choice in terms of frontend libraries, or if it’s best a frontend framework?
Have you heard about many frameworks, but you don’t have the time or the expertise to test them all?

You can find many “React vs Angular” or “React vs Svelte” blog posts and article, but how many of them coming from real experience? My feeling is that many of them are just clickbait or just a way to collect organic traffic from search engines.

Is it so easy?

I read many times very basic and very biased comparison. But how can a frontend developer be able to gain years of experience from all of this frameworks and libraries? I think it’s a challenge, or at least it has been for me.
Just to be productive in Angular and write good code quality it took at least one year, mostly to digest the Reactive part. But after that, it was a really great skill I felt unvaluable to compare these frameworks and tools.
How long it takes to be fluent in frameworks like React, and be able to write Functional components following best practices and write high quality code, with testability in mind and easy to change when business requirements changes too?
One of the first thing to look to these React App is:
1) how many redundant calls to the API/backend are made?
2) are “cancellation requests” in place?
3) in case of errors will you get a spinner spinning forever on a broken page?.
Just a list of the most common junior-mistakes. That’s not Professional React in my opinion.

The right tool

Are you just comparing React vs Angular? But do you know it is very important to use the right tool for the task? It’s one of the primary topics in IT. With the right tool, everything become more easy, and the project will bea success. I see too many project made with React because “it’s the standard” or “we know only React”. I think in the frontend ecosystem is a huge mistake. I have seen Design System made by React that after huge investments, no one want to use it. There are many frameworks available today, each one with a specific goal in mind, so it’s your responsibility – as architect or developer – to choice the right one.

Why everyone likes React

Many developers have also started their career using React, and they think is the “standard” now, and if you take a look to usage trends” you will see it’s the most used. But have you wondered why?
In my opinion it’s because it has been the first Frontend library pretty easy to use, after AngularJs.
AngularJs and Knockout were a milestone in the SPA framework world, as they were the first to try to build a high level interface to write SPA easily for Javascript developers.
They did their design mistakes, and bad choices. Then React tried to solved them, but it was many many years ago. So, React was basically the only library available at the time, meanwhile the new Angular was still a work-in-progress.
So, many developers and projects started to use React, as it was efficient and easy, and it was suited for the SPA requirements at that time. But then, SPA requirements growt, and React it was not enogught, so many extra complex side projects like Redux were built, so try to solve the lack of solutions.
But at that time, a huge amount of developers started to learn and use React, and has been a standard. Does this mean is still so?

Is React still a modern framework?

If you see the React roadmap and feature release, you will see that in the last few years their are kept behind, they just release small upgrades every many months or years, and it has not been big changes there. It looks like Meta has not anymore interest in keeping React up to date, maybe due to investments in other areas (metaverse)?
So, basically, React is an old library in my opinion. You will agree with me if you try latest version of Angular, LIT, Svelte or Vue.

React vs Angular: the big question

So, is it best React vs Angular? The real answer is: it depends.
Is your SPA app simple, and you have low-middle experience? Do you think learning a new framework or tech is a vaste of time, than React is for you.
Is you SPA a big enterprise app? Then Angular is the only choice. But, I said “but”, you need to learn the “Angular way”, or the “Reactive way”. If you write an Angular app in a “Javascript way” (like you are for sure used with React) it will bite you, and as many others you will say that “Angular is bad”. Angular is for professional, senior, skilled, passionate, developers. Only a Reactive approach can solve the spaghetti code problem many Junior devs write. Why? because it’s the only way, as it was built for that, it was its goal. You can achieve the same results as with Redux, but Redux is more complex and boilerplate. Again, just use the right tool for your job.

React vs Angular: the BIAS

I was a bit strong here because many times I read and spoke with people saying the same thing about React vs Angular, and when I’m asking the motivations, I did understand that they didn’t have a real experience with both of them, or they just refused to learnt the Reactive way (rxjs).
So my suggestion is that the next time you read or speak with someone about this topic, just check have fluent they are with Reactive programming. You will be surprised about what you will find yourself.
As a engineer, I’m used to come to my answers using a “scientific approach”, so I try to exclude any bias or “believe”. I like “facts”.

Are you a dinosaur?

And just remember, the SAP frontend landscape changes so fast, that if you use ONLY the same framework/library for few years, you are became a dinosaur, close to technical extinction.
Our job is to keep our skills up to date. So try to build a side project (if you cannot do it in your daily job) with as many frameworks you can, and try to build real-world apps, not just super easy app, how I see many do. In my opinion/experience, to learn a new library/framework, it takes a t least 6 months if you are working fulltime with it, and you are going deep in the best practice and are you trying to solve problems in the “right” way.

Are you a professional developer?

For example I see many that consider a LINT just a waste of time, or usage of ANY in Typescript OK. For a big App this is a HUGE NO!
How can you refactor code if you don’t have the compiler catching the errors for you? That’s a huge work!
In some frameworks that super easy (as in Angular) ion other very difficult (as in React). So you need also the right mindset.
Then you will understand the motivation between Reactive code, that remember, it’s not just Angular, but also Svelte is using it. Many mobile frameworks are using it. So it’s a skill that is more and more in demand now.
Why? Because it helps to write complex code in a easy and easy-to-follow way. Basically it exist only one point in the code where you are allowed to change a value in the UI. That’s a big help, so no more spaghetti code everywhere to keep in sync your UI. You will find more info about this topic after the comparison table.
This to me is to be a professional developer: the ability to write code that helps your business, and allow your codebase to change as fast as your business requirements. You provide value.

My experience with React, Angular, LIT and Svelte

In the last years I have had the opportunity to work with the most used Single Page Application (SPA) frontend tools/frameworks/libraries in a professional environment, to build from small and pretty big enterprise SPA applications.
In this article I will use the term “framework”, “library”, “tool” with the same meaning: a “something” that we use to build a SPA that get us productivity, avoiding to write everything from scratch, and that give us a good build pipeline.

Small and enterprise apps

For “small” applications I mean a SPA with few pages and not pretty easy logic, for example application to manage few configurations (CRUD – Create-Read-Update-Delete data) or that expose to the user simple pages to admin their profile. Another example could be a simple company website.

For “enterprise” instead I mean more pages and complex logic, for example back-office applications with complex dashboards and/or many pages to manage data with dynamic relationships. Another example could be a CRM, ERP, et similar.

A “well done” application

I have had also the opportunity to work with many developers, each with his own mindset, experience and focus on different topics, what they think it’s important in a SPA application and made it “well done”, “professionally done”, “a good work”.
In the last few years I had many discussions in what is best, which framework/library we should chose to develop the next application. So I thought could have been interesting for others to share my thoughts on this – pretty opinionated – topic.

I would like to underline that is my point of view, based on what I think is important from a developer and business to achieve success: a good developer experience, keep easily up to date an application, easy to read/write and understand code, and only as last point performance.

Focus on SPA framework performance

I argue that nowadays performance are not so important as readability and/or maintenance, because these frameworks already give us a very good experience. If you follow their best practice, 1µs (microsecond) more or less to render a page, in a normal not-critical SPA, doesn’t matter too much. If you are building a SPA where performance is critical from a business point of view, then you can skip this article, as it means it’s not for you.

Are we up to date?

The topic is pretty huge, and it’s very difficult to be up to date, so if you find out I wrote something not correct, please let me know.
As example few years ago I worked with a developer that was in charge of choosing the tech (basically the architect) that wanted to use React and Yarn.
When I check him rationale, he said that Angular and Npm were crap.
Then I found that he was few years outdated, as he meant AngularJs (and not Angular) and a very old Npm version.
Nowadays Npm is as fast as Yarn, and both support package.lock files, and Angular is a completely rewritten SPA framework with native Typescript support, completely unit-testable, and so on, so his rationale was completely wrong.
He was – for example – very focused on performance rather that code readability and ease of maintenance (as opposite than me).

Strongly typed code

I’m also a big fan of strongly-typed code, so I prefer Typescript over Javascript, so I can demand the boring task of debugging directly to the compiler. And I can skip to write thousands unit-tests to keep a decent code quality, too.

Unit-test or not to unit-test?

I think that also unit-testing is important. I don’t mind to have 100% coverage, but at least that the code “could” be tested, so based on the business requirements, you can chose to write or not write unit tests. I’m not extreme some others on this point, because in my experience (and based on the Pareto 20-80 law) the most efficient thing to do is to have a good coverage of the most important parts, that are also easy to write. As example pure functions used often in the code (as helpers, validators, etc) are very easy to test and give us a good value back.
I use the word “value” because I think is the core of our job: build value, an application that to be implemented costs less than the generated revenue. So all my choices are based on the value a feature could give us back.

The comparison

If you do not agree with these points, then you will also not agree with my considerations!

So let’s start with a comparison between frameworks:

  • I will explode some point after the table.
  • The points are not sorted by importance.
  • We can use the table as a global reference.
  • The score is meant to give a value between fit (10) and do not fit (1).

Let’s start.

Framework Angular LIT React Svelte
Typescript support 10/10
Native typescript support. Eslint available.
9/10
Very good native typescript, but sometimes it requires some extra care.
5/10
Built in javascript many years ago, it lacks good support for typescript, sometimes you need to write ugly code to get the right types. The official documentation is only for plain javascript, so you need to figure out yourself how to solve problems. And no, any is not an option for me. Eslint available.
9/10
Good typescript support.
Easy of updating/upgrading between minor & major versions 10/10
Most functionality are built in, Angular Schematics can updated automatically the code, easy to use CLI ng update
9/10
Pretty stable library, the APi surface is not big, so it’s pretty difficult they break stuff.
5/10
Worst point about React. Have you ever tried to keep a React application for many years? That’s why usually they build a SPA for one version, and just stick with it.
9/10
Using Svelte-kit you get the most you need, so they have control over the API surface. I don’t have a long-term experience with this framework, but I think it should just work.
Code readability 9/10
The code is splitted up between html and code, well written rxjs make complex code very easy to understand, input & outputs are strongly typed, clear life cycles hooks. Many linter available.
8/10
Not pure separation between html and javascript code, html-literals are sometimes hard to read and they require extra care. The reactivity model is pretty good.
5/10
TSX mixes html and javascript, who thinks is a good idea should read code written by other people. UseEffect and useHook are not easy to follow and require pretty skilled developers to keep high quality code base. What about complex workflows that in Rxjs are just a few operators? what about cancellable request, debouncing, etc? Many linter available.
7/10
Make easy to write components, but the reactive implementation is a bit weird. It uses reactivity, writable/readable stores, but you need to keep the code pretty simple, and is difficult to wrap in bigger services, mostly by design. I agree is a good idea, forcing the developer to keep it simple, but for enterprise applications is just not possible. I feel it’s a mix between Angular and React.
Packages pollution 8/10
The most you need is built in and updated by angular itself. You just need extra tooling or UI frameworks. Big names back the most used packages (material, bootstrap, etc) keep in sync with mayor versions.
8/10
If you use LIT to build web components, you don’t need too much stuff, you can just write plain css thanks to the shadow doom, css-variables and support to modern js and css. If you use LIT to build an SPA than you need to include what you need, but you will find all you need already built-in, or officially supported packages. Open Web Components provide npm packages that put together stuff for you.
3/10
You need an extra package for everything that is more than just TSX. And usually maintainers of these packages are not connected with Meta. Good luck trying to keep up to date between versions and in a long time span. You are also relying on create-react-app, try to avoid to “eject” at least.
8/10
As you should use Svelte-kit (as they suggest) the need for external packages is limited. Just try to avoid small low-used packages. I saw many Svelte packages not been updated, and codebases left to 1-2 years ago, mostly I think due to the explosion of the library. Tie to external packages carefully.
Reactivity support 9/10
Built in, good documentation, I’m only missing strongly typed binding with html elements. There are available also many linter rules that helps to keep good quality and avoid common mistakes.
7/10
Built in, easy to use, but it lacks complex operator to manage stores with complex logic, but maybe it’s just not the right tool for the job.
6/10
UseEffect, useHook, useState, etc, are a beginning, but you need much more to build an app. Where is the glue usually one needs?
7/10
Built in pretty basic reactive support, for more complex stuff you need to lean to rxjs. the built in reactivity way has no operators, just subscribe and readbale/writeble/derived stores. I’m missing powerful operator like CombineLatest, merge, keep, SwitchMap, and so on.
Documentation 8/10
The official website explains the basics, but is not in depth with rxjs, the most important and difficult to learn, hence it receives most of the criticism due to  misunderstanding the tech.
9/10
Very good documentation, I found everything I needed to start and grow along the way. They publish also videos on their official channel explaining the core topics.
6/10
Basic concepts explained, not really up-to-date docs with the new functional components. Mainly in javascript, lacking typescript support.
6/10
The documentation just shows the basic usage, examples are too simplified, not real world examples. If they improve on this side, they could get more users for sure.
External packages 9/10
You can find pretty everything, good support over time, I think thanks also to the easy of keeping in sync with newer versions.
7/10
I’m unsure here, as I have used it to build web components, what do really need? Maybe rollup and elative packages are not easy to use sometimes.
7/10
You can find basically everything, but no official support, too many choices, private maintainers, is the risk worth for you?
6/10
I found many packages not really supported (or abandoned to 1/2 years ago), so be careful about what you chose.
Easy to start 8/10
Pretty easy to start writing simple components.
9/10
The best framework for now.
8/10
Pretty easy to start writing simple components.
8/10
Easy and fun to start. It works out of the box.
Learning curve 4/10
Very steep learning curve to master best practice and reactive programming (rxjs).
8/10
Pretty easy to learn, thanks also to a beautiful community.
6/10
Pretty easy to learn and put things together, but to achieve high code quality is another story.
7/10
Pretty easy to learn, but for more advanced scenarios it takes a while to understand which pattern is best. Pretty easy to make design errors. Reactive stores are easy to start with, but to build more complex stuff… I’m still looking on it.
Fit as enterprise app 10/10
Very well defined patterns, separation of concerns, unit testable code, easy to describe domain concept via functional reactive code.
6/10
I don’t think so. The perfect fit is to build web components.
4/10
I will never build an enterprise app again with React, the ecosystem is too weak to give you guidance, best practices, design patterns, and stability over time. The fact that everyone is suggesting to use a redux store to keep the state is a red flag. How many redux library exist for React? every developer solves a problem in his way, it could be fun for the developer, but for the manager or stakeholder is not. Very expensive to maintain and develop over time. The code become spaghetti very soon.
7/10
I think Svelte is a step between React and Angular. It could fit an enterprise application, but I will not go all-in on it. Try to build a Proof of Concept (PoC) and see how it works for you. Rxjs in this case is mandatory.
Fit as simple app 4/10
One of the weak side of Angular: very tough to setup.
10/10
Yep, super easy. Super small footprint, super fast. Adobe is using LIT to build Photoshop in the browser.
8/10
One of the frameworks I could use to build a simple app, few simple components, no big forms, no complex business logic, but only if the stakeholder can confirm it will never grow. Otherwise nope, too risky.
9/10
Yes, just use it.
Data intensive applications 8/10
As Angular has a good support for typescript, forms and validation, it should be pretty easy to manage data intensive applications. You can also find many battle-tested Datagrid that can skip you the huge task of writing one. Do exist also many tools to generate data contract from Swagger.
6/10
You could create many web components that wrap controls, and orchestrate the data flow. Maybe you want to look in Vaadin (and others) components.
4/10
I will stay away, too weak typescript support and cumbersome form and validation support.
6/10
I don’t think it’s built to manage huge forms and validations. It could be technically possible, but I will suggest to look in something else, like server-side frameworks as ASP.NET Razor Pages.
Integrating in existing apps 4/10
Not designed to be used in existing applications, but they are working in this (experimental support started from Angular 14)
10/10
Super easy to use, just include a JavaScript file and you can start to use your web components.
8/10
It should be pretty easy.
10/10
Yep, you can do it in 5 minutes.
Unit testing 9/10
By design completely unit-testable, it was one of the main goal in building Angular as it is.
9/10
Very easy to unit test your web components, attributes, parameters and events.
6/10
How can you unit test the TSX code? I saw too much code in TSX to believe developers will separate html to js. Then you are forced to test the html directly, not really a good idea in a keep-moving real application.
TBD
Strongly typed forms 9/10
Built in strongly typed forms (from angular 15). Array of checkbox, or array of components, are not easy to manage yet.
7/10
It’s pretty easy to bind to your elements, but out-of-the-box form support should be improved. I haven’t used much, so maybe it’s better than I think. Just check another time.
5/10
Basic support built in, for real apps you need to use external libraries which I found very complex to use, and the code became a mess of refs around. And in the hope the developer will keep updating and fixing the issues for your  application lifetime. One of the most used libraries is React Hook Form.
6/10
Thanks to the good typescript support it should be possible, but I don’t think it’s built in, you need to write your own wrapper.
Form validation 10/10
Built in validators, provide interfaces to use your custom components part of the form validation life cycle.
7/10
Not built in, that I know.
5/10
Not built in, you need to handler everything yourself. A better choice is to use an external library, hoping it will works as you want and it will be updated for the same timespan of your application.
6/10
I don’t think it’s built in, you need to write your own wrapper.
Established pattern (Team scaling) 10/10
Well defined patterns, services, dependency injection, official best practices for naming etc.
8/10
Yes, very easy to follow, but requires a bit of care from the developer. Pretty easy to mess up with attributes, parameters, and so on.
3/10
No rules. Someone think it’s good, I think it will drive to a big mess, especially with junior developers.
6/10
Also here, for me is between React and Angular. The native reactive support could raise to big problems with junior developers.
Long-term support 8/10
Google keep updating Angular with latest tech and browsers needs. Pretty easy to update to never version with guidance to fix breaking changes, + automatic code migration thanks to schematics.
8/10
Google has string focus on LIT and it’s used internally. Small API surface and they provide guidance, even if basically they provide well established pattern.
4/10
You are following Meta’s roadmap. I don’t see a constant development as I see on other products.
6/10
Big question here. I hope it will stick for a long time. the adoption rate is stable, after the hipe is still not too much used, but it’s backed from a private company, so until they are in business you should be safe.
Community 6/10
I don’t see a real community around Angular, but many companies that share they knowledge mainly to sell consultancy. But maybe it’s just me that haven’t found that community yet.
9/10
Very good community, best I had experienced, they support everyone in a very short span of time, provide guidance, open to feedback, teach latest css/js stuff. Sad they switch to Discord (that I didn’t want to follow), the Slack channel was marvelous.
6/10
I’m not aware of a community, I see just a lot of developers trying to avocade it, mainly because they are juniors and want to share what they are learned. Mostly to share their name to sel consultancy. The knowledge level however is pretty low. pretty easy to follow the wrong guy that just started a week before you.
6/10
I found a lot of outdated blog posts and people speaking about it, stack overflow questions, etc, unsure about Reddit and Discord.
Virtual DOM 8/10
Yes, but it’s not a problem as it was many years ago with AngularJs (performance wise).
10/10
From my understand it’s not using Virtual DOM, but directly Shadow DOM and template literals. Basically super fast.
8/10
Yes, but it’s not a problem, just stick with their best practice: specify a key for each list, keep looking to the warning in the console, use a React linter.
10/10
Main Svelte purpose was to get rid of the virtual DOM. It generates just plain html and javascript, no virtual DOM, so it’s just fast.
Routing 5/10
IMHO one of the worst part of Angular. Very complex to route for very simple scenarios. They should absolutely improve this side, one of the biggest blockers for new users. Master-detail routing is just rocket science. Very good support for lazy modules, on the other hand.
8/10
Not built-in. Easy to use routing libraries available, like vaadin-router, and within @lit-labs they are working to an official router.
8/10
Not built in. Easy to use routing libraries available, maybe the most common is react-router. I haven’t worked in a big enterprise project that requires complex master-detail routing, so I’m not sure how good it is. For easy routing is super easy to get started.
7/10
It has his own way to do routing, based on conventions (unsure about complex master-detail scenarios).
NB. I needed to integrate Svelte in an existing MVC application, with existing routing, hence I needed hash-based routing. So I used svelte-spa-router – and not the built in router. It just worked fine.
Single responsibility/separation of concerns 10/10
Very well established patterns. It’s very hard to mess up (although still possible with junior devs). A component is made be many files (html, ts, scss, test) so it make pretty “hard” to split a component in smaller dumb components. Usually an Angular component is bigger than it should (or could) be. I think they are working on improving this, starting from Angular 14.
8/10
Pretty good support to design patterns, take a look to the docs before starting to write code.
5/10
I like how functional components allow you to split in many small dumb components. The difficult part is to keep the not-UI logic in good shape. Apart simple custom hooks, I never seen a way to have complex logic well managed.
6/10
I don’t like the Svelte way about mixing Typescrit, html and css/scss in the same file. Reactive stores are not very well scalable IMHO. I keep looking in a better way to organize code.
Web components support 8/10
Angular supports web components, but it requires you set CUSTOM_ELEMENTS_SCHEMA that will remove template check (and then allow to write invalid bindings). A best option is to wrap them in a dedicated module, but requires extra work. Still manageable, though.
9/10
I’m unsure how well it integrates with other web components (like vaadin, and others), but it should just work. Haven’t tested personally but I don’t see any problems.
5/10
React had in the roadmap to integrate with web components from many years. They never did.
8/10
Unsure about it, but it should just work.
Web components library 8/10
Pretty sure it supports web components out-of-the-box, but I don’t think it’s a good idea. Just use a dedicated tool (like LIT).
10/10
A dedicated framework built for this. It just works.
4/10
I don’t think it’s possible.
9/10
It supports web components out-of-the-box. I have used them, but my feeling is that it should be a very good fit.
Use to build/share a Design system 4/10
I don’t think you can build a Design System, you can build Angular libraries but I’m unsure about multi-technology support.
10/10
Built for this purpose. It works very well. With shadow-dom you can control how a consumer can customize your components. For the consumer is super nice to use because they do not need to care about messing up with the component’s css. Using slots and events also give you many ways to connect to the components.
4/10
It’s a very bad idea to create a Design system using React: it can be easily used only from other React projects. Just use the right tool, LIT as example. I saw many React Design System been built, and never used either than the team who built them.
9/10
If you generate web components with Svelte than is just fine, as with LIT. If you instead want to use Svelte native components, then it’s like Angular and React, just don’t do it.
… what should I add here, any suggestions?

Reactive Programming and RxJs

One special mention about Reactivity support (rxjs here). I’m a big fan of functional reactive style. In SPA world it is achieved mostly by Rxjs.

Rxjs is just an implementation of the Reactive library by Microsoft published many years ago, that get inspiration from functional programming and other stuff.
Reactive code is also available with other techs and not only in SPA, as example in Desktop and Mobile native applications via ReactiveUI in combination with the MVVM pattern. The code written there just shines. Super easy to build very complex logic, and super easy to follow who-did-what. It removes completely the spaghetti code we were used in the past.

Is Reactive code easy to learn? No. Is it worth it? Yes, absolutely. Can someone start to write Reactive code without “studying” it? Absolutely no.

This is the biggest problem I have seen in my programming experience with other people.
As example React developers that jump to Angular (because they are forced to do so) and who want to start to write code without reading the documentation or studying the best practices.

What they do then?

They write Javascript-style code mixing Rxjs. What a mess. And then they say that Angular is crap.
I think instead that these developers are not professionals. Why? Because when I start to use a Framework or a technology, I start reading the docs and trying to understand the patterns and best practices. It’s boring, maybe frustrating at the beginning, because you don’t feel very productive, but that is our job.

Very few developers spend time learning a framework, they just come from their studies – were they learnt Object Oriented Programming (OOP) imperative Javascript basically – and they think they are done.
So in my opinion the problem is not Angular, the problem is the developer.
Once I worked with a colleague complaining that it was challenging to write html-angular code, and React/TSX was much better. Then I found out he didn’t have the official Angular VS Code extension. Really, yes. Then he said “oh, much better now”. So I started to wonder what he was actually doing. I read his code, found a big ball of mud, and taught him rxjs basics. After few months he realized he wrote a lot of crap. I spent months fixing all the bugs he introduced because of side effects and imperative code. I hope that now he is a better developer and he has learnt also the power of reactive code and unit testing, too.

So what I what to say is that is pretty common to find people that complain about a tech, but they never tried to learn it. Hence, check who is giving you feedback about a tech, and exclude who is not deep in it (or tried to learn, at least).
If you use YouTube or blogs to learn new stuff, keep in mind that in my experience 90% of the people is just a Juniors, with low/medium experience, maybe passionate about tech, that want to express themself (that is a good think IMHO). But usually they don’t have any clue about what they are saying, because of the missing experience. So keep it with a grain of salt.

I see now a trend with people learning Svelte – that has a basic reactive support – very surprised about the reactivity power Svelte bring to them. And they now suggest to complement Svelte with RxJs.
Hey, it’s at least 10 years reactive code is out there, and RxJs is basically built-in in Angular, why now is it a good thing? 🤔

So I think that also Angular will get more momentum soon, as they will find that RxJs is good and Angular has also a native support.
I also think that many will found out that React is in his descending phase, as their programming model is pretty outdated and need a lot of energy compared to what rxjs can give you for free. Many Junior start with React just because is the most used, and pretty easy to learn. It’s a pretty obvious thing to do if you want to learn a tech that can give you a job soon after your studies. But it should be just a start, not an end! I don’t think a big app can be written in React. You can find many who shared their experience about this topic.
For example have you ever tried to build a complex pipeline with React, hooks and effects? Then you need a Redux store, that has a huge complexity and boilerplate code. Then why not going to a Rxjs Observable data services (also known as store services) pattern? Just put together few Operators and voila, you get super easy to write, read and to maintain code. In my experience Redux (all of them) is just evil.
I hope to see this trend soon.

Add a Comment

Your email address will not be published. Required fields are marked *