Why React?

React embraces one-way data flow. You build a tree-like structure of components each of which is configured by the props passed to it by its parent. Each component is a function that runs again every time any of the props change. Components also have the ability to manage local state, which is simple in some ways but handled poorly can lead to a lot of complexity. React doesn't give you a lot of guard rails, but it does give you a lot of power. You can tell the best React developers by how they handle state and side effects.

Most of your components in a React app should be pure functions, meaning their output for a combination of props should be the same every time. This makes testing extremely easy, although YMMV depending on how you structure your app. React lets you write lots of cheap and almost unbreakable lego pieces that you can assemble into larger blocks of functionality.

I haven't used your stack, but my main benefits of React are:

- People will pay me to build with it

- State - Update a value and all the places that uses the value get updated without any extra fiddling. If your pages are very dynamic or uses lots of use interaction you skip a lot of complexity

- Components - All components end up in their own file, adding reusability and clarity to the logic

- NPM packages - Easily add extra functionality

- JSX - It's a delight to write "HTML" and embed variables and functions directly where you need it

When you have 20 teams building all kinds of features, React is a common, familiar platform with re-usable components. Teams can interchange smoothly, good for retaining and training employees. Well supported, large community, standard testing, a11y, security updates.

For small, one-time projects? Use whatever makes you and your client happy. Just be aware it will be outdated in 5 years, so who will maintain it?

Huge HTMX fan but there are some things that just going to be easier to build with a real SPA. For example not going to be a great experience to build spotify using just alpine and htmx.

The standalone React library is okay. The virtual dom is not that necessary to do frontend, but it's at the core of what React is adding an extra layer of separation between the DOM and React concepts. But other libraries have shown that it's not that necessary.

The issue is the ecosystem. There's a lot of complicated architectures out there which only apply in esoteric context. Another issue is with the tooling. More often than not, we have templates that advertises making things simpler, but instead promotes complex and complicated tools that you should not add to your codebase.

But more often than not, you only need to update the content of your web app, and do a few changes to the layout. For that you don't need a full blown frontend library. React shines when you want to do web applications, not websites. But they're all pretty much the same when it comes to the latter. htmx+alpine and the other similar solutions are better when you don't want to control the whole UI. But need to add interactivity to a few select place. Which is the majority of websites.

This is similar to asking why Unity for a 2D game when something like SDL/Pygame/Love2D will work... sure it will and probably will be much cleaner for smaller, simpler things but I couldn't phantom building something with a lot of interactivity, popups, drag and drops, interaction, etc. with just HTMX and Alpine, and you get a massive ecosystem of UI libraries with premade theming, etc. Plus now React has NextJS which also gives you backend and SSR capabilities into one cohesive solution.

htmx looks really cool to me and I probably would chose it if I were to build something like Hacker News with little interactivity where I just need to show a few things reactively, but it's just not the right tool for all applications.

Even if you build something simple and small you can use a small subset of React without any complex frameworks or libraries, just as a single library, and it will work fine and won't be too complex.

Disclaimer I have not used React extensively although I did work at my dayjob with Vue which is very similar.

My answer would be the ecosystem, let's say you've to implement a note editor, a calendar and a dnd module and what not. You move fast because it has already been solved. And you don't reinvent the wheel.

Also have a look at the frontend iceberg there's a lot more to frontend systems.

I don't use React much but you are asking a question that was asked of Angular when react came a decade or so ago. Before that, people have always been asking "Why JQuery when you have angular etc"

It is just a matter of time before someone goes "Why HTMX/Alpine ? Now we have this "

Point is that the JS ecosystem is always coming up with new stuff. And there is a use case for all of them, React included.

My preferred stack is nextjs (react based) on the front end and either Django or fastapi on the backend. React allows you to build mvps really fast, handle states very well and has a lot of hooks you can use.

The downside to this is it makes code heavy sometimes. I use nextjs because I love the server side rendering and seo optimization it provides and use the client components (traditional react) to manage state.

To give the user a responsive and offline-first experience and also to scale infinitely without the need to provision a server for it - don't use nextjs! If you use nextjs every advantage is gone so it would be better to stick with django

With react you can get paid 2x more if your employer has react. That’s about it. Otherwise any modern framework will do, just use what has enough stars and less than 2-3 major versions in last few years.

Do you (like someone mentioned in the comments) plan to build something with the complexity of Spotify or Gmail or Facebook? And don’t have a team of dedicated front end engineers? If this is the case, React is for you.

It just works and is closer to programming than writing god awful html.

I just always try to master the most popular tool of a given area first before I start exploring around. Call it a generalized Chesterton's fence.

React happens to be the most popular tool, and I find a lot to like about it.

I am (mostly) a backend developer - so I deal with languages like C#, communicating with databases like MySQL, SQL Server, etc.. and sending data back (to things like) the frontend, such as HTML/Javascript.

Despite this - I can do frontend development as well - but I have reached a point where I cannot be asked to learn new Javascript framework or libraries. Personally I just think it has become bloated, so I leave that for those that do know/understand.. like full-time React developers. I cannot be bothered as I am sure some new toy will come out in the next few years and replaces it.

My opinion... and I understand it is apples and oranges... is web development could be much easier than it is today. Back in '00s we were using old school PHP or Classic ASP to return compiled HTML content and, mostly, full screen refreshes. Eventually, Javascript gained more responsibilities giving us JQuery. We had simple GET and POST functionalities, allowing us to refresh part of the page, etc.

By around the 2010's I remember KnockoutJS and, eventually, AngularJS. Web development was changing and I accepted this. While I saw some benefits with auto refreshing hooks or the like.. the end was a lot of bloat... more lines of code. Some of which is duplicated in the frontend as well as the backend.

Between 2016 to 2021 I stopped web development. I started a job as a GUI application developer. When I returned to web development I am now seeing Node being used... Grunt being used... with some websites sticking to JQuery while another is using React. I am in shock at how complicated things has gotten!

To me, with my years of experience, feel like I am going full circle back to the old methods of web development... just with modern tools! I leaned back to jQuery for personal projects. It is easy to follow (in my opinion) -- but I came across HTMX in 2023 and really enjoying it!

Using HTMX, With odd exceptions, my javascript code is mostly a compliment to my CSS. The amount of code is reduced by 60-80%!

Since then I have started using HTMX for web projects at work -- with positive feedback from the team. We are, one by one, moving our projects over to HTMX. It is just easier to deal with.

Our team only has half a dozen developers. We are mostly backend devs but OK with react. Some are better than others. We have agreed that with HTMX we are getting things done a lot easier. We no longer have to bother with the additional layer that is React. We also stopped using jQuery.

Now I am not suggesting HTMX replaces React for all cases. Its just, for our use cases, it has done the job remarkably well.. and we are doing complicated web sites.

Having a team of React devs may be needed in a number of scenarios - I, thinking of all websites I have built over the last 20 years, struggle to find one.

There is a saying that is going to offend, but I think those that dislike or hating on HTMX are those that have invested their time on (things like) React. I also hear that HTMX guys are like a cult. That might be true to a degree. I am sure some will suggest I am one of them with this comment.

- React creates jobs, but HTMX gets rid of them.

You came late to the party, but in short, yes you are right: you can skip the excesses the frontend-world got into and use the minimal needed tools to do the job. Every line of code costs time and money, but do not try to explain that to a Typescript/React-fellow or Angular-Fanboys.

because: https://reagent-project.github.io/

Complex and heavy UI - that's why basically.

Main reasons for me:

I know it. It is good enough. It is fast enough. DX is good enough although edges are prickly in functional/hooks. Massive 3rd party support. Does everything from simple to SPA that could make Slack work for example without a tech switch.

I'm a self-taught programmer too (and a web dev of like 15-20 years)... can give you one opinion (and that's all this is).

IMO it's important to discuss two related but separate things:

1) Why an interactive frontend at all? IMO this is the more important question, and basically boils down to "AJAX enables better UX since you're not refreshing the entire HTML on every page load". It's better (in theory) for end-users because actions and screen loads should be a lot quicker.

But that's only relevant when comparing to serverside frameworks (like old PHP, cgi-bin stuff, old government websites, etc.). Most modern frameworks have moved to this model, and even the old PHP stuff uses it piecemeal.

That answers the "why a frontend framework at all" question, but not "why React" specifically, when Alpine/Vue/Svelte/Anything Else can do a similar job.

2) My answer to that is simply "momentum", and that's because of history. React did what AngularJS (v1) tried to but could not: gained critical mass. For a while there, it was the only major option for teams that wanted to build an enterprise-grade frontend that could be easily shimmed into their existing backend, without the overhead and overcomplexity of Angular. React then was more of a UI library than an actual framework like Angular, and so you could jam in React anywhere you needed it, but leave it out where you didn't need it.

(These days that's of course changed with frameworks on top of React like Next.js, which adds a lot of features and preconfiguration for a one-click deploy.)

But I don't think those features are why people choose React for new projects. It's again the sheer momentum of React. It's here to stay, it's well-supported, it has a huge ecosystem, and – importantly – it's easy to hire and train for. It's the most popular standard for the time being.

You can hire any off-the-shelf React dev and they can start working in your recent-ish React codebase (especially if it has no older-style class components anymore) without much additional training, because they can take your existing state object and easily build a new component on top of it and make a workable screen. But it's not just that... it's that they can move to another team, and they're probably using React too. And when they switch companies, it's probably still React. It's a skillset that has a moderate learning curve (it's really not so bad if you spend a few days on it) but then can keep getting reused at many many places and career opportunities.

By contrast the other frameworks might have many of the same important features, but they're nowhere as easy to hire for, and there's no guarantee of their future popularity/sustainability. The JS frontend world moves really really fast, and there was a period a few years ago where entire frameworks and languages (CoffeeScript, Backbone, Knockout, Ember, and of course Angular) came and went, much hyped initially but then quickly fell out of fashion in 1-2 years.

By contrast, React and Next is very firmly entrenched now and probably will stay that way for a while; they've become the Wordpress/Drupal of the frontend world, the "good enough" default option that many teams will default to.

Of course individual teams can evaluate different frameworks and choose the one most suited to their needed complexity level, but if you don't want to think about it and/or want to maximize the chances that your codebase will still be maintainable by a new team a few years from now... it's probably gonna be React. Not because it's the best, but just because it has too much momentum to die in the short term.

At a certain scale (small-to-medium-sized businesses), it makes sense to just use a "good enough" option that's widely used across the industry, because it's easy to find help for. When you're tiny (like a restaurant website or a blog or just a simple ecommerce company) it doesn't matter much because your codebase probably isn't complicated enough anyway to justify React, and whatever you do is probably going to be pretty janky anyway. When you're huge, you can design and maintain your own framework (after all, that's what Meta did with React). But in the middle, where most companies are, there's not really a good business reason to choose one of the dozen+ smaller frameworks when React will almost certainly do the job and there are so many devs for it. It's like "no one ever got fired for choosing React".

It could've been anything, really. There is no perfect framework, just frameworks that gained enough critical mass or didn't. Google really wanted it to be to be Angular, Microsoft wanted it to be .NET, but now everyone (at least in the US) just uses React. I think .NET is more popular in Europe. Once one of these frameworks gains enough popularity, it's really hard to altogether displace it. React got in at the right time, got enough critical mass, and the rest is history... regardless of its technical merit.

Because PHP sucks.