6 ms·

Isn't this like comparing apples to a fruit salad? Quoting from the React website, "Lots of people use React as the V in MVC," whereas Angular is the whole kit

Isn't this like comparing apples to a fruit salad? Quoting from the React website, "Lots of people use React as the V in MVC," whereas Angular is the whole kit `n' kaboodle. I thought React was supposed to be used in tandem with a Flux-like component that stores the state of the application, thereby allowing the developer to adopt the functional reactive programming style. Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org http://elm-lang.org in order to fully achieve Satori. I mean, if you're going to drink the Kool-aid, you might as well down the whole pitcher.

davedx 11y ago
> anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org http://elm-lang.org in order to fully achieve Satori Or you could just use React with Redux, like many people are doing! :) https://github.com/rackt/redux#influences https://github.com/rackt/redux#influences
implicitdef 11y ago
React only covers the V of MVC, true, but in practice it influences heavily the rest of your app. So comparing Angular and React is useful, most people will have to pick one or the other when they start their next project.
- pluma 11y ago
  The difference is that React is much less opinionated. You can tie it into your existing Backbone app or you can use Flux (or one of the many Flux-like libraries out there) or you can use Redux (which is in many ways exactly like React, but for state) or you can use something like Relay or Falcor or even something entirely different. Angular wants to own your project. That's not necessarily a bad thing because it also means you don't need to evaluate the relative pros and cons of lots of tools doing what it already gives you for free and you're more likely to find help because there are more people with your specific combination. But it also limits how much you can adapt Angular to your specific application's needs. The more you deviate from the defaults, the more you lose the benefits of using a full-featured framework in the first place and the more you have to muck around trying to bend all the parts into the shape you want. Plus you actually CAN use React inside Angular (or vice versa) if you really want to. It's probably not a good idea because React doesn't do anything Angular can already do (but differently), but it's entirely possible (just like how people already used Angular with Polymer or Backbone or what have you). I wouldn't say React influences the rest of your app as much as Angular (or Ember) necessarily does but saying that a tool will influence the rest of the app is almost tautological -- every decision affects other decisions, even if it's only because of the mental models it may bring with it. The truth is, it's not a decision between Angular or just React. You're not going to simply use React. You're going to use React plus something else. That's simply a set of decisions choosing a framework won't require you to make. The comparison isn't meaningless because there is no either-or choice. The comparison is meaningless because it's incredibly hard to compare just React with all of Angular (or Ember or whatever).
seivan 11y ago
What's wrong with RxJS and React that makes you think it will be short lived as an alternative to Elm?
mtbcoder 11y ago
> Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon... I don't think most front end developers even care. React will stick around because it's backed by Facebook and if Facebook says this is the way to go with front-end development then that is all the convincing most folks need. They'll go on to learn React and not think twice about the minutiae of "FRP" or whatever the programming paradigm de jour is because at the end of the day, people just want something they can easily grok, something that works without too much hassle and something that is going to be used/supported for the long term.
- pluma 11y ago
  > React will stick around because it's backed by Facebook and if Facebook says this is the way to go with front-end development then that is all the convincing most folks need. Not just that. Facebook uses it for their flagship website (and as React Native for their mobile apps). So does Instagram. So does Netflix. If you have the React developer tools installed you can literally go to facebook.com or netflix.com and see them using React. Angular in turn can't really namedrop use cases like these. Yes, Google uses it somewhere in their ad manager, YouTube uses it in their video manager, Amazon uses it for something -- these are big names too, but the use cases aren't nearly as impressive and they're not as integral to the relative companies' core business. Google (who is backing Angular) doesn't have nearly as much skin in the game as Facebook (who is backing React). The difference between React and FRP in turn is that React simply builds on well-understood ideas that already exist in mainstream front-end programming: modular components and one-way data flow. You don't need a CS degree to understand the benefits of having your views not directly manipulate your state. FRP isn't bad. It's just that React is good enough, which is what really matters at the end of the day.
  - hitekker 11y ago
    > Google (who is backing Angular) doesn't have nearly as much skin in the game as Facebook (who is backing React). Excellent point. Here's another "smell" with angular: http://angularjs.org http://angularjs.org versus https://angular.io/ https://angular.io/. The former is AngularJS 2.0 and the latter is AngularJS 1.0... they maintain two websites for two versions of the same framework. It boggles my mind. Who thought it would be a good idea to separate versions of the framework onto two different domain names? While they're still owned by the same company? Why? Unfortunately, the only sensible answer that comes to mind is "AngularJS 1.0 was such a colossal, terrible mistake that we need to move away from it not just from a code perspective, but from a marketing perspective as well." Normally, I avoid framework/language wars but I had ( and will soon again have ) the misfortune of developing in Angular. Consulting out-of-date documentation on their quick-and-dirty bootstrap site, fervently wishing that the devs didn't rage-delete the comments section which corrected the incorrect documentation... yuck.
sotojuan 11y ago
> because anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org http://elm-lang.org Elm is awesome, but also look into Cycle[1]. [1] http://cycle.js.org http://cycle.js.org
- mercurial 11y ago
  When evaluating techs to make our frontend evolve, I looked at cycle. It seems genuinely interesting, and much more FRP than React+Flux, but it doesn't seem to have a lot of traction.
  - sotojuan 11y ago
    Sadly you are right. I think it got sandwiched under React/Redux. That said, it does raise very interesting ideas about writing web apps so it's worth a look at least just for fun.
Retozi 11y ago
From my experience, it is not about the FRP kool-aid. It's about the robustness of the concepts of React (DOM diff-ing, favor immutability, declarative views etc.) Adopting something like elm might have its advantages, but also comes with practical disadvantages that, depending on your team and your project might be simply too big make the jump. React got a lot of things right in my opinion. So much that to go from apple to fruit salad, you need roughly 200-300 additional LOCs, and you have a very robust Frontend system that, once you wrapped your head around React, has a very low knowledge barrier. However, the good traits of React are not attributable to one concept like "FRP" but are simply "good concepts" that seem to influence other Frameworks to do "the same, a little different". The adoption, the somewhat small API, the support from a large company, the possibility to integrate it easily in existing codebases that use other frameworks and react native has a much stronger pull than FRP in my opinion.
- tracker1 11y ago
  I think a lot of attention is given tot he DOM diffing... I don't think it really means that much in practice as far as understanding the flux-like workflows and how applications come together. To me, the unidirectional data flow, optionally immutable data structures and even tooling around redux (and similar) are what are nice. You have predictable, testable output without excessive complexity. The need to understand a certain level of complexity in React+Redux in getting started is indeed a bit higher. But as features are added, that complexity doesn't grow nearly as much as with Angular. I find the simpler node-like requires/es6-imports are easier to reason with than dealing with angular's weird DI system (though better in v2). Testing injection is supported via tooling (proxyquire and the like), and you can do full unit testing of your UI without firing up a browser. I agree that full on FRP isn't needed... but will say that having data flowing in one direction, and events in the other can simplify things a lot. I'm also not sold on static typing for JS, as someone who really likes C#. I also think the use of classes in JS should generally be very limited.
m_fayer 11y ago
I think FRP is one of those technologies where going full-hog (all the things are event streams!) results in confusing code and a dogmatic, difficult, and unpleasant development experience. However, if you apply it just enough, you'll have coherent one-directional dataflow, effortless propagation of state changes, and a nice testable push architecture as a free side-effect. It's a way to tame the state-monster. And there will be numerous small isolated parts of your codebase that are unrelated to the aforementioned goals, where sticking to FRP would be masochistic and pointless. A major part of mastering a technology or paradigm is knowing when to apply it and when the costs of it outweigh the benefits. Then again, I prefer hybrid-friendly languages like scala, so maybe the haskell and clojure people are onto something that I'm missing.
- Cymen 11y ago
  I agree with you. I also like being "closer to the machine" so to speak. One day, my dev browser will support ES6/7 and I won't need babel + webpack/browserify while doing locally development, debugging will be done on unmunged code and TDD will be easy to practice as the feedback loop will be back to normal.
  - likeclockwork 11y ago
    If you ditch Babel you won't be able to use ES8/9.
    - hazza1 11y ago
      For me ES6/7 has addressed all the low hanging fruit, I really hope ES8/9 is about removing features with only a few additions.
      - wangii 11y ago
        everybody agrees to add "only a few additions", except has different set of them!
      - tracker1 11y ago
dominotw 11y ago
>Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org http://elm-lang.org in order to fully achieve Satori Lot of ppl do server side rendering with react so elm is not going to cut it.
chisleu 11y ago
I don't know about that. You can write controllers and models in react, it is just an anti-pattern. The same is true of Angular. Angular is usually used as the V, and a little bit of the C with protected controller functionality server side, and APIs for public model interfaces and public controller api endpoints.
tlrobinson 11y ago
Elm will not replace React among most web developers for the simple reason that it is not JavaScript. It's easy to incrementally introduce React to JavaScript developers. Requiring an entire new language is a non-starter for many web developers (though I think the popularity of CoffeeScript and Babel et al is changing that to some extent)
spankalee 11y ago
React will be short-lived because of Web Components, not because of Elm. Either that, or React will evolve to be a Web Components framework. The days of proprietary component silos are numbered, IMO.
- ch0wn 11y ago
  React goes into the exact opposite direction than Web Components. Declarative vs. imperative. (Relatively) clearly defined state vs. mixing DOM and JS state. What's your evidence that WCs are replacing React?
- citrons 11y ago
  Here a discussion on React github about WebComponents: https://github.com/facebook/react/issues/5052 https://github.com/facebook/react/issues/5052

davedx 11y ago

> anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org http://elm-lang.org in order to fully achieve Satori Or you could just use React with Redux, like many people are doing! :) https://github.com/rackt/redux#influences https://github.com/rackt/redux#influences

implicitdef 11y ago

React only covers the V of MVC, true, but in practice it influences heavily the rest of your app. So comparing Angular and React is useful, most people will have to pick one or the other when they start their next project.

pluma 11y ago
The difference is that React is much less opinionated. You can tie it into your existing Backbone app or you can use Flux (or one of the many Flux-like libraries out there) or you can use Redux (which is in many ways exactly like React, but for state) or you can use something like Relay or Falcor or even something entirely different. Angular wants to own your project. That's not necessarily a bad thing because it also means you don't need to evaluate the relative pros and cons of lots of tools doing what it already gives you for free and you're more likely to find help because there are more people with your specific combination. But it also limits how much you can adapt Angular to your specific application's needs. The more you deviate from the defaults, the more you lose the benefits of using a full-featured framework in the first place and the more you have to muck around trying to bend all the parts into the shape you want. Plus you actually CAN use React inside Angular (or vice versa) if you really want to. It's probably not a good idea because React doesn't do anything Angular can already do (but differently), but it's entirely possible (just like how people already used Angular with Polymer or Backbone or what have you). I wouldn't say React influences the rest of your app as much as Angular (or Ember) necessarily does but saying that a tool will influence the rest of the app is almost tautological -- every decision affects other decisions, even if it's only because of the mental models it may bring with it. The truth is, it's not a decision between Angular or just React. You're not going to simply use React. You're going to use React plus something else. That's simply a set of decisions choosing a framework won't require you to make. The comparison isn't meaningless because there is no either-or choice. The comparison is meaningless because it's incredibly hard to compare just React with all of Angular (or Ember or whatever).

seivan 11y ago

What's wrong with RxJS and React that makes you think it will be short lived as an alternative to Elm?

mtbcoder 11y ago

> Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon... I don't think most front end developers even care. React will stick around because it's backed by Facebook and if Facebook says this is the way to go with front-end development then that is all the convincing most folks need. They'll go on to learn React and not think twice about the minutiae of "FRP" or whatever the programming paradigm de jour is because at the end of the day, people just want something they can easily grok, something that works without too much hassle and something that is going to be used/supported for the long term.

pluma 11y ago
> React will stick around because it's backed by Facebook and if Facebook says this is the way to go with front-end development then that is all the convincing most folks need. Not just that. Facebook uses it for their flagship website (and as React Native for their mobile apps). So does Instagram. So does Netflix. If you have the React developer tools installed you can literally go to facebook.com or netflix.com and see them using React. Angular in turn can't really namedrop use cases like these. Yes, Google uses it somewhere in their ad manager, YouTube uses it in their video manager, Amazon uses it for something -- these are big names too, but the use cases aren't nearly as impressive and they're not as integral to the relative companies' core business. Google (who is backing Angular) doesn't have nearly as much skin in the game as Facebook (who is backing React). The difference between React and FRP in turn is that React simply builds on well-understood ideas that already exist in mainstream front-end programming: modular components and one-way data flow. You don't need a CS degree to understand the benefits of having your views not directly manipulate your state. FRP isn't bad. It's just that React is good enough, which is what really matters at the end of the day.
- hitekker 11y ago
  > Google (who is backing Angular) doesn't have nearly as much skin in the game as Facebook (who is backing React). Excellent point. Here's another "smell" with angular: http://angularjs.org http://angularjs.org versus https://angular.io/ https://angular.io/. The former is AngularJS 2.0 and the latter is AngularJS 1.0... they maintain two websites for two versions of the same framework. It boggles my mind. Who thought it would be a good idea to separate versions of the framework onto two different domain names? While they're still owned by the same company? Why? Unfortunately, the only sensible answer that comes to mind is "AngularJS 1.0 was such a colossal, terrible mistake that we need to move away from it not just from a code perspective, but from a marketing perspective as well." Normally, I avoid framework/language wars but I had ( and will soon again have ) the misfortune of developing in Angular. Consulting out-of-date documentation on their quick-and-dirty bootstrap site, fervently wishing that the devs didn't rage-delete the comments section which corrected the incorrect documentation... yuck.

sotojuan 11y ago

> because anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org http://elm-lang.org Elm is awesome, but also look into Cycle[1]. [1] http://cycle.js.org http://cycle.js.org

mercurial 11y ago
When evaluating techs to make our frontend evolve, I looked at cycle. It seems genuinely interesting, and much more FRP than React+Flux, but it doesn't seem to have a lot of traction.
- sotojuan 11y ago
  Sadly you are right. I think it got sandwiched under React/Redux. That said, it does raise very interesting ideas about writing web apps so it's worth a look at least just for fun.

Retozi 11y ago

From my experience, it is not about the FRP kool-aid. It's about the robustness of the concepts of React (DOM diff-ing, favor immutability, declarative views etc.) Adopting something like elm might have its advantages, but also comes with practical disadvantages that, depending on your team and your project might be simply too big make the jump. React got a lot of things right in my opinion. So much that to go from apple to fruit salad, you need roughly 200-300 additional LOCs, and you have a very robust Frontend system that, once you wrapped your head around React, has a very low knowledge barrier. However, the good traits of React are not attributable to one concept like "FRP" but are simply "good concepts" that seem to influence other Frameworks to do "the same, a little different". The adoption, the somewhat small API, the support from a large company, the possibility to integrate it easily in existing codebases that use other frameworks and react native has a much stronger pull than FRP in my opinion.

tracker1 11y ago
I think a lot of attention is given tot he DOM diffing... I don't think it really means that much in practice as far as understanding the flux-like workflows and how applications come together. To me, the unidirectional data flow, optionally immutable data structures and even tooling around redux (and similar) are what are nice. You have predictable, testable output without excessive complexity. The need to understand a certain level of complexity in React+Redux in getting started is indeed a bit higher. But as features are added, that complexity doesn't grow nearly as much as with Angular. I find the simpler node-like requires/es6-imports are easier to reason with than dealing with angular's weird DI system (though better in v2). Testing injection is supported via tooling (proxyquire and the like), and you can do full unit testing of your UI without firing up a browser. I agree that full on FRP isn't needed... but will say that having data flowing in one direction, and events in the other can simplify things a lot. I'm also not sold on static typing for JS, as someone who really likes C#. I also think the use of classes in JS should generally be very limited.

m_fayer 11y ago

I think FRP is one of those technologies where going full-hog (all the things are event streams!) results in confusing code and a dogmatic, difficult, and unpleasant development experience. However, if you apply it just enough, you'll have coherent one-directional dataflow, effortless propagation of state changes, and a nice testable push architecture as a free side-effect. It's a way to tame the state-monster. And there will be numerous small isolated parts of your codebase that are unrelated to the aforementioned goals, where sticking to FRP would be masochistic and pointless. A major part of mastering a technology or paradigm is knowing when to apply it and when the costs of it outweigh the benefits. Then again, I prefer hybrid-friendly languages like scala, so maybe the haskell and clojure people are onto something that I'm missing.

Cymen 11y ago
I agree with you. I also like being "closer to the machine" so to speak. One day, my dev browser will support ES6/7 and I won't need babel + webpack/browserify while doing locally development, debugging will be done on unmunged code and TDD will be easy to practice as the feedback loop will be back to normal.
- likeclockwork 11y ago
  If you ditch Babel you won't be able to use ES8/9.
  - hazza1 11y ago
    For me ES6/7 has addressed all the low hanging fruit, I really hope ES8/9 is about removing features with only a few additions.
    - wangii 11y ago
      everybody agrees to add "only a few additions", except has different set of them!
    - tracker1 11y ago

dominotw 11y ago

>Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org http://elm-lang.org in order to fully achieve Satori Lot of ppl do server side rendering with react so elm is not going to cut it.

chisleu 11y ago

I don't know about that. You can write controllers and models in react, it is just an anti-pattern. The same is true of Angular. Angular is usually used as the V, and a little bit of the C with protected controller functionality server side, and APIs for public model interfaces and public controller api endpoints.

tlrobinson 11y ago

Elm will not replace React among most web developers for the simple reason that it is not JavaScript. It's easy to incrementally introduce React to JavaScript developers. Requiring an entire new language is a non-starter for many web developers (though I think the popularity of CoffeeScript and Babel et al is changing that to some extent)

spankalee 11y ago

React will be short-lived because of Web Components, not because of Elm. Either that, or React will evolve to be a Web Components framework. The days of proprietary component silos are numbered, IMO.

ch0wn 11y ago
React goes into the exact opposite direction than Web Components. Declarative vs. imperative. (Relatively) clearly defined state vs. mixing DOM and JS state. What's your evidence that WCs are replacing React?
citrons 11y ago
Here a discussion on React github about WebComponents: https://github.com/facebook/react/issues/5052 https://github.com/facebook/react/issues/5052