5 ms·

I've tried to understand what´s so special with react from the project's home examples, but it seems to me like an api similar to angularjs's directives, only u

by bsaul 13y ago

I've tried to understand what´s so special with react from the project's home examples, but it seems to me like an api similar to angularjs's directives, only using javascript to build the widget´s html instead of a template. Could anyone here with an experience of the two enlighten me? Edit : to be more precise, i've written fairly complex directives in angular and i don't understand the problem react is better solving. Synchronisation between dom and model is something you have to deal with manually anyway since it often includes validations rules and default behaviors, that can't be guessed easily ( invalid user input, no value appearance, etc..)

spicyj 13y ago
Does this post answer any of your questions? http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-AngularJS-A-Closer-Look http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-Angu... Declarative syntaxes are easier to work with because you can look at your template and see exactly what the UI will look like. Since you're not doing the DOM manipulation yourself, it's completely airtight and you don't need to worry about writing custom DOM manipulation code for each individual part of the UI that can change. Of course, in any framework you can rerender the entire DOM by setting innerHTML on the top level but that tends to be slow and you need to watch out about resetting scroll position, input focus (and value), etc. React takes care of all of this for you. (You're right that invalid user input is something you need to deal with regardless, but you should need to deal with that only when making forms, never when displaying data that you already have (which is the common case). As for fallback values, it's easy to write something like <div>{this.props.author || "(anonymous)"}</div> in React when building a view.)
adamnemecek 13y ago
There was a quora thread where they did some superficial comparison http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-AngularJS-A-Closer-Look?share=1 http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-Angu...
grayrest 13y ago
If you're already using directives to get all your app's state out of the DOM then there's not a lot of practical benefit to using React over Angular. You get some perf gains due to the DOM update batching and it's conceptually cleaner. I think Angular is better for a mixed designer/developer team if the dev builds directives with the goal of letting the designer work independently since non-directive Angular is extremely easy to learn. The excitement here is that React is a MUCH better match for Clojurescript. The React model is a one way rendering into a virtual DOM, computing a minimal edit list against the real DOM, and applying it in one batch. The idempotent render lines up with pure functions. The batch nature lines up with the epochal time model of Clojure's vars. Clojure's persistent data structures allow react to bypass model mutation checks. I discussed the topic of client side state with various people at a couple NYC Clojure meetups in the spring and at Clojure/West and everybody had ideas for a solution but nobody had THE solution. The React model, if not React itself, is that solution for Clojurescript. I'm disappointed that I didn't look into the implementation details of React when I checked it out this Summer and found it unremarkable.
- bsaul 13y ago
  Not sure i got this right, but my client side state lies in the model javascript layer (i'm talking single page application here), and the synchro between model and DOM is handled both by two-ways data binding (not exclusive to angular) and directives for micro DOM states. I don't quite see the need for diffing at the DOM layer, if you can already observe the changes on the model layer and recreate the Part of the DOM... So maybe it´s just a clojurescript thing, but i really feel like i'm missing something.
  - chenglou 13y ago
    There's no two-way binding in React, so right off the bat you get to drop that synchronization code. Check out the examples on the front page; they cover 80% of React's API. http://facebook.github.io/react/ http://facebook.github.io/react/
  - grayrest 13y ago
    You pretty much have it. React is a better match with the Clojure programming model. Pulling your application state completely out of the DOM is the key win and everything else is incremental gains/taste. Since I care about this a lot I'll write more stuff: Consider the basic conceptual model of Backbone. Your model changes, you get an event, you run your model object and matching template through your template engine, you get an HTML string and innerHTML it into the right place in the DOM. It's a simple functional transform of data into DOM in response to an event and the simplicity is a large part of the initial appeal of Backbone. The issue with the event->model+template->innerHTML sequence is what I call the idempotent update problem. The transform from model into the DOM is idempotent and as long as your model and template are the same the resulting DOM subtree will be identical. This is a problem because identical means blowing away all the state that was previously in the DOM subtree: event handlers, form fields, subcomponents, widgets from other libraries, etc. In small apps, this isn't a problem you just event delegate the listeners, be careful around your forms and widgets and you're fine. The problem is that when your app gets big enough you want to split it into components so you stay sane and once you do that you invariably want to nest your components and the idempotent update problem bites you hard. There are workarounds and people manage but you lose the conceptual simplicity of the Backbone model almost immediately. The benefit of the virtual DOM/diffing approach is that it lets you retain the simplicity of the idempotent transform of model to DOM while solving the idempotent update problem. Of course, with React you have the issue of getting things back from the DOM to your model that two way bindings give you but two way bindings are incompatible with the Clojure model. Angular templating system and bindings deliver the same benefits and it remains my preferred javascript solution to the problem. Other people complain about the introduction of a lot of extra things you need to know (scopes, change propagation, directive phases, digest cycle), how things can interact strangely (directives and repeats), and that the system is monolithic (providers, DI, promises). These are legitimate complaints but I've been interested in this problem for years and I have yet to find a system that doesn't have legitimate complaints and angular is roughly equal in complexity to anything I've found that covers the same ground.

by bsaul 13y ago

spicyj 13y ago

Does this post answer any of your questions? http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-AngularJS-A-Closer-Look http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-Angu... Declarative syntaxes are easier to work with because you can look at your template and see exactly what the UI will look like. Since you're not doing the DOM manipulation yourself, it's completely airtight and you don't need to worry about writing custom DOM manipulation code for each individual part of the UI that can change. Of course, in any framework you can rerender the entire DOM by setting innerHTML on the top level but that tends to be slow and you need to watch out about resetting scroll position, input focus (and value), etc. React takes care of all of this for you. (You're right that invalid user input is something you need to deal with regardless, but you should need to deal with that only when making forms, never when displaying data that you already have (which is the common case). As for fallback values, it's easy to write something like <div>{this.props.author || "(anonymous)"}</div> in React when building a view.)

adamnemecek 13y ago

There was a quora thread where they did some superficial comparison http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-AngularJS-A-Closer-Look?share=1 http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-Angu...

grayrest 13y ago

If you're already using directives to get all your app's state out of the DOM then there's not a lot of practical benefit to using React over Angular. You get some perf gains due to the DOM update batching and it's conceptually cleaner. I think Angular is better for a mixed designer/developer team if the dev builds directives with the goal of letting the designer work independently since non-directive Angular is extremely easy to learn. The excitement here is that React is a MUCH better match for Clojurescript. The React model is a one way rendering into a virtual DOM, computing a minimal edit list against the real DOM, and applying it in one batch. The idempotent render lines up with pure functions. The batch nature lines up with the epochal time model of Clojure's vars. Clojure's persistent data structures allow react to bypass model mutation checks. I discussed the topic of client side state with various people at a couple NYC Clojure meetups in the spring and at Clojure/West and everybody had ideas for a solution but nobody had THE solution. The React model, if not React itself, is that solution for Clojurescript. I'm disappointed that I didn't look into the implementation details of React when I checked it out this Summer and found it unremarkable.

bsaul 13y ago
Not sure i got this right, but my client side state lies in the model javascript layer (i'm talking single page application here), and the synchro between model and DOM is handled both by two-ways data binding (not exclusive to angular) and directives for micro DOM states. I don't quite see the need for diffing at the DOM layer, if you can already observe the changes on the model layer and recreate the Part of the DOM... So maybe it´s just a clojurescript thing, but i really feel like i'm missing something.
- chenglou 13y ago
  There's no two-way binding in React, so right off the bat you get to drop that synchronization code. Check out the examples on the front page; they cover 80% of React's API. http://facebook.github.io/react/ http://facebook.github.io/react/
- grayrest 13y ago
  You pretty much have it. React is a better match with the Clojure programming model. Pulling your application state completely out of the DOM is the key win and everything else is incremental gains/taste. Since I care about this a lot I'll write more stuff: Consider the basic conceptual model of Backbone. Your model changes, you get an event, you run your model object and matching template through your template engine, you get an HTML string and innerHTML it into the right place in the DOM. It's a simple functional transform of data into DOM in response to an event and the simplicity is a large part of the initial appeal of Backbone. The issue with the event->model+template->innerHTML sequence is what I call the idempotent update problem. The transform from model into the DOM is idempotent and as long as your model and template are the same the resulting DOM subtree will be identical. This is a problem because identical means blowing away all the state that was previously in the DOM subtree: event handlers, form fields, subcomponents, widgets from other libraries, etc. In small apps, this isn't a problem you just event delegate the listeners, be careful around your forms and widgets and you're fine. The problem is that when your app gets big enough you want to split it into components so you stay sane and once you do that you invariably want to nest your components and the idempotent update problem bites you hard. There are workarounds and people manage but you lose the conceptual simplicity of the Backbone model almost immediately. The benefit of the virtual DOM/diffing approach is that it lets you retain the simplicity of the idempotent transform of model to DOM while solving the idempotent update problem. Of course, with React you have the issue of getting things back from the DOM to your model that two way bindings give you but two way bindings are incompatible with the Clojure model. Angular templating system and bindings deliver the same benefits and it remains my preferred javascript solution to the problem. Other people complain about the introduction of a lot of extra things you need to know (scopes, change propagation, directive phases, digest cycle), how things can interact strangely (directives and repeats), and that the system is monolithic (providers, DI, promises). These are legitimate complaints but I've been interested in this problem for years and I have yet to find a system that doesn't have legitimate complaints and angular is roughly equal in complexity to anything I've found that covers the same ground.