Skip to main content
Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.

Why Do People Think React Teaches You More JavaScript?

By Ben Nadel on

I don't understand it. Once again, someone with a good amount of community influence said that when you use the React JavaScript framework you learn "more JavaScript" when compared to other frameworks (Angular in this particular case). I've dabbled in React; and, I've been using AngularJS and Angular for the better part of a decade; and, I don't understand what it is that people in React are doing that is fundamentally different from the things that people in Angular are doing? I would like someone to help me understand this perspective!

Britney Spears looking confused.

NOTE: This post is not a dig on the people who say or hold this perspective. I believe that they believe it is true; and that there is something in React that "clicked" for them in a way that other frameworks did not.

The best that I can understand it so far is that people look at Angular's templating language and think that it makes it "less JavaScript". That they would rather use a .map() in their JSX file than an ng-repeat or ngFor in an HTML file. Or, that they would rather use an if in their JSX file than an ng-if or ngIf in an HTML file.

But, I'm just grasping at straws here; because, in both cases you're still using JavaScript to build the view-model that is then used to render the DOM (Document Object Model). In Angular, the abstraction is the HTML template; in React, the abstraction is the JSX syntax. They're just different abstractions.

At the end of the day, both Angular and React (and Vue and Ember and every other framework) use all the same JavaScript. And, every framework has quirks and things that you just have to know in order to use the framework effectively (like React's synthetic event system or that hooks have to appear first thing in a Function or that inline Function handlers cause extra rendering cycles).

Is this post a little bit of a rant? 100% absolutely.

But, this post is also a plea to understand what it is that people are seeing that I am not seeing. I wouldn't really care except for the fact that I keep hearing people with influence say that React teaches you more JavaScript; which will, without a doubt, hold sway over people with less experience and more trepidation about their career paths and their technology choices. And when that sway is founded on something that seems misleading (at least to me), things get icky-icky in my tum-tum.

If you can think of something that makes React "more JavaScript" than other frameworks, please leave a comment. I may push back against your comment; but, then at least we can have a conversation and better understand each other's perspectives.

Thank you in advance for helping me understand!

Reader Comments

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? 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.

Reply to this Comment


But, I would also argue that you still need to understand how React handles your data. For example, is it obvious that you can safely render {null} or {false} or {undefined}. Or, that you need to render a single node (though, I think maybe that's changed in recent releases with "fragments" or something - I haven't kept up). Or that all events are bound at the root.

Now, to be clear, I'm not arguing that any of that is complicated - I'm just saying that it's React-specific and something you need to learn as part of the React journey. Which is, at least to me, the same thing you would say about the Angular journey.

It's possible that I just never felt the friction of the Angular template that other people are feeling? So, the idea of controlling JSX with JavaScript is no less work than controller HTML with ng-* attributes. To me, they are the same control-flows, just different syntax (more or less).

One detractor to JSX - at least for me - is that it's unclear what the actual HTML will look like. Meaning, You might render a <MyComponent/>, but then when you look at the page source, there _is no <my-component> in there at all. Whereas with Angular, the page-source and the angular-source look much more similar. I am surprised that more React developers aren't confused by that. But again, it's just part of the learning curve of any framework.

So, long-story-short, maybe I just don't realize that the Angular templates are a big hurdle for a lot of people?

Reply to this Comment


But, just to re-focus, I did not / am not intending for this to be a React vs. (other framework) post. I am specifically reacting to (no pun intended) the comments about people saying that React helps you learn more JavaScript. That's the part that really confounds me; because, even if you can render JSX using "JavaScript", is that really the only place you're using if or for or map in your React app? I'm using those same constructs everywhere. So, there's nothing - to me - that I see in React that I don't see elsewhere in Angular.

Reply to this Comment

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).

Reply to this Comment


It all just seems like a matter of personal preference to me. Which is totally fine - that's what so much of programming is all about. I am not here to say that Angular is better or React is better. I am here to say that neither of them is fundamentally better or different. They just have choices that may or may not work for you personally.

Re: Dev Tools, I don't have any experience with that. I never used dev tools with Angular because the source was "the source", so the native Chrome Tools were always sufficient. And, when I started playing with React, I didn't -- and this is just personal preference -- want to "have to" install dev tools to understand how it works. I thought not installing them would help me build a better mental model of what was going on. But, that's just personal preference.

Reply to this Comment

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.

Reply to this Comment

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

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.

Reply to this Comment

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.

Reply to this Comment


It's really interesting to hear your perspective. Especially the fact that you came from modern Angular, not AngularJS. I wonder if this is more of the common experience. Because, my Angular code and my AngularJS code look syntactically very different. In fact, my AngularJS code heavily used things like Closures. Most of my AngularJS services were factory functions defined like this:

function MyServiceFactory() {
	var message = "Hello world";

	// Return public API.
		doSomething: doSomething

	// Public methods.
	function doSomething() {
		return( doSomethingPrivate() );
	// Private methods.
	function doSomethingPrivate() {
		return( message );

So, just little snippet of code actually has a lot of "JavaScript features" baked into it:

  • Variable hoisting
  • Function hoisting
  • Function references
  • Closures
  • Block scoping
  • Constructors
  • Overriding constructor return values

And, to make all that work in AngularJS, you had to understand a lot of low level JavaScript stuff. Which makes me wonder if modern Angular actually hides some of that behind the Class-based and Fat-arrow style of syntax?

I know for sure that some of the people that I've heard say things about React did come from the AngularJS world; but, now I am wondering if they are reacting more to the modern Angular abstractions than they are to AngularJS in general.

Thank you for sharing your views and experience. 💪

Reply to this Comment


You make a great point about this vs closure scope ... and it does give me the reality check that I've actually just been around a hella long time. So, a lot of how JavaScript works I actually know from my jQuery (and earlier days). I mean, even in jQuery, you had to really understand a lot of fundamentals even to understand what this was referring to - and why that may be different inside a jQuery plug-in. And how closures worked and why you could run into trouble if you defined event-handlers inside a loop and try to reference your loop-index variable.

So, I guess for me, AngularJS was a lot of taking stuff I already knew and just applying it in an Angular context. Which is also the way that I look at React as well.

I don't think I had ever considered this perspective before, until you and @Chau talked about people being confused with closures.

Reply to this Comment


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.

Reply to this Comment


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:

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.

Reply to this Comment


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 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".

Reply to this Comment


But, to focus on the ng-repeat missing a lot of what is going on. After all, to build-up the view-model that you are actually rendering with ng-repeat, you probably had to use things like .map(), .filter(), and .forEach() anyway. ng-repeat is just getting you over that last-mile to the rendering.

I'm also stuck on your point here:

Especially now with hooks! It's "just" functions. Components are functions. Hooks are functions.

And, I could counter-argue that being so heavily reliant on Functions is actually very narrowing in its own right. Do people who learn React have a good understanding of how Classes work? Are they good at understanding prototypal inheritance? Do they understanding why they can read from high-up in an prototype chain, but why writing to the prototype chain sometimes causes data to be written in "unexpected" places ("unexpected" if you don't understand how the prototype chain works)? Do they understand how you can take a Function reference, pull it out of one object, stuff it into another object, and completely change what this is referring to?

In Angular, you have to learn all this stuff about Classes and prototypes chains. And, you have to learn all the stuff about Functions too. Because, again, it's all just JavaScript. The only part of Angular that isn't JavaScript is the HTML templating. And, that's just the last mile.

Reply to this Comment


Re: jQuery, I remember very clearly the day that I had to look into the source code to understand how their implementation of Deferred (promises) worked. I remember wanting to pass around a reference the the .resolve function, rather than having to call it directly. And, I could only do that once I looked into the source code and saw that they bindings between the .resolve function and the underlying Deferred instance were being maintained through a Closure, not through a this reference. Which meant that the .resolve function would maintain the correct context even it were passed around as a naked Function.

jQuery was also just JavaScript, and you had to understand a lot of JavaScript in order to understand how to use the library.

Reply to this Comment

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.

Reply to this Comment


Mentioning yield brings up another thought - with React and JSX you pretty much need to be compiling code. Meaning, you can't just add a <InvalidTag> tag to your document and call it a day (I mean, I think you could do that in very early React releases, but I'm not sure you can anymore). And, once you are compiling stuff, you get to use more of the modern language features like yield, like async/await, without having to worry as much about cross-browser compatibility. So, to that end, by working in a compiled language, you get some more freedom in the types of things you explore.

For example, when I work in AngularJS, I am not "compiling" it the same way that we compile modern Angular. As such, I don't get to take advantage of things like for-of loops - I have to stick to for loops and forEach() iteration. Which is unfortunate, since for-of is amazing!

The "higher order" stuff is definitely a pattern that is more common in React due to the way it is architected. Though, that might become less of a "thing" with React Hooks? I'm not sure - I'm talking out of my depth now 🙃

That said, "higher order" in a general sense usually just refers to something that wraps something else. So, for example, a "higher order function" is just a Function that accepts or returns another Function, which is something that we can use all over the place in JavaScript. Such as when calling .filter() on an Array - the filter property is a function that accepts another function that uses internally. So, you're probably using "higher order" concepts far more often than you even realize.

JavaScript is so much fun!

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Blog
Live in the Now
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.