- As a professional web developer, I do work a lot with React, Angular, Vue, and similar
libraries and frameworks, especially since I do a lot
of front-end web development. And of course, I also got
some bestselling courses on those libraries and frameworks. And therefore, it's only
natural that I often get asked what my personal favorite
is and which library or framework I would recommend
to learn or to focus on, for example, now that a new year started. And therefore, over the next minutes, I wanna give you an idea
of what my favorite is and why that's the case, and I'll explain why it of course depends,
as it always does, which framework or library
you should focus on, but I'll also explain what it depends on. And therefore, I'll explore
the different philosophies behind those different frameworks. I'll explain who owns
and runs those frameworks and libraries and what that means for you and why that should influence your choice, which library or framework
you are going to use. And I'll also take a
look at the popularity, the numbers, how often
those libraries get used. I'll of course also give you an insight into how performant those frameworks and libraries are and if that matters. And I'll of course also
explore how easy or difficult those different libraries
are to learn and to master and to become better at
before I then, as promised, also let you know what
my personal favorite is. Now, let's start with the
different philosophies because that's really important. We got all these different
libraries and frameworks, but they don't all have
exactly the same philosophy, the same way of working,
and the same approach towards the idea of giving
you a tool that you can use to build web applications or
front-end web applications. For example, React, which arguably is the most popular library,
and I'll get back to that, React has the approach of being a library that's focused on managing the UI, updating the UI based on your code. And that sounds pretty
trivial, and it sounds like what such a front-end
library should do, and that's probably why React does it, but as you will see, for example, Angular does way more and
has more built-in features that can come in handy. React, on the other hand, in its core, is really just
about giving you the tools you need to derive state,
derive changing states and update the UI
accordingly so that you can, for example, listen to
a click on a button, then change some internal
data and then reflect that changed data on the screen. Now it turns out though, that in reality, most front-end web
applications you are building need a bit more than that. For example, they might need routing. So the capability of managing
different URL paths and displaying different
pages for different paths. Now, when I say pages, I, of course, here in the context of those front-end JavaScript libraries, mean that we're technically
still on the same page. We're still on the same HTML file that was originally
downloaded from the server, but the front-end JavaScript
changes what's visible in that file, so to say. So what's visible on the page. That's how single-page applications work. And even though they're called
single-page applications, because we have just this
one single HTML file, which is downloaded initially, those applications still
typically, very often, need to display different screens, different pages if you
wanna call it like this, so that we can, for example, view a login screen, and
once we are logged in, we might wanna move on
to a dashboard screen. And it would all be handled
by the same JavaScript code that's powered by React, for example. Now, React, however, doesn't have any built-in
mechanism that would watch the URL and would navigate you
from /login to /dashboard and display something else on the screen. You would have to build such
a functionality on your own, or what you would typically
do, you would reach out for a third-party library. For example, for React Router, which is a super popular
routing library for React. But that's the philosophy of React. You have just the basics built-in, and you then need extra
third-party libraries, which are not maintained by the React team but instead, by the React community to solve certain specific problems. And routing is a pretty common problem, and it has a very well-maintained library that solves that problem, but of course, there are multiple problems you might wanna solve. Advanced animations, form handling, advanced state management, and a broad variety of other things. And for all these different
problems, when using React, you need an extra third-party library. And that, for example, is different when you are working with Angular. Angular, unlike React,
is not just a library, which focuses on the bare
minimum, but instead, Angular actually is a framework that comes with batteries included, you could say. So it comes with many crucial features, many crucial solutions to
common problems built-in. For example, Angular has a
built-in routing package, which is developed and
maintained by the Angular team. So the same team that's
maintaining and developing the Angular core framework itself, the core library, if you
wanna call it like this. And there are many other
packages that are developed and maintained by the Angular team. For example, you have a
package for animations, for handling forms and
validating forms, and so on. And that's simply a different approach, a different philosophy. Now Vue, for example, is
a bit between those two, you could say. In its core, Vue is like React and focuses on just updating the UI. But Vue then has a team
of core maintainers where some of those team members
are then also responsible for some important third-party packages, which are only kind of
third party, I would guess, because they are, in the end, developed by those Vue core members and maintained by those members. And therefore, Vue does not
just have that core framework, but it also has some
crucial extra packages like a routing package that are maintained by some of the same people that are working on the core framework. Now, for other libraries
like Svelte or SolidJS, things are kind of similar, you could say. There, it's also some core members, some core members of the
Svelte or SolidJS teams, if you wanna call it like
this, that are also working on crucial third-party
libraries or extra frameworks that are building up on Svelte and SolidJS to offer features like routing. And that's actually an important topic. Frameworks building up
on those base libraries and frameworks, which
might sound weird at first. Why would we have a framework that builds up on React, for example? React itself is already a library, so why do we have some extra
framework that builds up on it? Well, we do have such frameworks, for example, Next.js but also Remix, because remember, React itself is just that basic thing
that handles UI updates. Now, recently, over the last one and two years, we've seen a huge trend where we seem to be moving away from building decoupled
front-end applications, single-page applications
with React or Angular and so on, and extra back-ends, extra REST APIs, for example. We seem to be moving away from that way of building web applications back to building full-stack applications. So where you have one
project where front-end and back-end work together
seamlessly and blend into each other, where the
server side pre-renders the front-end pages on the fly
on the server, for example, where the data for those
pages is fetched directly on the server and
rendered into those pages on the server, and so on. We're seeing a trend
where we're moving more towards that world again, which I guess is the world we're all coming from, back from our early PHP days and so on. But that's a topic for a
different video and talk. Anyways, we have that trend, and we have, therefore,
frameworks like Next.js or Remix for React, which
simplify the process of building such full-stack applications. So which allow you to build
full-stack applications with React by essentially
wrapping React, that core library, and by then giving you extra
features that allow you to set up routes that are
handled on the server, extra features that help
you with data fetching on the server, and so on. And Next.js and Remix are some really big, popular JavaScript frameworks. They are both for React,
and they're both key drivers of that trend, you could say. And I'm emphasizing this here because this also is an
important consideration to make when choosing a library or framework. If you wanna build such
a full-stack application, if you wanna follow that
trend, which has its merits, you might wanna pick a library that has some decent meta frameworks, as they're also sometimes called, that allow you to build
such full-stack applications in a simple and easy way. And for example, Angular
here only has Analog.js. And I'm saying only because
Analog.js is an amazing project, but it's also less mature, less feature-rich than
Next.js, for example, which makes sense because Analog.js is essentially developed by one person, whereas Next.js is
developed by a huge team working at Vercel, which
is a hosting provider. And therefore, since
we have only Analog.js, which is a bit less capable than Next.js, for example, if you wanna build such seamlessly integrated
full-stack applications with Angular instead of React, that could prove to be a bit trickier, and that might be a
reason for picking React. Now, for Vue, for example, things are different. There, we have another meta
framework built for Vue, which is called Nuxt, which is essentially the Next.js of Vue. I guess you see the similarities. Nuxt, Next. Yeah. It's a framework that
was developed for Vue multiple years ago already. It's developed by a big team. I think they even have some
venture capital funding, and they are building that meta framework, which allows you to build
full-stack applications for Vue, or with Vue. And that of course means
that if you wanna build such full-stack applications, Vue can be an attractive choice. Now, what about smaller
libraries like Svelte or SolidJS? And by the way, I know
that there are others, but I have to stop somewhere. Well, those smaller libraries also have such meta frameworks, which are maintained by the
developers and by the teams that are working on the
main libraries as well. Svelte has SvelteKit, which
is developed by the same team that develops Svelte, and
SolidJS has SolidStart, which is also such a full-stack framework that's developed by the
same team and person that works on the main library. So there, we also have
those full-stack frameworks. And that, therefore, gives us an idea of the different philosophies
of those libraries and frameworks and how
you can work with them. Now before we take a
look at their popularity, which might also matter
for various reasons, let's take a brief look
at who owns and runs and develops those libraries because that, of course, matters since
when you're choosing a technology, you wanna be sure that it will still be
around in a couple of years. You don't wanna rewrite
your entire application in two or three years just
because the technology, the library or framework you
chose today is outdated then. And here, to start with React again, that was originally developed by Facebook, and it's still owned and
maintained by Facebook. But recently, a part of
the team working on React has actually moved to a
different company, to Vercel, which is that hosting
provider that also developed the Next.js framework. And we can see the impact
of this because recently, the focus seems to be
on working on Next.js and making sure that React
works well together with it, but I did create a separate
video on the current state of React on my Academind YouTube channel if you wanna learn more about that. The main takeaway though,
is that React is maintained by teams that are
employed at big companies, at Facebook, for example, and that those companies
are using React internally. Therefore, it's pretty much guaranteed that React will not just be around today, but also in the future. Now it's pretty much the same for Angular because Angular is and was
developed by a team at Google, and it's getting used by Google in dozens, or, I guess, hundreds of internal and publicly available applications. If you're using a Google
service on the internet, chances are pretty decent,
that it's powered by Angular. And therefore here, it's the same. There is a pretty much a
guarantee that Angular, despite Google's tendencies
to kill its projects, will still be around in a couple of years because they're using it a lot internally. Now for Vue and SolidJS, it's a bit different because
both of these libraries and frameworks are indeed
developed by the community, if you wanna call it like this. Vue was originally developed
by one person, by Evan You, but it now is actually
maintained by a huge team of core Vue maintainers, if
you wanna call it like this. And therefore, it has a pretty stable base of developers working on it. Nonetheless, it's not a company, but instead, the community
that's maintaining Vue. And you can judge on yourself
if that makes you feel better or worse, or if that gives
you more or less security that Vue will still be
around in a couple of years. Personally, I'm pretty sure it will be. Now SolidJS is not
entirely a one-man show. It does have a lot of contributors, a lot of people working on it. There is a team behind it, you could say, but to me, it feels like SolidJS has less people working
on it than Vue does. For example, it's a smaller library. And for Svelte, there,
it's important to note that one person who
originally built Svelte is now supported by many core members just as it's the case for
Vue, and that one person, Rich Harris, is now
also employed at Vercel. So you could say Svelte
has kind of a company backing behind it. Not as strong as Next.js and React, but some company backing. And that is an overview
of who owns and runs those different libraries and frameworks. With that, let's finally leave that behind and take a look at how
popular those frameworks and libraries are because
that can, of course, also be an important decision criteria since you might prefer to
work with a library a lot of other developers are using as well, since it will be easier
to find freelancers for popular libraries, since the ecosystem might be more active, since
you might find more tutorials and courses and solutions
for problems, and so on. And here, it's probably
fair to say that React is the most popular
front-end JavaScript library. At the point of time
where I'm recording this, it has more than 200,000 GitHub Stars. It has around 22 million
weekly downloads on npm. So the React package is downloaded around 22 million times every week. And I looked up some
job postings on Indeed, but also LinkedIn Jobs. And there, you were able to find thousands of job postings looking
for React developers. On Indeed, for example,
when I recorded this, I found around 11,000
job postings for React, and I found even more
job postings on LinkedIn. Now, Angular is probably the second most
popular framework here, though it of course always
depends on how you measure it. But Angular has over 90,000 GitHub Stars. So way less than the 200,000
React has, but still. It has 3.2 million weekly npm downloads. So also way less than React. Though, at least to my knowledge, one reason for that also is that Angular is quite popular amongst huge enterprises, and they sometimes have their
own dependency registries, some internal dependency registries where it might be served from. But still, it's definitely fair to say that it has less downloads than React. And at least on Indeed,
I also found less jobs for Angular than for React. I found around 6,000 job postings there compared to the 11,000 of React. But on LinkedIn, on the other hand, I found more job postings for Angular. So overall, it's definitely fair to say that it's pretty popular,
and that especially if you're looking to find
a job for the framework you're using, angular has
lots of available jobs. Now, Vue then is a bit smaller
than React and Angular, though not necessarily at all
the metrics you could look at. Now, the Vue 3, which is
the latest Vue version, GitHub repository has
around 40,000 GitHub Stars. So less than Angular and
of course, less than React. But Vue had over 4 million
weekly npm downloads. So actually more than Angular. However, it definitely
had less job postings. For example, on Indeed, I found around 1,400 jobs
when I created this year. And that's less than the
6,000 or 11,000 I found for Angular and React. It also had less jobs
on LinkedIn, by the way. Nonetheless, Vue is definitely
a popular framework. And if you're looking to find a job, there still is a decent amount
of job postings for Vue.js. And these things change a
bit for Svelte and SolidJS. They are still popular if you
take a look at GitHub Stars. For example, Svelte has
over 70,000 GitHub Stars. SolidJS has around 30,000. So they are popular there. But for example, regarding npm downloads, we're looking at less than
1 million weekly downloads for both those packages. Svelte has 0.8 million, and
SolidJS has 0.2 million. So 200,000 weekly downloads, which is way less than
the other frameworks had. And the same is true for job postings. There, I was only able to
find a couple of dozen, maybe hundreds, of job postings, but not the thousands of jobs you found for the other frameworks. And that's therefore the popularity of those frameworks and libraries. Now, another important decision factor, of course, is performance, because you wanna choose a technology that allows you to build
applications that perform well, that deliver great performance to your website visitors, for example. And here, the easy answer
is all these libraries and frameworks are extremely performant. You will always be able to
find specific niche cases or scenarios or optimization that make one framework stand out, but the main takeaway really is that they all got great performance. You find a link to a website
that runs some benchmarks across those frameworks, in the show notes or below the video. But in the end, it really is the case that you got great performance
for all those frameworks and libraries, and therefore, performance likely will not
be the most important factor when deciding for one of
those libraries or frameworks. Though it of course can
be in certain situations. Now, what might matter though,
is the way you write code and if you like the syntax and the the way of solving problems with those different libraries because they of course all
have their very own syntax and their very own way of writing code that you need to adapt if you're working with one of those libraries or frameworks. They all share the idea of
composing your user interface from components, from
reusable building blocks that contain the markup
that should be rendered and the logic that
might alter that markup. But the way you then
write those components and the way you manage your state that leads to UI updates, that differs. With React, for example, you write JavaScript functions,
and you use a feature called React Hooks to manage
some data in those functions, which will re-execute those
functions automatically when that data changes and so on. With Angular, on the other hand, you're working with classes,
and you work with decorators and extra template files, and it tends to require a bit more
boilerplate code than React, for example. In Vue, you have separate files, a separate file format, you could say, where you put your
components, their markup, their logic, and their
styling into those files, and you therefore then write
neither functions nor classes, but instead, you use this
separate file format. And in the end, it therefore comes down to personal preference, which
approach you like the most. You should really just
give all those libraries and frameworks a try. And with that, I don't mean that you should spend
multiple hours or even days on learning those different frameworks, but instead, just go through
their quick start guides on their websites, look up
some tutorials on YouTube and get an idea of how
you generally write code when working with those
libraries and frameworks. And then decide which
approach you like the most because there really is
no right or wrong here. You will read a lot of
strong opinions on X, Twitter in the past, and
in the internet in general. But let's be honest, strong opinions, we always have them in
the developer space. We especially have them on X, and often it's best to
just not care about them. So make your own choice there and find out what you like the most. Now, what I can say though, is how easy or difficult
it is for my experience to learn these different
libraries and frameworks. Because even though it comes down to your personal preferences,
whether you like the way of writing code in a given
library or framework, I can see from all the courses I created that they do have
different difficulty levels when it comes to learning
and mastering them. For example, Vue is a
framework that's pretty easy to get started with. It has a syntax and an approach that's not too difficult to understand. It doesn't require a
lot of boilerplate code, and it doesn't have too many pitfalls where you can write wrong code
that won't work as intended. You can of course do that, but it doesn't have too
many of those pitfalls. Angular, on the other hand, is relatively challenging to learn, though that has gotten a bit easier in recent years or months, you could say, because Angular actually
is innovating rapidly and is introducing new
alternative features, which make it a bit easier
to get started with Angular since less boilerplate code is required. It still requires a
decent bit of extra code, but it's gotten easier
over the years, I'd say. That being said, not all Angular projects are using those latest features. So chances are that when
you're learning Angular, you'll have to learn the more complex way of building Angular apps at some point, at least if you're looking
to find a job with Angular, because chances are high that there, you're not going to use
all those latest features. React, for example, is a bit easier to get started with, I'd say, because initially, it has
a simpler mental model and doesn't require as
much boilerplate code, but React has quite a few pitfalls. It's relatively easy if you're
getting started with React to write code that
doesn't work as intended in certain situations,
and it can then be hard to figure out why that's the case. It's also relatively easy
to run into some errors, which can be hard to understand initially. So React is maybe a bit easier to learn initially than
Angular, for example. But when it comes to mastering React and writing good React
code, I personally would say it's at least as challenging as Angular, which also is challenging there. But they're pretty equal there, I'd say. And for Svelte and SolidJS,
they're somewhere in between. In my personal experience,
they're not as easy to grasp and work with as Vue might be, but they're also not
as tricky or difficult as React or Angular can be. But again, here also, my recommendation is that you simply get started with them, that you go through
those quick start guides, that you maybe take a course
like one of my courses or any other course, and you
therefore then get a feeling for yourself how easy it is for you to get started with a
certain library or framework. Because even though I can
see some general trends, it of course always depends
on which prior experience you have and with which
average technologies you might have worked in the past. And that's there for this
pretty extensive overview of those different
frameworks and libraries. My thoughts on those
frameworks and libraries, which hopefully were helpful. And therefore, to conclude this here, I just wanna share what
my personal favorite is. And I would say that this
would probably be React but not because I like the way you write React code the most. I actually don't do that. It's okay, but I'm not a fan
of all the advanced things you need to know about
React and JavaScript in order to write good code. But instead, I tend to choose React for most of my new projects simply because of its popularity, because there is this vibrant ecosystem that you can use to find
solutions for specific problems you might be facing
when working with React and because we have those
full-stack libraries like Next.js and Remix,
which are relatively mature, and which simplify the process of building such full-stack applications, which I tend to do a lot as of late. But that's the reason why for me. If you would force me to
pick one, it would be React. But I do honestly like all of them, and I do enjoy every
project where I got a chance of working with Angular
or Vue, for example.
