9 ms·

React vs. Angular 2

160 points by kevindeasis 11y ago

vertebrate 11y ago
What is this FRP thing JS developers talking about? What I should read to learn more about it?
- michaelsbradley 11y ago
  It's been around in various forms, and implemented on top of various languages, for quite some time. The earliest full-fledged FRP implementation for JavaScript was Flapjax – work on it dates all the way back to 2006! http://www.flapjax-lang.org/ http://www.flapjax-lang.org/ The paper Flapjax: A Programming Language for Ajax Applications is worth reading. http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgbk-flapjax/paper.pdf http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgb... The principal designer and maintainer of the Elm Language (a functional reactive lang that compiles to JS) did his Master's Thesis on FRP, and that's a great resource if you want the big picture: https://www.seas.harvard.edu/sites/default/files/files/archived/Czaplicki.pdf https://www.seas.harvard.edu/sites/default/files/files/archi... See also Controlling Time and Space: understanding the many formulations of FRP, by the same author: https://www.youtube.com/watch?v=Agu6jipKfYw https://www.youtube.com/watch?v=Agu6jipKfYw
- masklinn 11y ago
  > What is this FRP thing https://en.wikipedia.org/wiki/Functional_reactive_programming https://en.wikipedia.org/wiki/Functional_reactive_programmin...
- pluma 11y ago
  It's a way to write applications as declarative code that defines the UI in terms of sequences of events and streams. Basically: something incredibly powerful and clever that will not be adopted by the wider developer community until someone figures out how to present it in a way that makes it accessible to someone who isn't deeply interested in academia.
  - michaelsbradley 11y ago
    I don't think it's so much that it requires an interest in academia, but that it requires a shift in thinking towards abstractions that still aren't mainstream, relative to OOP (in its various forms) and unadorned events/listeners. Principally, that shift is toward higher-order functions. Yes, those same HOF abstractions are popular subjects for academic research and teaching, but they're not inherently academic subjects.
    - pluma 11y ago
      True, but this paradigm shift has been pending for nearly half a century and there doesn't seem to be any progress, just periodic rediscoveries.
- sotojuan 11y ago
  A small part of it is that your events are basically constant streams of data (think arrays) you can map, reduce, and filter (among other functions) and then present. Here is a short article on it: https://medium.com/@andrestaltz/2-minute-introduction-to-rx-24c8ca793877#.pzupjr8nt https://medium.com/@andrestaltz/2-minute-introduction-to-rx-... This is a discussion over the controversy of calling stuff FRP in academia vs. real world: https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-just-did-d5ffaa23973b https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-j...
- tunesmith 11y ago
  If you ignore the whole thing about how frp is not FRP, and how javascript developers really only mean frp, then a good place to start would be learning about RxJS. FRP is deterministic and referentially transparent, frp is not. Key concepts in FRP are behaviors, events, signals; key concepts in frp is streams, observables, subscriptions. Although I'm not expert with either, there's a lot of overlap and term overloading, and I might be explaining this all badly anyway.
  - spion 11y ago
    AFAICT, the simplest way of explaining the difference between FRP and "popular frp" is that in FRP things are described as functions of time, whereas in popular frp they are streams of events. The "real" FRP is great for describing non-interactive things. They can be used to describe anumations: e.g. a FRP behavior can describe the position of a ball as a function of time: ballPosition :: t -> Position whereas in "quasi" frp, the ballPosition is a stream of Position values: ballPosition :: (Stream Position) Basically, quasi FRP is what you get when you sample real FRP at certain times :)
- bahmutov 11y ago
  A way to handle sequences of events - which is really powerful abstraction. Look at this (shameless self-promotion) presentation https://slides.com/bahmutov/javascript-journey-boston-code-camp-24 https://slides.com/bahmutov/javascript-journey-boston-code-c... and the companion blog post http://glebbahmutov.com/blog/journey-from-procedural-to-reactive-javascript-with-stops/ http://glebbahmutov.com/blog/journey-from-procedural-to-reac... plus repo of the code that shows every style of JS, including Redux and Reactive https://github.com/bahmutov/javascript-journey https://github.com/bahmutov/javascript-journey
Omnipresent 11y ago
For someone who hasn't had to do much work on the front end JS technologies like Ember, Angular, React, etc. What is a good resource to start learning Angular 2 (even though its not out yet)? I came across ng-book2 [0] but I've heard mixed reviews about their first book. [0] https://www.ng-book.com/2/ https://www.ng-book.com/2/
- kotojo 11y ago
  Egghead.io has some good stuff so far. https://egghead.io/technologies/angular2 https://egghead.io/technologies/angular2
  - gamesbrainiac 11y ago
    I have to say that it does not start from scratch when it teaches angular 2, it expects you to have some understanding of angular to understand what's going on.
- mtrimpe 11y ago
  I found Build Your Own Angular [1] gave me the most understanding in the least amount of time. It's geared more towards understanding (and Angular 1 not 2) and not so much towards building stuff though so YMMV. [1] http://teropa.info/build-your-own-angular http://teropa.info/build-your-own-angular
- terda12 11y ago
  Honestly? I would start with React. The way Angular 2 has been going, they are adopting a lot of new ideas from React.
  - Omnipresent 11y ago
    But what about angular being a framework and react being a library? Ido hate to invest time in react only to find out that when working on some project it doesn't provide all I need. By project I mean some backend api and front end SPA
OrthoMetaPara 11y ago
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).
spion 11y ago
Two corrections: 1. You can use types with React, either via Flow or in TypeScript with TSX. Unlike with Angular, with React you can also get type checking even in the JSX template (checking for valid component property types included, even with TypeScript) 2. You can "externalise" your render method if you really want to by simply writing import MyComponentTemplate from './external-template.tsx' let MyComponent = React.createClass({ .. render: MyComponentTemplate .. }) then in external-template.tsx export default function render() { return <template goes here>.... } Most React users think its unnecessary, but it doesn't mean its not possible.
- tlrobinson 11y ago
  React v0.14 adds "stateless functional components" syntax, which essentially makes your external-template.tsx a valid component on its own (with the caveat that no state or lifecycle methods are allowed): https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html https://facebook.github.io/react/blog/2015/10/07/react-v0.14...
  - tracker1 11y ago
    There seems to be progression into breaking apart components that have decision trees with components that are simply rendered... I've had a tendency to favor this myself. Also, simple components can defer events to prop/parent binding.
pjmlp 11y ago
- Dojo - Prototype - jQuery - Ember - ExtJS - YUI - Knockout - Angular - React - place for the next cool framework in the upcoming two years
idibidiart 11y ago
Maybe React core is in ES5 but most React components are now bejng written in ES6/7 with things like decorators and async functions, not to mention immutable data structures, and you may use Flow to substitute for static typing. I can't believe in the team behind Angular 2.x they STILL have the same basic flaw in their thinking about UI development: their ideology is in contradiction to the idea of keeping it simple yet flexible.
j1e 11y ago
For job postings, it's still an Angular 1.x world out there: http://www.indeed.com/jobtrends?q=%22angularJS%22%2C+%22ReactJS%22%2C+%22EmberJS%22&l= http://www.indeed.com/jobtrends?q=%22angularJS%22%2C+%22Reac...
kevindeasis 11y ago
I am hesitant to spend time learning on react because of this: " SomeCallMeTim: I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the direction of the industry, and then try to stay on top of the next new hot technology of the year. But I hear you on the "worse" technology sometimes winning. You mentioned Java; it was worse than just about all other major contenders, and is only finally losing popularity. On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better. And how many app teams have 100 or more active developers? Probably fewer than a dozen, and I submit that none of them probably should. Certainly not the Facebook app: It has a lot of features, but not that many features, and yet it has a 150Mb footprint. When I hear things like that, I can't help but fill in "junior" or "mediocre" in front of "developers." React helps to prevent people from breaking each others' code when you have bloated development teams filled with junior developers. React has some cool ideas, but all told I think it's a step backward for software engineering, and certainly isn't as much of a help for small teams, especially if you want to have a CSS/SCSS/LESS expert styling your product without having to dig through JSX files, for instance. The Java rationale was similar, IMO: You can use the Java abstractions to allow lots of mediocre developers to make contributions to a product without breaking each others' code. At least not as frequently as when they can poke right into random data structures and change things arbitrarily. If it weren't for Google's decision to require Java for Android, I think Java would be relegated to big company web backend development. I do like React's idea of the Virtual DOM for optimization, but you can get that without using React. [2] React Native is great for using native components and driving them from JavaScript, but it's also not the only game in town. [3] Back to the original point, though: You can stay on top of the Hot New Technologies, but when there are good technical reasons to use alternate technologies, stay on top of those as well. And then explain clearly to your clients (or employers) why the current fad is a fad, and how to get the key benefits of that stack without its drawbacks. Oh, and choose clients (or employers) who will listen to strong technical arguments. :) [1] https://www.pandastrike.com/posts/20150311-react-bad-idea https://www.pandastrike.com/posts/20150311-react-bad-idea [2] https://github.com/Matt-Esch/virtual-dom https://github.com/Matt-Esch/virtual-dom [3] https://www.nativescript.org/ https://www.nativescript.org/ "

React vs. Angular 2

160 points by kevindeasis 11y ago

vertebrate 11y ago

What is this FRP thing JS developers talking about? What I should read to learn more about it?

michaelsbradley 11y ago
It's been around in various forms, and implemented on top of various languages, for quite some time. The earliest full-fledged FRP implementation for JavaScript was Flapjax – work on it dates all the way back to 2006! http://www.flapjax-lang.org/ http://www.flapjax-lang.org/ The paper Flapjax: A Programming Language for Ajax Applications is worth reading. http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgbk-flapjax/paper.pdf http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgb... The principal designer and maintainer of the Elm Language (a functional reactive lang that compiles to JS) did his Master's Thesis on FRP, and that's a great resource if you want the big picture: https://www.seas.harvard.edu/sites/default/files/files/archived/Czaplicki.pdf https://www.seas.harvard.edu/sites/default/files/files/archi... See also Controlling Time and Space: understanding the many formulations of FRP, by the same author: https://www.youtube.com/watch?v=Agu6jipKfYw https://www.youtube.com/watch?v=Agu6jipKfYw
masklinn 11y ago
> What is this FRP thing https://en.wikipedia.org/wiki/Functional_reactive_programming https://en.wikipedia.org/wiki/Functional_reactive_programmin...
pluma 11y ago
It's a way to write applications as declarative code that defines the UI in terms of sequences of events and streams. Basically: something incredibly powerful and clever that will not be adopted by the wider developer community until someone figures out how to present it in a way that makes it accessible to someone who isn't deeply interested in academia.
- michaelsbradley 11y ago
  I don't think it's so much that it requires an interest in academia, but that it requires a shift in thinking towards abstractions that still aren't mainstream, relative to OOP (in its various forms) and unadorned events/listeners. Principally, that shift is toward higher-order functions. Yes, those same HOF abstractions are popular subjects for academic research and teaching, but they're not inherently academic subjects.
  - pluma 11y ago
    True, but this paradigm shift has been pending for nearly half a century and there doesn't seem to be any progress, just periodic rediscoveries.
sotojuan 11y ago
A small part of it is that your events are basically constant streams of data (think arrays) you can map, reduce, and filter (among other functions) and then present. Here is a short article on it: https://medium.com/@andrestaltz/2-minute-introduction-to-rx-24c8ca793877#.pzupjr8nt https://medium.com/@andrestaltz/2-minute-introduction-to-rx-... This is a discussion over the controversy of calling stuff FRP in academia vs. real world: https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-just-did-d5ffaa23973b https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-j...
tunesmith 11y ago
If you ignore the whole thing about how frp is not FRP, and how javascript developers really only mean frp, then a good place to start would be learning about RxJS. FRP is deterministic and referentially transparent, frp is not. Key concepts in FRP are behaviors, events, signals; key concepts in frp is streams, observables, subscriptions. Although I'm not expert with either, there's a lot of overlap and term overloading, and I might be explaining this all badly anyway.
- spion 11y ago
  AFAICT, the simplest way of explaining the difference between FRP and "popular frp" is that in FRP things are described as functions of time, whereas in popular frp they are streams of events. The "real" FRP is great for describing non-interactive things. They can be used to describe anumations: e.g. a FRP behavior can describe the position of a ball as a function of time: ballPosition :: t -> Position whereas in "quasi" frp, the ballPosition is a stream of Position values: ballPosition :: (Stream Position) Basically, quasi FRP is what you get when you sample real FRP at certain times :)
bahmutov 11y ago
A way to handle sequences of events - which is really powerful abstraction. Look at this (shameless self-promotion) presentation https://slides.com/bahmutov/javascript-journey-boston-code-camp-24 https://slides.com/bahmutov/javascript-journey-boston-code-c... and the companion blog post http://glebbahmutov.com/blog/journey-from-procedural-to-reactive-javascript-with-stops/ http://glebbahmutov.com/blog/journey-from-procedural-to-reac... plus repo of the code that shows every style of JS, including Redux and Reactive https://github.com/bahmutov/javascript-journey https://github.com/bahmutov/javascript-journey

Omnipresent 11y ago

For someone who hasn't had to do much work on the front end JS technologies like Ember, Angular, React, etc. What is a good resource to start learning Angular 2 (even though its not out yet)? I came across ng-book2 [0] but I've heard mixed reviews about their first book. [0] https://www.ng-book.com/2/ https://www.ng-book.com/2/

kotojo 11y ago
Egghead.io has some good stuff so far. https://egghead.io/technologies/angular2 https://egghead.io/technologies/angular2
- gamesbrainiac 11y ago
  I have to say that it does not start from scratch when it teaches angular 2, it expects you to have some understanding of angular to understand what's going on.
mtrimpe 11y ago
I found Build Your Own Angular [1] gave me the most understanding in the least amount of time. It's geared more towards understanding (and Angular 1 not 2) and not so much towards building stuff though so YMMV. [1] http://teropa.info/build-your-own-angular http://teropa.info/build-your-own-angular
terda12 11y ago
Honestly? I would start with React. The way Angular 2 has been going, they are adopting a lot of new ideas from React.
- Omnipresent 11y ago
  But what about angular being a framework and react being a library? Ido hate to invest time in react only to find out that when working on some project it doesn't provide all I need. By project I mean some backend api and front end SPA

OrthoMetaPara 11y ago

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

spion 11y ago

Two corrections: 1. You can use types with React, either via Flow or in TypeScript with TSX. Unlike with Angular, with React you can also get type checking even in the JSX template (checking for valid component property types included, even with TypeScript) 2. You can "externalise" your render method if you really want to by simply writing import MyComponentTemplate from './external-template.tsx' let MyComponent = React.createClass({ .. render: MyComponentTemplate .. }) then in external-template.tsx export default function render() { return <template goes here>.... } Most React users think its unnecessary, but it doesn't mean its not possible.

tlrobinson 11y ago
React v0.14 adds "stateless functional components" syntax, which essentially makes your external-template.tsx a valid component on its own (with the caveat that no state or lifecycle methods are allowed): https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html https://facebook.github.io/react/blog/2015/10/07/react-v0.14...
- tracker1 11y ago
  There seems to be progression into breaking apart components that have decision trees with components that are simply rendered... I've had a tendency to favor this myself. Also, simple components can defer events to prop/parent binding.

pjmlp 11y ago

- Dojo - Prototype - jQuery - Ember - ExtJS - YUI - Knockout - Angular - React - place for the next cool framework in the upcoming two years

idibidiart 11y ago

Maybe React core is in ES5 but most React components are now bejng written in ES6/7 with things like decorators and async functions, not to mention immutable data structures, and you may use Flow to substitute for static typing. I can't believe in the team behind Angular 2.x they STILL have the same basic flaw in their thinking about UI development: their ideology is in contradiction to the idea of keeping it simple yet flexible.

j1e 11y ago

For job postings, it's still an Angular 1.x world out there: http://www.indeed.com/jobtrends?q=%22angularJS%22%2C+%22ReactJS%22%2C+%22EmberJS%22&l= http://www.indeed.com/jobtrends?q=%22angularJS%22%2C+%22Reac...

kevindeasis 11y ago

I am hesitant to spend time learning on react because of this: " SomeCallMeTim: I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the direction of the industry, and then try to stay on top of the next new hot technology of the year. But I hear you on the "worse" technology sometimes winning. You mentioned Java; it was worse than just about all other major contenders, and is only finally losing popularity. On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better. And how many app teams have 100 or more active developers? Probably fewer than a dozen, and I submit that none of them probably should. Certainly not the Facebook app: It has a lot of features, but not that many features, and yet it has a 150Mb footprint. When I hear things like that, I can't help but fill in "junior" or "mediocre" in front of "developers." React helps to prevent people from breaking each others' code when you have bloated development teams filled with junior developers. React has some cool ideas, but all told I think it's a step backward for software engineering, and certainly isn't as much of a help for small teams, especially if you want to have a CSS/SCSS/LESS expert styling your product without having to dig through JSX files, for instance. The Java rationale was similar, IMO: You can use the Java abstractions to allow lots of mediocre developers to make contributions to a product without breaking each others' code. At least not as frequently as when they can poke right into random data structures and change things arbitrarily. If it weren't for Google's decision to require Java for Android, I think Java would be relegated to big company web backend development. I do like React's idea of the Virtual DOM for optimization, but you can get that without using React. [2] React Native is great for using native components and driving them from JavaScript, but it's also not the only game in town. [3] Back to the original point, though: You can stay on top of the Hot New Technologies, but when there are good technical reasons to use alternate technologies, stay on top of those as well. And then explain clearly to your clients (or employers) why the current fad is a fad, and how to get the key benefits of that stack without its drawbacks. Oh, and choose clients (or employers) who will listen to strong technical arguments. :) [1] https://www.pandastrike.com/posts/20150311-react-bad-idea https://www.pandastrike.com/posts/20150311-react-bad-idea [2] https://github.com/Matt-Esch/virtual-dom https://github.com/Matt-Esch/virtual-dom [3] https://www.nativescript.org/ https://www.nativescript.org/ "