Why I love React and some other description to make it very long

I've been using and teaching React since 2014. Back then we all knew it was special, but I don't think any of us could have predicted the growth and impact it would eventually have on the JavaScript ecosystem. In this post, I hope to break down why I personally love React as well as what I believe have been important factors to its success.

You're probably familiar with the idea of taking individual functions and composing them together to get some value.

Now, what if instead of composing functions together to get some value, we compose functions together to get some UI? Sounds a little strange at first, but this idea is foundational to what makes React so powerful.

Because composition is a language-agnostic programming principle, regardless of what programming language you have experience with, the same intuition you have about building and composing functions together can be directly applied to building and composing React components together. On top of that, by bringing composition to the UI layer, the same benefits you typically see from composition will now directly apply to your UIs.

Another benefit of component composition is you naturally get a vibrant ecosystem of third-party components. At this point pretty much any type of React component that can be made as a third party component has been and is available on NPM.

To get your brain thinking this way, here are some example components that you might build or download. React really is just Legos for developers.

A big part of building predictable and robust applications is knowing when and howstate changes. If you're coming from a jQuery background, you may be familiar with the following scenario. You start building your app, and everything is fine. You have event handlers which are responsible for updating the state of your application (which lives in the DOM, primarily).

Then your application starts to grow. Slowly each event handler gets tasked with updating more and more pieces of state. What once was nice and predictable begins to look more like this.

As you can imagine, relying on shared mutable state is typically a bad idea. React takes a different approach. Instead of the source of truth for the state of your application living in the DOM, it lives inside of your React components. From there, you can explicitly decide how and when the state should change as well as what the UI looks like based off of that state.

An interesting way to think about this is that your UI is just a function of your state, **UI = fn(state)**.

One thing I glossed over with our jQuery and React examples above is exactly how the DOM gets updated. With jQuery, you're responsible for writing the imperative code to update the DOM. That typically ends up looking something like this.

With React, however, that responsibility is abstracted from you. Instead, React allows you to describe what the UI should look like, not how it gets updated. In other words, when a component's state changes, React will do the hard work of actually updating the DOM. This process lowers the cognitive load of building your application since you only need to worry about 1. how the state in a component changes and 2. what the UI looks like based off that state.

For further reading, see Imperative vs. Declarative Programming

This one's a bit controversial, but I still hold it to be true. Generally speaking, if you're already comfortable with JavaScript, you'll have an easier time picking up React. There are two reasons for that. First is that the surface level of the React API is pretty minimal. There's not a whole lot of API that you need to remember. Second is that React tries to not re-create functionality that you can already do in JavaScript. For example, say you had an array of **friends** that you wanted to loop over and show to the UI. In some front-end frameworks, there would be a special API for this. For example, in Vue, you would use their **v-for** directive.

With React, you'd use JavaScript's **.map** method.

Neither approach is "wrong" or "bad," they simply prioritize different things.

React is such a good idea that we will spend the rest of the decade continuing to explore its implications and applications. - Guillermo Rauch. CEO Vercel.

Part of what makes creating abstractions difficult is, by their nature, they have to be opinionated. The right abstraction should empower the user without getting in their way. It should simplify how you think about a behavior. It needs to allow for an almost infinite amount of use cases all without leaking its implementation details. React does all of these things, gracefully.

The proof is really in the types of applications and even tools that have been built using or on top of React.

• Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps.

• Styled Components are "Visual primitives for the component age".

• Next.js is a JavaScript framework that lets you build server-side rendered, static web applications using React.

These are just a few examples, but there's a reason entire industries are being built upon React.

An underrated aspect of the React ecosystem is the welcoming community around it. From educators and OSS devs to newsletters and conferences, there's never a short supply of helpful developers willing to lend a hand.

• React Newsletter

• React Subreddit

• Reactiflux Discord Channel

• Conferences

Last but not least, Facebook continues to invest heavily in React's development and in my opinion, the current React team continues to innovate and prioritize the right problems.