7 ms·

Angular 1 developers should see this as an opportunity to abandon Angular and move on to React. React is by far and away the best the market has to offer right

by gasping 12y ago

Angular 1 developers should see this as an opportunity to abandon Angular and move on to React. React is by far and away the best the market has to offer right now. From my perspective client-side applications are a solved problem thanks to React.

purpletoned 12y ago
Not to mention, it's much simpler than Angular. You can get upto speed with React in 2 or 3 days. Once you make the shift to specifying single states for your interactions and letting React rebuild the DOM on changes, you'll never go back to anything else.
- gasping 12y ago
  > you'll never go back to anything else. React completely changed the way I thought about rich clients. It took me a little longer than 2 days, I went into React with an absolute hatred of anything Javascript and came out 2 weeks later loving it. There is something to be said for a library that can wash away over 10 years of built up anger for a particular technology. It's not just another revamped library thrown into the frying pan, it's a complete rethink of how rich clients can be developed almost effortlessly with code that anyone can read. When I got into react, all I could think was "yes, this makes sense, this is how it should have been all along." Moving into the future I expect most libraries will unify under the concepts introduced by React in the same way that most web applications frameworks are different flavors of MVC.
  - bryanlarsen 12y ago
    You are absolutely right. Which is why I'm so excited about Angular2. It's the first post-React client-side framework to come along. (as opposed to React which is more of a library than a framework, although it definitely pushes the boundaries of that...)
    - colinramsay 12y ago
      Technically you're right - it is post-React. But in order for it to really have learned from React I think we'd have to wait a little while longer, because the industry is still learning what React and Flux can really bring to the table. For me, one of those things is simplicity, and that's something that I feel Angular sorely lacks.
    - malandrew 12y ago
      Given the choice between two solutions capable of helping you solve a problem, why would you ever choose a framework over a library? I would never choose a framework when a library suffices.
    - Offler 12y ago
      It's not really a post-React framework though, it has been designed at the same time as React was starting to take mind share so it's not clear if they have built something that responds to what React + Flux provide.
- Bahamut 12y ago
  I disagree (about never going back) - I spent some time playing around with React (I authored https://github.com/wesleycho/angular-react https://github.com/wesleycho/angular-react ), and I found the lack of a framework for application development to be a massive void. Code organization and modularity is becoming an increasingly important problem with JS as more logic is happening in the client and more components need to be modular for fast changing requirements. Neither Angular or Flux quite solves this, but Angular provides more useful tools for managing an application. Angular has a void with the lack of a useful enough eventing solution - $scope eventing has specific use cases, but you don't want to use it as a general event bus, mainly due to performance. This is important for Angular since you don't want to couple modules together with hardcoded state keys that you may want to alter in different applications. Flux does offer a way around the eventing problem at a lower level within React components, but on a higher level, there is no application level of control - you have to construct exactly the control you want, which while liberating, also is an easy way to create a hole in architecture when designing an application if you're not careful. Angular exposes that problem directly in many ways (for example handling transitions between two urls in the application), as well as forces thinking about module dependencies with dependency injection. HTML mixed in with JS via JSX is also an abomination, that originally made me want to run far away from React when I first looked at it. I'm not a huge fan of it still, but it's not an extremely terrible thing as long as you keep higher level templates slim, which React forces you to do in order not to have huge chunks of HTML mixed in with complex JS...although I'm sure there are developers out there who do it anyway (just like there are plenty of Angular developers who will toss plenty of jQuery in an Angular controller).
  - purpletoned 12y ago
    > Angular has a void with the lack of a useful enough eventing solution - $scope eventing ... I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components. > HTML mixed in with JS via JSX is also an abomination ... Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.
- zdam 12y ago
  Can you elaborate on 'specifying single states for your interactions and letting React rebuild the DOM'... - this feels like it is a key conceptual difference but I'm not clear on what this means.
- rdtsc 12y ago
  100x that. Never got beyond all the directives, digests, factories, services, scopes, dependency injentions, all the ng-* tags and so on. That is a lot of terminology for something that is supposed to make developing web appliclations easy. Granted I am not a Web UI developer was just curious what everything was excited about. Maybe all this complexity just makes sense to someone who already did all the more complex stuff wiht jQuery? Not sure. Anyway React made sense to me. The whole data flow ideas, minizing mutable state and inter-dependencies between components, VDOM and even JSX. So I like React a lot better.
bsaul 12y ago
Not sure what in react would replace all the other angularjs part not related to directives. How does react deal with routing, web service querying, unit testing, etc... It seems to me that the integrated approach of angular isn't answered by react.
- tracker1 12y ago
  See: Flux .. I'm partial to the Yahoo implementation myself, which has a really good client-server story behind it. React would be the "View" system in the Flux workflow. You are correct that React alone won't replace Angular, but with other tools (Ampersand, Flux, etc) you can use the pieces that you want and put them together. It's the difference between a library and a framework.
  - bsaul 12y ago
    Just looked at the flux presentation from facebook, and it seems to me that it's basically a set of best practice on how to wire your view actions to your controller's model and refresh. Having a single unidirectionnal "loop" model=>view=>action=>model... is something that i have been doing inside my angular controllers for a while... Now react may help with the performances of refreshing the dom in that scenario, but so far i didn't encounter that issue myself.
    - tracker1 12y ago
      I think the performance issues tend to come when you have a lot of controls and associated bindings via angular on a page. The use of jQuery (improperly) tends to exacerbate the issue. Most people won't come across the issue, to be honest. Facebook has a lot of points of display and interaction on their pages, so it quickly becomes an issue. Not to mention the simpler flow is easier to track. I do find that the flux model makes more sense to me. Flux is a set of best practices, they use React for the rendering/view portion, and since their talks there have been several implementations of the workflow. Some using Ampersand or Backbone, others implementing their own pieces. Now Facebook has been releasing their own implementation... It's all pretty interesting.
bryanlarsen 12y ago
Angular 2 steals the best ideas from React and Meteor and everything else that has come along in the 5 years since Angular 1 came along, and puts them together in a really nice fashion. IMO, definitely the best of breed for the time being. A few months later, something new and shinier will come along. Really the choice comes down to whether you're a "single big framework" or "lots of little libraries" type of guy. The former should go with Angular2, the latter with React, IMO.
- tracker1 12y ago
  The consensus seems to be that Angular 2 won't really be ready for use until a year or two from now. I'm sticking to Flux + React for now, but looking forward to seeing Angular 2 mature. I'm hoping they gain the same client-server (shared code) capabilities that React offers.
- RivieraKid 12y ago
  I have zero knowledge of Angular, just skimmed through the presentation but didn't find it very similar to React. What ideas does it steal? Specifically, does it internally do diffing thing as React?
for_i_in_range 12y ago
Actually, I see it as the opposite. It's really not that huge of a jump from Angular 1.0 to Angular 2.0. Small example: <button ng-click="addTodo()">+</button> becomes <button (click)="addTodo()">+</button> and <div ng-controller="SantaTodoController"> literally becomes <div> Getting the advantage of 1 framework that's batteries included + universal (i.e. taught in CodeSchool, Tuts+, etc.) vs. an eclectic selection of libraries all over the place, gives Angular an advantage IMO.
rtpg 12y ago
I remember when I looked into React that I was basically writing HTML templates into javascript code. Are there ways around doing that now with React? Because I find that to be a pretty big affront to separation of concerns
- purpletoned 12y ago
  Separation of concerns is different from separation of technologies. For more details, view Pete Hunt's excellent talk at http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-best-practices.html http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...
- malandrew 12y ago
  You don't have to use JSX. You can use React.DOM directly or use react-hyperscript as a shorthand method for React.DOM Also pay attention to the new createFactory method which aims to make it easy to separate your changing HTML from the static HTML (which you would have previously used a templating library for) My recommendation is to not use JSX ever since it breaks a lot of your tooling. The first impression people get is that "Hey this makes my code easier to read", but that is only because JSX introduces the problem that it attempts to solve. Basically most HTML structures are 80% unchanging and 20% changing (the reason we use templates in the first place). React.DOM was a pain previously because you'd define a complicated HTML structure in Javascript, which isn't really any harder or more complex, but then you'd have all this code that was never changing distracting you from the code that was changing (i.e. your app behavior). JSX fixed this problem by turning all the static bits to html like templates do so it was visually easy to separate from your behavior code. This was the wrong solution because it's over engineered and breaks compatibility with a lot of things. createFactory essentially allows you to "partially apply" the static parts and get a function that only needs to deal with the dynamic parts (like compiled template functions but for virtual DOM) Anyways, check out the following links: https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript https://gist.github.com/sebmarkbage/d7bce729f38730399d28 https://gist.github.com/sebmarkbage/d7bce729f38730399d28
- spion 12y ago
  The question is whether those concerns need separating. I've come to believe that the price to pay for that "separation" is too big and ends up being a re-implementation of shared scope (see angular's $scope)
haberman 12y ago
> From my perspective client-side applications are a solved problem thanks to React. React is very cool, no doubt, and I use it in my own app, but let's not get ahead of ourselves. React is far from perfect: - the Virtual DOM is a leaky abstraction: you sometimes need to get your hands on a real DOM node: http://facebook.github.io/react/docs/working-with-the-browser.html http://facebook.github.io/react/docs/working-with-the-browse... - if you're updating the virtual DOM from anywhere other than React's event loop (for example from a setTimeout() or XHR callback), batching doesn't happen properly which can lead to inefficiency. Needing to be aware of what runs inside a React event loop vs. what doesn't can add application complexity. More info: https://groups.google.com/forum/#!topic/reactjs/LkTihnf6Ey8 https://groups.google.com/forum/#!topic/reactjs/LkTihnf6Ey8 - writing manual event handlers is a somewhat more manual and less expressive than some of the two-way data binding approaches like Knockout.js or Angular.js.

by gasping 12y ago

purpletoned 12y ago

Not to mention, it's much simpler than Angular. You can get upto speed with React in 2 or 3 days. Once you make the shift to specifying single states for your interactions and letting React rebuild the DOM on changes, you'll never go back to anything else.

gasping 12y ago
> you'll never go back to anything else. React completely changed the way I thought about rich clients. It took me a little longer than 2 days, I went into React with an absolute hatred of anything Javascript and came out 2 weeks later loving it. There is something to be said for a library that can wash away over 10 years of built up anger for a particular technology. It's not just another revamped library thrown into the frying pan, it's a complete rethink of how rich clients can be developed almost effortlessly with code that anyone can read. When I got into react, all I could think was "yes, this makes sense, this is how it should have been all along." Moving into the future I expect most libraries will unify under the concepts introduced by React in the same way that most web applications frameworks are different flavors of MVC.
- bryanlarsen 12y ago
  You are absolutely right. Which is why I'm so excited about Angular2. It's the first post-React client-side framework to come along. (as opposed to React which is more of a library than a framework, although it definitely pushes the boundaries of that...)
  - colinramsay 12y ago
    Technically you're right - it is post-React. But in order for it to really have learned from React I think we'd have to wait a little while longer, because the industry is still learning what React and Flux can really bring to the table. For me, one of those things is simplicity, and that's something that I feel Angular sorely lacks.
  - malandrew 12y ago
    Given the choice between two solutions capable of helping you solve a problem, why would you ever choose a framework over a library? I would never choose a framework when a library suffices.
  - Offler 12y ago
    It's not really a post-React framework though, it has been designed at the same time as React was starting to take mind share so it's not clear if they have built something that responds to what React + Flux provide.
Bahamut 12y ago
I disagree (about never going back) - I spent some time playing around with React (I authored https://github.com/wesleycho/angular-react https://github.com/wesleycho/angular-react ), and I found the lack of a framework for application development to be a massive void. Code organization and modularity is becoming an increasingly important problem with JS as more logic is happening in the client and more components need to be modular for fast changing requirements. Neither Angular or Flux quite solves this, but Angular provides more useful tools for managing an application. Angular has a void with the lack of a useful enough eventing solution - $scope eventing has specific use cases, but you don't want to use it as a general event bus, mainly due to performance. This is important for Angular since you don't want to couple modules together with hardcoded state keys that you may want to alter in different applications. Flux does offer a way around the eventing problem at a lower level within React components, but on a higher level, there is no application level of control - you have to construct exactly the control you want, which while liberating, also is an easy way to create a hole in architecture when designing an application if you're not careful. Angular exposes that problem directly in many ways (for example handling transitions between two urls in the application), as well as forces thinking about module dependencies with dependency injection. HTML mixed in with JS via JSX is also an abomination, that originally made me want to run far away from React when I first looked at it. I'm not a huge fan of it still, but it's not an extremely terrible thing as long as you keep higher level templates slim, which React forces you to do in order not to have huge chunks of HTML mixed in with complex JS...although I'm sure there are developers out there who do it anyway (just like there are plenty of Angular developers who will toss plenty of jQuery in an Angular controller).
- purpletoned 12y ago
  > Angular has a void with the lack of a useful enough eventing solution - $scope eventing ... I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components. > HTML mixed in with JS via JSX is also an abomination ... Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.
zdam 12y ago
Can you elaborate on 'specifying single states for your interactions and letting React rebuild the DOM'... - this feels like it is a key conceptual difference but I'm not clear on what this means.
rdtsc 12y ago
100x that. Never got beyond all the directives, digests, factories, services, scopes, dependency injentions, all the ng-* tags and so on. That is a lot of terminology for something that is supposed to make developing web appliclations easy. Granted I am not a Web UI developer was just curious what everything was excited about. Maybe all this complexity just makes sense to someone who already did all the more complex stuff wiht jQuery? Not sure. Anyway React made sense to me. The whole data flow ideas, minizing mutable state and inter-dependencies between components, VDOM and even JSX. So I like React a lot better.

bsaul 12y ago

Not sure what in react would replace all the other angularjs part not related to directives. How does react deal with routing, web service querying, unit testing, etc... It seems to me that the integrated approach of angular isn't answered by react.

tracker1 12y ago
See: Flux .. I'm partial to the Yahoo implementation myself, which has a really good client-server story behind it. React would be the "View" system in the Flux workflow. You are correct that React alone won't replace Angular, but with other tools (Ampersand, Flux, etc) you can use the pieces that you want and put them together. It's the difference between a library and a framework.
- bsaul 12y ago
  Just looked at the flux presentation from facebook, and it seems to me that it's basically a set of best practice on how to wire your view actions to your controller's model and refresh. Having a single unidirectionnal "loop" model=>view=>action=>model... is something that i have been doing inside my angular controllers for a while... Now react may help with the performances of refreshing the dom in that scenario, but so far i didn't encounter that issue myself.
  - tracker1 12y ago
    I think the performance issues tend to come when you have a lot of controls and associated bindings via angular on a page. The use of jQuery (improperly) tends to exacerbate the issue. Most people won't come across the issue, to be honest. Facebook has a lot of points of display and interaction on their pages, so it quickly becomes an issue. Not to mention the simpler flow is easier to track. I do find that the flux model makes more sense to me. Flux is a set of best practices, they use React for the rendering/view portion, and since their talks there have been several implementations of the workflow. Some using Ampersand or Backbone, others implementing their own pieces. Now Facebook has been releasing their own implementation... It's all pretty interesting.

bryanlarsen 12y ago

Angular 2 steals the best ideas from React and Meteor and everything else that has come along in the 5 years since Angular 1 came along, and puts them together in a really nice fashion. IMO, definitely the best of breed for the time being. A few months later, something new and shinier will come along. Really the choice comes down to whether you're a "single big framework" or "lots of little libraries" type of guy. The former should go with Angular2, the latter with React, IMO.

tracker1 12y ago
The consensus seems to be that Angular 2 won't really be ready for use until a year or two from now. I'm sticking to Flux + React for now, but looking forward to seeing Angular 2 mature. I'm hoping they gain the same client-server (shared code) capabilities that React offers.
RivieraKid 12y ago
I have zero knowledge of Angular, just skimmed through the presentation but didn't find it very similar to React. What ideas does it steal? Specifically, does it internally do diffing thing as React?

for_i_in_range 12y ago

Actually, I see it as the opposite. It's really not that huge of a jump from Angular 1.0 to Angular 2.0. Small example: <button ng-click="addTodo()">+</button> becomes <button (click)="addTodo()">+</button> and <div ng-controller="SantaTodoController"> literally becomes <div> Getting the advantage of 1 framework that's batteries included + universal (i.e. taught in CodeSchool, Tuts+, etc.) vs. an eclectic selection of libraries all over the place, gives Angular an advantage IMO.

rtpg 12y ago

I remember when I looked into React that I was basically writing HTML templates into javascript code. Are there ways around doing that now with React? Because I find that to be a pretty big affront to separation of concerns

purpletoned 12y ago
Separation of concerns is different from separation of technologies. For more details, view Pete Hunt's excellent talk at http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-best-practices.html http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...
malandrew 12y ago
You don't have to use JSX. You can use React.DOM directly or use react-hyperscript as a shorthand method for React.DOM Also pay attention to the new createFactory method which aims to make it easy to separate your changing HTML from the static HTML (which you would have previously used a templating library for) My recommendation is to not use JSX ever since it breaks a lot of your tooling. The first impression people get is that "Hey this makes my code easier to read", but that is only because JSX introduces the problem that it attempts to solve. Basically most HTML structures are 80% unchanging and 20% changing (the reason we use templates in the first place). React.DOM was a pain previously because you'd define a complicated HTML structure in Javascript, which isn't really any harder or more complex, but then you'd have all this code that was never changing distracting you from the code that was changing (i.e. your app behavior). JSX fixed this problem by turning all the static bits to html like templates do so it was visually easy to separate from your behavior code. This was the wrong solution because it's over engineered and breaks compatibility with a lot of things. createFactory essentially allows you to "partially apply" the static parts and get a function that only needs to deal with the dynamic parts (like compiled template functions but for virtual DOM) Anyways, check out the following links: https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript https://gist.github.com/sebmarkbage/d7bce729f38730399d28 https://gist.github.com/sebmarkbage/d7bce729f38730399d28
spion 12y ago
The question is whether those concerns need separating. I've come to believe that the price to pay for that "separation" is too big and ends up being a re-implementation of shared scope (see angular's $scope)

haberman 12y ago

> From my perspective client-side applications are a solved problem thanks to React. React is very cool, no doubt, and I use it in my own app, but let's not get ahead of ourselves. React is far from perfect: - the Virtual DOM is a leaky abstraction: you sometimes need to get your hands on a real DOM node: http://facebook.github.io/react/docs/working-with-the-browser.html http://facebook.github.io/react/docs/working-with-the-browse... - if you're updating the virtual DOM from anywhere other than React's event loop (for example from a setTimeout() or XHR callback), batching doesn't happen properly which can lead to inefficiency. Needing to be aware of what runs inside a React event loop vs. what doesn't can add application complexity. More info: https://groups.google.com/forum/#!topic/reactjs/LkTihnf6Ey8 https://groups.google.com/forum/#!topic/reactjs/LkTihnf6Ey8 - writing manual event handlers is a somewhat more manual and less expressive than some of the two-way data binding approaches like Knockout.js or Angular.js.