3 ms·

I just realized how I learned to put to good use many of the above stuff when using React. When I used to use Angular a common theme when I was writing my code

I just realized how I learned to put to good use many of the above stuff when using React. When I used to use Angular a common theme when I was writing my code was "How do I accomplish my goal by using Angular's API (as opposed to jQuery)?". With React, since my "markup" and code is all just Javascript the common theme has become "How do I accomplish my goal in plain old Javascript?". The skills I've been picking up are definitely transferable to projects that don't use React or any other JS library. Though I do keep forgetting to add `.bind(this)` all the time that it makes me miss using `var self = this;`.

EGreg 12y ago
Forgetting to use bind can be a good thing. See my comment above. As for writing things "the Angular way", it's about truly separating your MVC layers using two way databinding. I don't care how you do it as long as you keep V as declarative as possible. It sounds like "the javascript way" for you might just involve a lot of storing data in the DOM. I think a much more robust pattern involves: A Model - This is Javascript data stored outside the DOM, for easy manipulation. It is usually accessible via the window object A ViewModel - This is Javascript data that is stored outsidd the DOM but is referenced directly by a data-bound component. It can involve view transformations such as time/date localization. A View - This is the actual DOM component, in Angular it is a "directive". It reacts to changes in the ViewModel and can also change the Model (which in turn changes the ViewModel). That way, for example, if you want to implement optimistic visual feedback you can do it in the Model and have the model try to sync or revert. All this becomes even more complex when you have to build multi user apps. You can use Firebass or Parse etc. or you can check out http://platform.qbix.com http://platform.qbix.com -- open sourced but still a work in progress until 1.0
- xtrumanx 12y ago
  > It sounds like "the javascript way" for you might just involve a lot of storing data in the DOM. I don't think I've ever modified the DOM directly when using React. Try it out, it's a really refreshing take on building client-side apps.
Bahamut 12y ago
The types of problems one becomes focused on are different between the two libraries - with Angular, the problem often is how to best architect an application. The lower level stuff are not as difficult once you familiarize yourself with Angular, although that admittedly has a high upfront cost of having to familiarize yourself with it. React takes less opinions than Angular, thus leaving more for the user to determine how he/she wants to solve it. Fundamentally, React is more sound in that regard since it doesn't dominate everything as strongly - it is pretty clear that the Angular team agrees in this regard, and why they are moving to modularize everything in 2.0 (and why some formally core pieces such as the router were split off in 1.x). Using either library helps with understanding of javascript and the browser - unless you contribute to/author angular components, React probably gives more precisely since it doesn't hide as much of the complexity. My own experience with Angular has been the deeper I delve into using it, the more I find myself moving towards using pure javascript in creating abstract classes while having the Angular-specific code be extensions of those classes - this pattern is transferable between frameworks/libraries, and likely an understated best practice when working in the browser.

EGreg 12y ago

Forgetting to use bind can be a good thing. See my comment above. As for writing things "the Angular way", it's about truly separating your MVC layers using two way databinding. I don't care how you do it as long as you keep V as declarative as possible. It sounds like "the javascript way" for you might just involve a lot of storing data in the DOM. I think a much more robust pattern involves: A Model - This is Javascript data stored outside the DOM, for easy manipulation. It is usually accessible via the window object A ViewModel - This is Javascript data that is stored outsidd the DOM but is referenced directly by a data-bound component. It can involve view transformations such as time/date localization. A View - This is the actual DOM component, in Angular it is a "directive". It reacts to changes in the ViewModel and can also change the Model (which in turn changes the ViewModel). That way, for example, if you want to implement optimistic visual feedback you can do it in the Model and have the model try to sync or revert. All this becomes even more complex when you have to build multi user apps. You can use Firebass or Parse etc. or you can check out http://platform.qbix.com http://platform.qbix.com -- open sourced but still a work in progress until 1.0

xtrumanx 12y ago
> It sounds like "the javascript way" for you might just involve a lot of storing data in the DOM. I don't think I've ever modified the DOM directly when using React. Try it out, it's a really refreshing take on building client-side apps.

Bahamut 12y ago

The types of problems one becomes focused on are different between the two libraries - with Angular, the problem often is how to best architect an application. The lower level stuff are not as difficult once you familiarize yourself with Angular, although that admittedly has a high upfront cost of having to familiarize yourself with it. React takes less opinions than Angular, thus leaving more for the user to determine how he/she wants to solve it. Fundamentally, React is more sound in that regard since it doesn't dominate everything as strongly - it is pretty clear that the Angular team agrees in this regard, and why they are moving to modularize everything in 2.0 (and why some formally core pieces such as the router were split off in 1.x). Using either library helps with understanding of javascript and the browser - unless you contribute to/author angular components, React probably gives more precisely since it doesn't hide as much of the complexity. My own experience with Angular has been the deeper I delve into using it, the more I find myself moving towards using pure javascript in creating abstract classes while having the Angular-specific code be extensions of those classes - this pattern is transferable between frameworks/libraries, and likely an understated best practice when working in the browser.