5 ms·

It doesn't fare well that a framework that is only 3 years old already has an extensive list of anti-patterns and tons of statements on what not to do. Also hav

It doesn't fare well that a framework that is only 3 years old already has an extensive list of anti-patterns and tons of statements on what not to do. Also having to do manual performance optimizations using the framework is a hassle to application developers and can be a major pitfall (ex. PureRenderMixin, shouldComponentUpdate).

nathancahill 10y ago
No, no, no. This is exactly what makes React so great compared to Angular (to pick one). There's One Way™ to do things correctly. Using anti-pattern "hacks" will work for a little bit, but in the long run come back to bite you as your software grows and scales. I've been using React for over 2 years now, and still refer back to that list when I feel like something isn't right.
- Bahamut 10y ago
  Huh? This sounds like it's more true of Angular than React - there is a widely adopted style guide, and well-known anti-patterns are very established. I don't get that impression with React.
  - thejameskyle 10y ago
    As a former Angular 1 user I have to disagree with you. There are many many ways of writing Angular apps and the community generally disagrees on what the best ideas are. Compare this to how people write React components, they all look pretty much the same no matter what application you are working on. Sure there has been some churn, but there are tons of helpful warnings when they have happened and the migrations are easy. The community is also on the same exact page when it comes to writing components. Outside of components there's a lack of the same cohesiveness with competing architectures. But the good ideas are rising to the top and the bad ones are fizzling away. I don't see it as a bad thing.
  - nathancahill 10y ago
    I added "to pick one" because I don't particularly want to start a flame thread over frameworks. Everyone can choose their own tools for their jobs. However, to the point about style guide/anti-patterns: I guess we haven't been working in the same codebases.. I've worked on a handful of different projects and most have scope flying all of the place, with controllers and directives used interchangeably (not to mention factories/services/providers). But really my biggest gripe is the amount of logic that ends up in disparate HTML attributes. JSX is a much cleaner solution.
    - Bahamut 10y ago
      Well, I commented mainly because of this > There's One Way™ to do things correctly. Using anti-pattern "hacks" will work for a little bit, but in the long run come back to bite you as your software grows and scales. This is true, but in the given context that this is not true in the Angular world, that is definitely false. Some of the things you've mentioned are considered known abuses/anti-patterns/etc.
      - Sacho 10y ago
        I'd consider large parts of the Angular 1 framework to be anti-patterns. I believe that's the reason why they completely remade the framework with Angular 2, to avoid all these pitfalls. Given that, I find it the complaint that React is doing the same odd :)
- tlrobinson 10y ago
  I love React, but once you move beyond toy applications it's definitely not always clear what the "one way to do things correctly" is. This is even more true when you start talking about the rest of the ecosystem (testing? build tools? style? Redux?). I sometimes wish for an opinionated framework that's built around React and possibly Redux (that said, I have pretty strong opinions so there would have to be significant overlap) That said, I never got deep enough into Angular to know whether React is better or worse in that respect.
spicyj 10y ago
As performance optimization goes, I've never seen a system for building apps where you never need to worry about performance. Our goal with React is to give good performance most of the time and to make it easy to optimize when you have problems -- in many cases, by adding a single shouldComponentUpdate. I think we generally succeed at this goal.
trizinix 10y ago
You have to consider that react was the first (popular) implementation of a virtual dom. We learned a tremendous amount how to implement and use the virtual dom in the mean time. And react isn't a framework, it only implements the view layer.
danabramov 10y ago
>It doesn't fare well that a framework that is only 3 years old already has an extensive list of anti-patterns and tons of statements on what not to do. Doesn’t programming in general have solutions that scale well, and solutions that don’t scale well? Would you rather not have people writing about their experiences because it “doesn’t fare well”? We are just sharing some things that worked well for us, and some things that didn’t. Things that didn’t (mixins) will eventually be forgotten as we move away from those APIs. So it looks like progress to me, but maybe I misunderstand something. >Also having to do manual performance optimizations using the framework is a hassle to application developers and can be a major pitfall You don’t “have to” do those optimizations. We only use them in about one in twenty components. But they are handy, and having an option to speed up a component with a few lines is better than having no such option. What do you think?
- daliwali 10y ago
  A corollary to what I'm saying is that the design patterns that are espoused by React authors can be eliminated by using another abstraction, they're specific to React and have nothing to do with programming in general. I wouldn't go so far as to say, never use mixins in JavaScript, for example. >You don’t “have to” do those optimizations. Sure, but it seems to be a trade off of complexity for user experience. It's just covering up a leaky abstraction.
  - jhall1468 10y ago
    > they're specific to React and have nothing to do with programming in general. I can't think of a single design pattern used in React that isn't a highly common design pattern in any number of languages. HOC's are just a React implementation of Higher-order Functions. > I wouldn't go so far as to say, never use mixins in JavaScript, for example. Neither did they... This doesn’t mean that mixins themselves are bad. People successfully employ them in different languages and paradigms, including some functional languages... Nevertheless, we think that mixins are unnecessary and problematic in React codebases.
  - danabramov 10y ago
    >they're specific to React and have nothing to do with programming in general Higher-order functions are extremely common and useful in all functional languages. In fact many people gave us the exact opposite feedback: React taught them many functional programming patterns that they later used elsewhere, both with and without JavaScript, not to say React. >I wouldn't go so far as to say, never use mixins in JavaScript, for example. This is not what the article says. There is a paragraph clarifying this specific point, as the sibling comment points out. And the article is sprinkled with “in React codebases” and “in our experience” for this very reason. >Sure, but it seems to be a trade off of complexity for user experience. I don’t understand what you mean. In most cases you don’t need to do anything, React is fast. When you have an especially complex tree (not very common), you can add three lines to a few files, and React is even faster. It is a tradeoff, and it is a pretty damn good tradeoff in my experience working on React apps. What am I missing?
natrius 10y ago
Just try using it already. Or any virtual DOM library. You have cosmetic complaints about things that no one who uses this stuff is bothered by.
baddox 10y ago
I don't understand. For any framework there are lots of things that you shouldn't do. Are you complaining that these things exist, or that they're documented? Surely it's better to have them documented.
mrblueblue 10y ago
The "anti-pattern" patterns that you can use to build your React app are usually the "imperative escape hatches" the post is referring to. They are part of the framework to allow developers not familiar with functional and declarative ways of doing things to get stuff done I believe its part of the React team's long-term goal to educate framework adopters about the proper patterns and to slowly phase out these escape hatches.
- danabramov 10y ago
  It is indeed a part of our strategy. We can’t just tell everyone to go functional. We are making mistakes and learning together with our users, and we are phasing our patterns when we are confident that the better patterns are accessible and we see that people can use them efficiently without extensive training.

nathancahill 10y ago

No, no, no. This is exactly what makes React so great compared to Angular (to pick one). There's One Way™ to do things correctly. Using anti-pattern "hacks" will work for a little bit, but in the long run come back to bite you as your software grows and scales. I've been using React for over 2 years now, and still refer back to that list when I feel like something isn't right.

Bahamut 10y ago
Huh? This sounds like it's more true of Angular than React - there is a widely adopted style guide, and well-known anti-patterns are very established. I don't get that impression with React.
- thejameskyle 10y ago
  As a former Angular 1 user I have to disagree with you. There are many many ways of writing Angular apps and the community generally disagrees on what the best ideas are. Compare this to how people write React components, they all look pretty much the same no matter what application you are working on. Sure there has been some churn, but there are tons of helpful warnings when they have happened and the migrations are easy. The community is also on the same exact page when it comes to writing components. Outside of components there's a lack of the same cohesiveness with competing architectures. But the good ideas are rising to the top and the bad ones are fizzling away. I don't see it as a bad thing.
- nathancahill 10y ago
  I added "to pick one" because I don't particularly want to start a flame thread over frameworks. Everyone can choose their own tools for their jobs. However, to the point about style guide/anti-patterns: I guess we haven't been working in the same codebases.. I've worked on a handful of different projects and most have scope flying all of the place, with controllers and directives used interchangeably (not to mention factories/services/providers). But really my biggest gripe is the amount of logic that ends up in disparate HTML attributes. JSX is a much cleaner solution.
  - Bahamut 10y ago
    Well, I commented mainly because of this > There's One Way™ to do things correctly. Using anti-pattern "hacks" will work for a little bit, but in the long run come back to bite you as your software grows and scales. This is true, but in the given context that this is not true in the Angular world, that is definitely false. Some of the things you've mentioned are considered known abuses/anti-patterns/etc.
    - Sacho 10y ago
      I'd consider large parts of the Angular 1 framework to be anti-patterns. I believe that's the reason why they completely remade the framework with Angular 2, to avoid all these pitfalls. Given that, I find it the complaint that React is doing the same odd :)
tlrobinson 10y ago
I love React, but once you move beyond toy applications it's definitely not always clear what the "one way to do things correctly" is. This is even more true when you start talking about the rest of the ecosystem (testing? build tools? style? Redux?). I sometimes wish for an opinionated framework that's built around React and possibly Redux (that said, I have pretty strong opinions so there would have to be significant overlap) That said, I never got deep enough into Angular to know whether React is better or worse in that respect.

spicyj 10y ago

As performance optimization goes, I've never seen a system for building apps where you never need to worry about performance. Our goal with React is to give good performance most of the time and to make it easy to optimize when you have problems -- in many cases, by adding a single shouldComponentUpdate. I think we generally succeed at this goal.

trizinix 10y ago

You have to consider that react was the first (popular) implementation of a virtual dom. We learned a tremendous amount how to implement and use the virtual dom in the mean time. And react isn't a framework, it only implements the view layer.

danabramov 10y ago

>It doesn't fare well that a framework that is only 3 years old already has an extensive list of anti-patterns and tons of statements on what not to do. Doesn’t programming in general have solutions that scale well, and solutions that don’t scale well? Would you rather not have people writing about their experiences because it “doesn’t fare well”? We are just sharing some things that worked well for us, and some things that didn’t. Things that didn’t (mixins) will eventually be forgotten as we move away from those APIs. So it looks like progress to me, but maybe I misunderstand something. >Also having to do manual performance optimizations using the framework is a hassle to application developers and can be a major pitfall You don’t “have to” do those optimizations. We only use them in about one in twenty components. But they are handy, and having an option to speed up a component with a few lines is better than having no such option. What do you think?

daliwali 10y ago
A corollary to what I'm saying is that the design patterns that are espoused by React authors can be eliminated by using another abstraction, they're specific to React and have nothing to do with programming in general. I wouldn't go so far as to say, never use mixins in JavaScript, for example. >You don’t “have to” do those optimizations. Sure, but it seems to be a trade off of complexity for user experience. It's just covering up a leaky abstraction.
- jhall1468 10y ago
  > they're specific to React and have nothing to do with programming in general. I can't think of a single design pattern used in React that isn't a highly common design pattern in any number of languages. HOC's are just a React implementation of Higher-order Functions. > I wouldn't go so far as to say, never use mixins in JavaScript, for example. Neither did they... This doesn’t mean that mixins themselves are bad. People successfully employ them in different languages and paradigms, including some functional languages... Nevertheless, we think that mixins are unnecessary and problematic in React codebases.
- danabramov 10y ago
  >they're specific to React and have nothing to do with programming in general Higher-order functions are extremely common and useful in all functional languages. In fact many people gave us the exact opposite feedback: React taught them many functional programming patterns that they later used elsewhere, both with and without JavaScript, not to say React. >I wouldn't go so far as to say, never use mixins in JavaScript, for example. This is not what the article says. There is a paragraph clarifying this specific point, as the sibling comment points out. And the article is sprinkled with “in React codebases” and “in our experience” for this very reason. >Sure, but it seems to be a trade off of complexity for user experience. I don’t understand what you mean. In most cases you don’t need to do anything, React is fast. When you have an especially complex tree (not very common), you can add three lines to a few files, and React is even faster. It is a tradeoff, and it is a pretty damn good tradeoff in my experience working on React apps. What am I missing?

natrius 10y ago

Just try using it already. Or any virtual DOM library. You have cosmetic complaints about things that no one who uses this stuff is bothered by.

baddox 10y ago

I don't understand. For any framework there are lots of things that you shouldn't do. Are you complaining that these things exist, or that they're documented? Surely it's better to have them documented.

mrblueblue 10y ago

The "anti-pattern" patterns that you can use to build your React app are usually the "imperative escape hatches" the post is referring to. They are part of the framework to allow developers not familiar with functional and declarative ways of doing things to get stuff done I believe its part of the React team's long-term goal to educate framework adopters about the proper patterns and to slowly phase out these escape hatches.

danabramov 10y ago
It is indeed a part of our strategy. We can’t just tell everyone to go functional. We are making mistakes and learning together with our users, and we are phasing our patterns when we are confident that the better patterns are accessible and we see that people can use them efficiently without extensive training.