Why Do People Think React Teaches You More JavaScript?

Control flow is the biggest aspect here, yes.

If we set aside JSX syntax itself, which is mostly HTML-like, all control flow in React is done with normal JS syntax. List of items? items.map(). Conditional rendering? Ternary, if statement, or boolean someCondition && <MyComponent />.

There's no new template-specific syntax here for control flow. Like, look at the other major frameworks:

• Vue: v-for="item in items"
• Angular: *ngFor="let item of items"
• Svelte: {#each items as item}
• Ember: {{#each items as |item|}}

Four similar but very different syntaxes here. Whereas with React, if you know the normal JS array methods and loop syntaxes, you know how to render a list.

Another factor is that while JSX is how we all write React in practice, it ultimately is "just" calls to React.createElement() internally. If I see <MyComponent a={1} b="blah" />, I know that it becomes React.createElement(MyComponent, {a: 1, b: "blah"}). So yes, it's syntax sugar and does have its own particular quirks, but ultimately it's a very straightforward transformation and you could (in theory, although few people do it in practice) write an app with nothing but React.createElement() calls.

You can also point to React components being "just" plain JS functions, albeit ones that are called by the React runtime and given access to React-managed state and behavior.

Ultimately, a lot of the "React" questions that I see people asking, especially beginners, really are "JS" questions: how do I loop, what array methods should I be using, how do I destructure correctly, etc.

I think templates is the biggest aspect of this distinction, yes.

Agreed that there's absolutely a ton of React-specific concepts to learn even in just rendering a basic React component: props, state, hooks, JSX syntax, events, how React handles falsy values, etc. But, at its core, the "templates" vs "JS rendering" split is a huge divide.

Obviously you can do ultimately the same things with either templates or JS rendering, and there's pros and cons either way. Templates lend themselves to better static analysis of which pieces are dynamic and which are just static content, and can be friendlier for people coming from a pure HTML background, but force you to learn that specific templating syntax. JSX and JS rendering work better with TS in a lot of ways and give you freedom, but the ability to use any arbitrary logic makes them harder to analyze.

React devs typically fall on the "I don't want to be constrained by template limitations, and I don't want to have to learn special template syntax" side of the opinion divide.

I can't say I've ever heard anyone express a concern about a <MyComponent> not being visible in the page itself before. I can sorta see where you're coming from on that. Typically, I'd just look at the React DevTools. If you click on an HTML element in the "Inspector" tab and then click on the DevTools "Components" tab, React will highlight which component rendered that element. Also, the DevTools Components view hides DOM elements by default to avoid clutter so it only shows components, but you can toggle visibility of the DOM elements so that you see both at once in the Components tab (ie, more what you're asking for here).

Ah, yeah, the React DevTools are a huuuuuge aspect of using React.

I haven't ever used modern Angular, but a year ago I was moved onto a project using classic AngularJS 1.x. I knew enough about web dev to pick up how it worked overall, but I can tell you that debugging AngularJS 1.x is hugely frustrating specifically because templates are un-debuggable. I did find a browser extension that sorta lets you view some scope-related data, but it doesn't work very well. With React, I can click any component at any time, see exactly what its props and state are, and then trace that data flow through the component tree. That's an absolutely critical advantage and a key part of my development workflow.

The "how React works" aspect is completely separate from the DevTools themselves, but that mental model of "props + state + data flow = UI" is what helps make the DevTools useful. It's because I know how components render and how data flows through the tree that I can look at the DevTools and understand how the components relate to each other.

My opinions might as well be personal preferences but I want to chime in my 2 cents about the "why" I think, for me, React helped me know (I use know here instead of learn) more JavaScript since my reason is a little different from the Templating Syntax.

A little of context: I got exposed to Angular 2 when I first started then learned React for a project.

TLDR; React being a UI Library with its own way of doing things make a curious developer go out of their way to actually learn more about some fundamental JavaScript concepts to be efficient in React. It's not that learning React helps you learn JavaScript better but it's more like learning React will leave more opportunity for you to actually look into more JavaScript concepts.

When I was learning React, I found it was "less abstracted" than Angular. I'm talking about things like Forms, Router, HttpClient etc... In React, I had to go out of my way to learn these concepts, find libraries, read more about the libraries that I found to use it in my React projects. And most libraries are JavaScript libraries

That said, I'm not saying that anyone can/should use Angular libraries blindly.

Next is Closures. Yes, closures. I didn't really look into what it was when I first started with Angular because I (or anyone) rarely run into problems with Closures in Angular. In React, problems with Closures are more apparent that it forces the devs to go out of their ways to look into closures. (eg: setState, Functional Set State). Or things like Currying, an example of Currying is how to write Event Handlers. In Angular, it's just a class method. In React, you can have different ways. For example:

onClick={() => handleClick()}
// then you realize you can do this
onClick={handleClick}

handleClick() {...}

Now if I need to accept some arguments for handleClick(), I then learned that I can:

handleClick(arg1) {
  return (clickEvent) => {...}
}

Third, immutability. Again, another concept that the old-days Angular (before the Observable View Models/Reactive Pattern/Pull-based Architecture was mainstream) doesn't really have any problems with. In Angular, I can mutate an object or an array and the view will still re-render if I'm using the Default ChangeDetectionStrategy. In React, I had to learn about immutability. In turns, I then WANTED to learn about why immutability. Then this proactive curiosity opened up a whole new section about Shallow Comparison, Deep Comparison, Reference Equality etc... all of these are JS concepts and it's less of an apparent issue in Angular than in React.

To me, JSX is more like a React DSL in disguise. Now in Angular, you have HTML but in reality, the HTML will be compiled down to instructions in JavaScript. If we embrace Single File Component and using inlineTemplate with Angular components, Angular's inlineTemplate is not that different from JSX. If one person just think of Angular template, not as HTML, but as Angular specific syntax with Directives + Markup then it will be pretty much the same as learning JSX imho.

The illusion of having multiple files in Angular kind of makes it seems like Angular is so far away from actual JavaScript.

Yeah, I think that's another good point.

With React's ES6 class components, you had to know how this works. Now, that wasn't necessarily a good thing :) We had a seemingly endless series of questions about "cannot read property 'state' of undefined", etc, when people would pass around unbound class methods as handlers. So, it was definitely a forcing function that made people start to learn this, method binding, arrow functions, etc.

With function components and hooks, there's no more this, but now you really have to understand closures. Again, this isn't entirely a good thing either - we no longer get questions about this, but we get all kinds of questions about stale state and scoping. But yes, React's design really forces you to learn and understand some specific aspects of JS behavior. That's why a large portion of Dan's A Complete Guide to useEffect post is really just talking about closures and scope.

@Ben,

but, now I am wondering if they are reacting more to the modern Angular abstractions than they are to AngularJS in general.

I have a feeling that this is truly the case here. Thank you for sharing your perspective on this. I have been curious myself.

@Ben,

I'm amused that you bring up jQuery here, because to me this whole argument comes down to the same things people say about jQuery. In fact there's a whole website for that: http://youmightnotneedjquery.com/

When you're using jQuery, you're using JS, but you're not writing JS. You're writing a DSL that is meant to make the power of JS easier to grasp. Of course you'll write better jQuery code if you have really strong JS fundamentals, but it can also be a crutch.

The argument that React is more like JS than Angular (or the others) is that it's less DSL and more plain vanilla JS, which not only benefits from strong fundamentals but almost requires you to hone those skills in order to get your work done.

Especially now with hooks! It's "just" functions. Components are functions. Hooks are functions. And you can compose them together the exact same way you compose functions completely outside the context of React.

Yes, absolutely: JSX does add its own abstraction and looking at <MyComponent> and recognizing that it's shorthand for calling function MyComponent() does require some learning, but it saves a heck of a lot of repetitive boilerplate typing AND it's intended to carry over the familiarity of writing HTML.

I also see some humor in expecting there to be a <my-component> in the resulting output. Granted, that's technically possible with modern HTML (anything unrecognized is treated as a div) but SO OFTEN when looking at a large view we need to abstract out in our minds: "ok, this portion of the page is the widget picker" (and my preference is to use an IDE that lets me "fold" that code up)... What JSX and React's approach to components bring to the party is the ability to actually compose a UI from reusable blocks like that so that instead of needing to look at a giant mess of HTML and see the invisible dividing lines between interlocking components, you can see the interlocking components and, where you so choose, dive down into the implementation details of any individual component.

It's not perfect, but in my opinion it's the best way to write UI's today.

I feel like I'm the inverse of you: I've dabbled with Angular in the past and never really felt productive in it, but I write React all the dang time and can't imagine doing it any other way.

@Ben,

Actually I went back and had another look at your original blog entry here. And your title stood out to me even more than previously:

"Why Do People Think React Teaches You More JavaScript?"

It teaches you more JS because it doesn't hold your hand through things by giving you some other syntax. As Mark was explaining, the way to loop in React is to use an array.map. Instead of reinventing each tiny wheel, React lets you use the wheels that already exist. And if you don't know how map works, then you'll get introduced to it when you find some content that shows you how to output a list of elements generated from an array.

Angular doesn't teach you map, it teaches you ng-repeat.

THAT is why people say that "React teaches you more JavaScript".

Ben, having worked in both, from my and my team members perspective, Angular was doing something magical. Like you enjoy the magic and don't know what happened underneath. Deep inside you know its something scientific still you feel unexplained and get excited.
While working in React, you get to know the scientific stuffs more.
Listing couple of examples below

1. Higher order components
2. Usage of yield functions if you come across Redux saga for state management in React

As you know the above listed ones are not specific to React. Those are patterns in JS. So usage of such patterns make you as a developer feel a bit close to JS.
These might be our knowledge limitation. But just wanted to give you all a view on how an average developer might think.