5 ms·

> React: when you need total control over the architecture and build, but only for webapps built with components. React-ecosystem development takes time and req

by ng12 8y ago

> React: when you need total control over the architecture and build, but only for webapps built with components. React-ecosystem development takes time and requires a lot of planning beforehand. React pays back plenty, but only if you know what you are doing. Complete nonsense. React is not any more complicated than Vue and I think it's significantly easier for newbies to grok than Angular (with some non-trivial anecdotal evidence to back this up). I do not understand where this perception comes from. My best guess is that React scales well to complicated applications which makes people think that's what it's geared for. Maybe I'm lucky that I learned React in the "early days" before this perception was common.

swsieber 8y ago
I think this sentiment comes from the fact that React is not a complete solution, and for big projects, you will have to make several impactful decision about architecture as it relates to using React. Angular and Vue don't encounter this as much because they are more broad, and more opinionated.
- linkmotif 8y ago
  React is not a complete solution? What are you referring to? It’s a complete solution for describing what you want on the screen and not worrying about how that happens. It comes with build tools. What else do you want?
  - britch 8y ago
    React is frequently mentioned in the same breath as Angular/Vue/etc. Angular, for example, has most of what you'd want to build a complex web app built. Compared to that, React is not "complete" because if you wanted to build a complex web app you'd need to start using outside libraries or writing a great deal of code yourself. I agree this does not mean React is "incomplete." It does what it sets out to do very well. But the discussion is often framed as React vs Vue vs Angular, fair or not.
    - linkmotif 8y ago
      > because if you wanted to build a complex web app you'd need to start using outside libraries or writing a great deal of code yourself. This is false. The ambiguity in this comment (“outside libraries”) speaks for itself. Yeah you probably want to use something for routing, but you really don’t have to at all. Otherwise nothing else comes to mind in terms of “libraries”. Just weird that people spread FUD/misinformation like this. so weird.
      - trgv 8y ago
        React is not "batteries included". Angular is. This isn't a weakness in React. I prefer react's approach. But it does mean the developer needs to make more decisions. Angular comes with stuff like RxJS and a wrapper around XmlHttpRequest. React doesn't. Again, this isn't "correct," it's just a different approach. No one is being combative here (except you), just descriptive.
        ng12 8y ago
        I don't like the "batteries included" metaphor because it implies getting batteries is hard. Yes, Angular ships with routing but thanks to the node ecosystem adding react-router is a one-line command. The hard part is learning the routing API which you have to do either way.
        TAForObvReasons 8y ago
        "batteries included" means that the software itself has everything you need to get going. It's not that it's hard to get an individual component, but now you're relying on a third party component and potential issues with random configurations etc. It takes some research and effort to figure out that react-router is the best module among the options for routing.
        TheCoelacanth 8y ago
        Neither of those are things that are needed for a javascript project. Fetch is a perfectly fine replacement for XmlHttpRequest and is a standard part of JS. RxJS is nice to have, but is not necessary.
  - arcticfox 8y ago
    > React is not a complete solution? There's no router, for example. I'm a huge React fan, but it's frustrating that the third party router I chose has been through 3 major paradigm-breaking changes since I started my project. I have experienced consistent quality from the core React team, but their footprint is limited by design, and I think it's naive to imply that relying on ecosystem projects is the same level of "complete" as being able to rely on core projects.
duxup 8y ago
n00b webdev here. React's component-ish nature and such actually makes things easier for me to digest / manage. No painful planning needed and I can move stuff around at will. I put React on everything (even if only for practice). It was a bit intimidating at first (like a couple weeks...) but it doesn't take long for for the fundamental React-isms to become second nature / my preferred way of doing the front end.
- rectangletangle 8y ago
  I had worked quite a bit with Angular 1 (first "real" front-end framework I learned), and some jQuery before that. I found the React/Redux/JSX stack to be really quick and easy to pick up. The simple component API and minimal use of magic helped avoid many of the headaches and quirks Angular 1 was riddled with. React/Redux is the most painless front-end stack I've ever used, makes writing web clients much faster. My only real complaint against the modern React/Redux stack, is the crazy amount of boilerplate involved, even with a "minimal" project.
- _bxg1 8y ago
  FWIW, Angular, Vue, Polymer, Ember, etc. all use the same component-ish pattern; it's the architecture du jour. That's great that you were able to pick up React right off the bat, but the concept of components isn't what sets it apart.
  - duxup 8y ago
    I guess I kinda implied it was a reactism, but that wasn't my intent. I was just noting how someone else new really doesn't find React as big a hill to climb as the article. The componentisms are just something that make it easy for me.
    - _bxg1 8y ago
      Yeah no worries, I just wanted to make sure you had a clear understanding of the landscape
ben_jones 8y ago
Seriously? Complete non-sense? React projects are frequently broken down into lots of small components with custom model/controller architectures depending on what third party tools you throw in with it. There are many areas where bloat and technical debt can add up if you do not properly plan before hand. Particularly in scenarios where you may be getting into front-end development for the first time i.e. when creating a MVP for your start-up. In this scenario and others like it React may not pay back plenty. While these issues exist in other libraries/frameworks they are somewhat mitigated by clearer first-party conventions or front-runners in the third party ecosystem which dictate specific architectures.
_bxg1 8y ago
- React takes way more configuration to get started than Vue. You can technically use either of them with or without build tools, but without Babel and Webpack, Vue is still reasonably usable and React is laughably obtuse. - React out of the box may not be any more complicated than Vue, but it also does a whole lot less than Vue does. Chiefly, you don't get tracking of deep state changes without adding a second (state management) framework on top, and the major ones designed for use with React are also designed for scale, and require tons of boilerplate and highbrow programming theory to get up and running with (I'm looking at you, Redux). - React itself is pretty highbrow, forgoing straightforward OOP concepts for functional-programming ideals. Which isn't a bad thing! But it makes it harder for newcomers who just want to get the text on their page to match up with what's being typed in an input.

by ng12 8y ago

swsieber 8y ago

I think this sentiment comes from the fact that React is not a complete solution, and for big projects, you will have to make several impactful decision about architecture as it relates to using React. Angular and Vue don't encounter this as much because they are more broad, and more opinionated.

linkmotif 8y ago
React is not a complete solution? What are you referring to? It’s a complete solution for describing what you want on the screen and not worrying about how that happens. It comes with build tools. What else do you want?
- britch 8y ago
  React is frequently mentioned in the same breath as Angular/Vue/etc. Angular, for example, has most of what you'd want to build a complex web app built. Compared to that, React is not "complete" because if you wanted to build a complex web app you'd need to start using outside libraries or writing a great deal of code yourself. I agree this does not mean React is "incomplete." It does what it sets out to do very well. But the discussion is often framed as React vs Vue vs Angular, fair or not.
  - linkmotif 8y ago
    > because if you wanted to build a complex web app you'd need to start using outside libraries or writing a great deal of code yourself. This is false. The ambiguity in this comment (“outside libraries”) speaks for itself. Yeah you probably want to use something for routing, but you really don’t have to at all. Otherwise nothing else comes to mind in terms of “libraries”. Just weird that people spread FUD/misinformation like this. so weird.
    - trgv 8y ago
      React is not "batteries included". Angular is. This isn't a weakness in React. I prefer react's approach. But it does mean the developer needs to make more decisions. Angular comes with stuff like RxJS and a wrapper around XmlHttpRequest. React doesn't. Again, this isn't "correct," it's just a different approach. No one is being combative here (except you), just descriptive.
      - ng12 8y ago
        I don't like the "batteries included" metaphor because it implies getting batteries is hard. Yes, Angular ships with routing but thanks to the node ecosystem adding react-router is a one-line command. The hard part is learning the routing API which you have to do either way.
        TAForObvReasons 8y ago
        "batteries included" means that the software itself has everything you need to get going. It's not that it's hard to get an individual component, but now you're relying on a third party component and potential issues with random configurations etc. It takes some research and effort to figure out that react-router is the best module among the options for routing.
      - TheCoelacanth 8y ago
        Neither of those are things that are needed for a javascript project. Fetch is a perfectly fine replacement for XmlHttpRequest and is a standard part of JS. RxJS is nice to have, but is not necessary.
- arcticfox 8y ago
  > React is not a complete solution? There's no router, for example. I'm a huge React fan, but it's frustrating that the third party router I chose has been through 3 major paradigm-breaking changes since I started my project. I have experienced consistent quality from the core React team, but their footprint is limited by design, and I think it's naive to imply that relying on ecosystem projects is the same level of "complete" as being able to rely on core projects.

duxup 8y ago

n00b webdev here. React's component-ish nature and such actually makes things easier for me to digest / manage. No painful planning needed and I can move stuff around at will. I put React on everything (even if only for practice). It was a bit intimidating at first (like a couple weeks...) but it doesn't take long for for the fundamental React-isms to become second nature / my preferred way of doing the front end.

rectangletangle 8y ago
I had worked quite a bit with Angular 1 (first "real" front-end framework I learned), and some jQuery before that. I found the React/Redux/JSX stack to be really quick and easy to pick up. The simple component API and minimal use of magic helped avoid many of the headaches and quirks Angular 1 was riddled with. React/Redux is the most painless front-end stack I've ever used, makes writing web clients much faster. My only real complaint against the modern React/Redux stack, is the crazy amount of boilerplate involved, even with a "minimal" project.
_bxg1 8y ago
FWIW, Angular, Vue, Polymer, Ember, etc. all use the same component-ish pattern; it's the architecture du jour. That's great that you were able to pick up React right off the bat, but the concept of components isn't what sets it apart.
- duxup 8y ago
  I guess I kinda implied it was a reactism, but that wasn't my intent. I was just noting how someone else new really doesn't find React as big a hill to climb as the article. The componentisms are just something that make it easy for me.
  - _bxg1 8y ago
    Yeah no worries, I just wanted to make sure you had a clear understanding of the landscape

ben_jones 8y ago

Seriously? Complete non-sense? React projects are frequently broken down into lots of small components with custom model/controller architectures depending on what third party tools you throw in with it. There are many areas where bloat and technical debt can add up if you do not properly plan before hand. Particularly in scenarios where you may be getting into front-end development for the first time i.e. when creating a MVP for your start-up. In this scenario and others like it React may not pay back plenty. While these issues exist in other libraries/frameworks they are somewhat mitigated by clearer first-party conventions or front-runners in the third party ecosystem which dictate specific architectures.

_bxg1 8y ago

- React takes way more configuration to get started than Vue. You can technically use either of them with or without build tools, but without Babel and Webpack, Vue is still reasonably usable and React is laughably obtuse. - React out of the box may not be any more complicated than Vue, but it also does a whole lot less than Vue does. Chiefly, you don't get tracking of deep state changes without adding a second (state management) framework on top, and the major ones designed for use with React are also designed for scale, and require tons of boilerplate and highbrow programming theory to get up and running with (I'm looking at you, Redux). - React itself is pretty highbrow, forgoing straightforward OOP concepts for functional-programming ideals. Which isn't a bad thing! But it makes it harder for newcomers who just want to get the text on their page to match up with what's being typed in an input.