9 ms·

All About Angular 2.0 (2014)

97 points by nfriedly 12y ago

_mtr 12y ago
And 11 days later... > Several months ago the general direction of Angular 2.0 began to change in critical ways. I found myself fundamentally at odds with certain aspects of the proposed design. Still, I tried to keep an open mind and explore the various possibilities. Unfortunately, I haven't been satisfied with how things have progressed since then. At this point, there are too many irreconcilable differences. The Angular that's being built is not the Angular I signed up to work on http://eisenbergeffect.bluespire.com/leaving-angular http://eisenbergeffect.bluespire.com/leaving-angular
- kofalt 12y ago
  Yikes. > What I am saying is that it is no longer fundamentally the same thing I was originally hired to help build nor is it compatible with my vision for the future. I've heard elsewhere that 2.0 will be an entirely unrelated framework which will be still called Angular for no good reason. Dismissing this opinion as a troll is no longer productive after the above commentary by an Angular developer.
  - cheriot 12y ago
    In that Angular 1.x has been iterative changes and 2.0 is a completely new architecture and code base, it's not a rumor. The angular team has been saying that since the original announcement.
  - justinzollars 12y ago
    he should create a fork
    - Kiro 12y ago
      He has Durandal. http://durandaljs.com/ http://durandaljs.com/
- cheriot 12y ago
  Keep in mind this guy's reasons for leaving. He's focused on his own vision for his own framework (Durandaljs).
  - ep103 12y ago
    Any time I've ever left a job because of a project, all that time spent working on a broken product has left me with tons of time to figure out how I would do it on my own.
    - cheriot 12y ago
      The guy's framework existed before he joined Angular, he announced that they were merging, and then he changed his mind. Your analogy doesn't quite fit. I'm skeptical of several things, but so far trusting that team has gone well for me.
- dang 12y ago
  Discussed at https://news.ycombinator.com/item?id=8619789 https://news.ycombinator.com/item?id=8619789.
- serve_yay 12y ago
  See, I find this reaction to Angular understandable, but in some ways it should apply more towards the current version than the upcoming one. I think people should be unhappier with the pile of junk that they currently have to deal with, than the fact that a bunch of it is going to change or go away. It looks like the new version does away with some unnecessary concepts (Angular itself has way too many concepts to deal with IMO) and adopts upcoming standards like module syntax. (The AtScript stuff does seem like sort of a nightmare, though apparently only contributors need to worry about it.) I hated the time I spent with Angular 1.x and the whole thing strikes me a as a complex and painful way to build applications. But the new stuff seems like a slight course-correction if you want to build apps in that way.
  - marknutter 12y ago
    > I hated the time I spent with Angular 1.x and the whole thing strikes me a as a complex and painful way to build applications. This comment baffles me. Not your cup of tea, sure, that I can understand, but complex and painful? Angular, Ember, Backbone, React, etc. are all so vastly superior to hacking together jQuery spaghetti code with imperative DOM manipulation I can't understand how anybody wouldn't be elated with the productivity gains they get from any of the modern frameworks, regardless of their syntax preferences.
    - serve_yay 12y ago
      Who said anything about jQuery or Backbone? About the complexity part, I am referring to the number of concepts one must be familiar with in order to produce a working Angular app. I mean read TFA: part of it breaks down the three varieties of directives you need to know in order to do a thing. And it's all like this, just a constant array of made-up concepts you have to digest in order to make something happen in the DOM. It's such a pain in the butt, and you constantly keep running into it -- whenever you need to output a URL to the view, you get to go hunting for the docs for $sce and figure out your exact use case just so you can spit out the damn URL.
      - marknutter 12y ago
andrewstuart2 12y ago
I'm glad to see official Google support confirmed, but I wasn't too worried about that. It's an open source project, always available on github at any version, and if Windows XP can survive this long without those provisions, then I'm sure Angular 1.x will be last a long time. I think the one thing that I would change for Angular 2.0 is the project name. With so many of the framework elements being killed, and the whole thing rewritten from scratch on a different language (AtScript, compiled to JS), with a different API, with different paradigms, the name "Angular" and the expected meaning it's built up to all developers involved doesn't apply anymore. I will soon need to update my resume to say that I'm experienced in Angular 1.x. I'll need to ask people developing projects built on Angular, "But which version do you use?" I'd say the same gripes apply to Python 2 vs Python 3. I don't want to go all Romeo and Juliet on the name here, but maybe there's room for a semver 2.1 that specifies the hitherto-unspecified contracts you can expect to be upheld if a project keeps the same name.
- juleska 12y ago
  > I'm glad to see official Google support confirmed, but I wasn't too worried about that. It's an open source project, always available on github at any version, and if Windows XP can survive this long without those provisions, then I'm sure Angular 1.x will be last a long time. For example, I still using ExtJS 3.1.1 in some projects, even the 4.x version is available for a long time, so, i totally agree with you.
- cheriot 12y ago
  Keeping the name succinctly describes how 1.x will stop adding new features and the team behind it is building 2.0. It's a good move if the community stays with them.
iamgopal 12y ago
I read it till the end, and if its all true, they are just providing new syntax to do old things, which will end up where it ended up previously. :( This I have seen in many project recently at Google, it seems like they are aggressive pushing lots of code and feature and technology in to every project without considering its effect oor its future, just keep throwing and see what sticks.
jeswin 12y ago
I don't think Angular can be fixed, without throwing out everything in 1.x. What's wrong: 1. UIs are complex. Angular tries to solve this by attaching a lot of programming capability into its templating language. That makes the template itself very complex, which is the situation with Angular right now. Instead of injecting some programming capability into html-like templating, a better way would be to insert templating into a full programming language. Example, JSX. 2. One of the great things about the evolving JS ecosystem (as seen in say, the npm registry) is that components and libraries are tiny, and usually they do only one thing. While there are a few disadvantages to this, it also gives incredible flexibility. From my experience it reduces risk (because components are smaller and better understood) and makes it possible to adopt newer ideas/tech faster (because you could incrementally add small components). Angular on the other hand, tried to do too much. 3. Frameworks should enable users to re-use what they already know, instead of making them go through dozens of pages of documentation. Learning Angular takes as much time as learning JavaScript. We should encourage libraries which take advantage of what programmers already know, so that they can spend time working on features instead of learning the framework.
- ep103 12y ago
  I don't necessarily disagree with any of your points, but 2.0 is doing the exact opposite on all three points. The front end UIs are now _more_ complex, does _more_, and requires more Angular tie in.
- Bahamut 12y ago
  The general idea behind directives is still there in 2.0. JSX does come with one fatal flaw in order to accomplish what it does - it requires extra build tooling from the get go, which makes it that much more difficult for junior developers to pick it up, along with the assault of other technologies, code structure, and paradigms they have to pick up at the same time. The beauty of the declarative direction of Angular is that it still is just regular old HTML. I do agree with #2, and it is a large part of why Angular is changing so drastically with 2.0 - part of this can be evidenced in 1.x with components being split into official optional modules (ngRoute, ngSanitize, ngAnimate, ngTouch, etc.). I somewhat agree with #3 - I feel like in order to properly use any framework, there is no way around combing through documentation and the source code. I have found that true with most libraries I have used. Angular's documentation at least has the benefit of being very thorough compared to most at least. I do disagree that libraries should only use what programmers already know though - we should be pursuing how to best foster productivity in the long term, and sometimes this means exploring new patterns.
trainwrecks 12y ago
sorry I just have to vent a little... I feel like I got wrecked twice jumping on the GWT and then the Angular train. I am not sure if I have the energy to jump on the Angular 2.0 train and get wreck once more... Any advice would be helpful.
- watty 12y ago
  My only advice is to leave web development if you're afraid of changing technologies. The web is moving at light speed, any framework you pick today will likely be significantly different or gone in 10 years.
- nfriedly 12y ago
  Well, on the one hand, GWT and Angular 1.x both still work. They might not be new and shiny anymore, but they do still get the job done. Personally, I still like using Backbone.js. I liked it from the start because I could read and easily comprehend the entire codebase. That might be a decent rule of thumb before getting very invested into a tool/framework/whatever.
- VeejayRampay 12y ago
  Google built their brand-new email product Inbox with GWT apparently. GWT might not be hip but it was still their technology of choice to build an extremely complex, intricate and convoluted web application.
- sgt 12y ago
  Angular 1.x is still highly useful right now, and will be for a years going forward. I don't think we'll see much 2.0 adoption though, but we'll see.
- marknutter 12y ago
  Don't take this the wrong way, but perhaps you should rethink your career choice. If tools changing and be supplanted by other tools causes you too much stress then I have unpleasant news for you - it will never stop. The good news is, it doesn't have to be stressful. If a tool you like works, use it! Don't worry about the shiny new stuff coming out, worry about being productive today, and you will find that your stress level will decrease dramatically. But above all, become comfortable with the fact that you will always be learning new things until the day you retire. You aren't flipping burgers.
sidcool 12y ago
Very very comprehensive article.
marknutter 12y ago
I'm really hoping this thread doesn't devolve into a framework flame war, but those who are interested in angular or currently using it would find this post very interesting. It clarifies a lot of the reasons why the Angular team felt that they needed to do a complete rewrite instead of incrementally improving 1.x and it also outlines a lot of the exciting new features they hope to include in 2.0. I personally appreciate their dedication to the web components specification and a desire to seamlessly co-exist with it. Atscript illuminated a lot of interesting programming concepts I'm not personally familiar with as a front-end developer and I'm intrigued by them. Definitely worth a read if you have time, Rob Eisenberg has a very extensive understanding of Angular.
RivieraKid 12y ago
I haven't read the article (I never used Angular), any idea how does it compare to React? Does it use the one-way-only data-binding powered by shadow DOM?
- marknutter 12y ago
  It really only makes sense to compare React to Angular's Directives because they are both trying to simplify the process of creating isolated, reusable components with data binding built in. In fact, they both use in-memory representations of the DOM to track model changes, although they differ in the actual mechanisms for doing so. Angular uses "dirty-checking" which basically tracks whether or not a model has changed in any way from its previous value and it does this on a loop. It's very simple and inexpensive but can start to perform poorly when dealing with large lists of items (in the tens of thousands). React also has an in memory representation of the DOM they call the "virtual DOM" (not to be confused with Web Components' "shadow DOM") and differs from Angular in the way it employs its diffing algorithms to efficiently and surgically respond to only the elements that need to change when a model is updated. It performs better than Angular when dealing with very large collections of items but I believe Angular is as performant or better than React in the small case. React also enforces certain restrictions by default when it comes to mutating data. While Angular encourages "two-way binding" where data can be changed by two different sources (e.g. the controller and the user changing the input field), React encourages a strict policy of one-way data passing. It is possible to restrict Angular directives to function exactly like React components, however, if you subscribe to React's core philosophies about data handling. For large applications, though, React applications get messy as they need to pass data down a very long tree of nested components. They wrote the "Flux" pattern to address this concern, but it really ends up looking like yet another version of MVC (although I like it, personally). Where React and Angular differ dramatically is in how they handle templating. Angular's philosophy from the start was to embrace HTML and a declarative programming style. They believe HTML should be embraced and extended using "Directives" which is very much in-line with the philosophies behind the coming Web Components standard. React's team, on the other hand, challenges long-held assumptions about web development like not including markup in your code, opting instead for a framework that not only encourages it, but requires it. This is a controversial aspect of React, but it makes sense when you actually try it. Some logic is better written imperatively (like if statements, map/reduce, etc.) and it's nice having everything required to render the component in one file. It does, however, require a compilation step unless you use their imperative DOM manipulation library so in that respect Angular is far easier to get up and running with (which is part of its dramatic success). In my mind, the only aspect where React really has a clear advantage is the ability to run server-side, which allows you to pre-render components before sending them to the client. This solves a variety of SEO and time-to-render issues single-page web applications often struggle with. The only caveat is that single-page apps don't typically need to be SEO friendly (like gmail or google docs, for instance) so it remains to be seen how important this differentiator really is. The React team admits it was really a happy side-effect of the virtual DOM and not really the main reason they built it, but it's compelling nonetheless. One last thing I'll mention is that currently it's a very difficult time to pick a horse in front-end development world. All signs point to Web Components becoming the next big thing, but React has made a lot of people question whether or not that's the correct approach. React has not made it a stated goal of theirs to align with the Web Components specifications like the Ember and Angular teams have. I can't say whether this is incredibly wise or foolish, but again, it's compelling. edit: I forgot to answer your original question directly: > Does it use the one-way-only data-binding powered by shadow DOM It allows for both the use of one-way binding and two-way binding, which React actually does too (although React's core team discourages using two-way binding). Neither is powered by shadow DOM so I'll assume you meant virtual DOM. I kind of answered this above but to re-iterate, both frameworks build up virtual representations of the DOM in memory to better serve data-diffing, but they both chose different mechanisms for doing said diffing which is outside the scope of this post but definitely interesting to learn about. The important point to take away is that you can restrict Angular directives to function exactly the same as React components, the only functional difference being the diffing algorithms under the hood and the templating systems used.
ttrashh 12y ago
Rob is a brilliant guy. We've used his WPF/Silverlight mvvm framework for years. Our consulting company uses durandal.js for current projects. It looks like Durandal v2 is now called Aurelia. I have high hopes for it, he knows how to write a framework. https://github.com/aurelia https://github.com/aurelia
pavlov 12y ago
When AngularJS was first created, almost five years ago, it was not originally intended for developers. It was a tool targeted more at designers who needed to quickly build persistent HTML forms. I guess this confirms it -- Angular really is the modern Visual Basic.
Nekorosu 12y ago
The Angular's level of complexity looks overwhelming. I feel like it creates more problems than it solves. I do hope I'm wrong, the man-hours put into it are not in vain and there is a good niche for this framework.

97 points by nfriedly 12y ago

_mtr 12y ago

And 11 days later... > Several months ago the general direction of Angular 2.0 began to change in critical ways. I found myself fundamentally at odds with certain aspects of the proposed design. Still, I tried to keep an open mind and explore the various possibilities. Unfortunately, I haven't been satisfied with how things have progressed since then. At this point, there are too many irreconcilable differences. The Angular that's being built is not the Angular I signed up to work on http://eisenbergeffect.bluespire.com/leaving-angular http://eisenbergeffect.bluespire.com/leaving-angular

kofalt 12y ago
Yikes. > What I am saying is that it is no longer fundamentally the same thing I was originally hired to help build nor is it compatible with my vision for the future. I've heard elsewhere that 2.0 will be an entirely unrelated framework which will be still called Angular for no good reason. Dismissing this opinion as a troll is no longer productive after the above commentary by an Angular developer.
- cheriot 12y ago
  In that Angular 1.x has been iterative changes and 2.0 is a completely new architecture and code base, it's not a rumor. The angular team has been saying that since the original announcement.
- justinzollars 12y ago
  he should create a fork
  - Kiro 12y ago
    He has Durandal. http://durandaljs.com/ http://durandaljs.com/
cheriot 12y ago
Keep in mind this guy's reasons for leaving. He's focused on his own vision for his own framework (Durandaljs).
- ep103 12y ago
  Any time I've ever left a job because of a project, all that time spent working on a broken product has left me with tons of time to figure out how I would do it on my own.
  - cheriot 12y ago
    The guy's framework existed before he joined Angular, he announced that they were merging, and then he changed his mind. Your analogy doesn't quite fit. I'm skeptical of several things, but so far trusting that team has gone well for me.
dang 12y ago
Discussed at https://news.ycombinator.com/item?id=8619789 https://news.ycombinator.com/item?id=8619789.
serve_yay 12y ago
See, I find this reaction to Angular understandable, but in some ways it should apply more towards the current version than the upcoming one. I think people should be unhappier with the pile of junk that they currently have to deal with, than the fact that a bunch of it is going to change or go away. It looks like the new version does away with some unnecessary concepts (Angular itself has way too many concepts to deal with IMO) and adopts upcoming standards like module syntax. (The AtScript stuff does seem like sort of a nightmare, though apparently only contributors need to worry about it.) I hated the time I spent with Angular 1.x and the whole thing strikes me a as a complex and painful way to build applications. But the new stuff seems like a slight course-correction if you want to build apps in that way.
- marknutter 12y ago
  > I hated the time I spent with Angular 1.x and the whole thing strikes me a as a complex and painful way to build applications. This comment baffles me. Not your cup of tea, sure, that I can understand, but complex and painful? Angular, Ember, Backbone, React, etc. are all so vastly superior to hacking together jQuery spaghetti code with imperative DOM manipulation I can't understand how anybody wouldn't be elated with the productivity gains they get from any of the modern frameworks, regardless of their syntax preferences.
  - serve_yay 12y ago
    Who said anything about jQuery or Backbone? About the complexity part, I am referring to the number of concepts one must be familiar with in order to produce a working Angular app. I mean read TFA: part of it breaks down the three varieties of directives you need to know in order to do a thing. And it's all like this, just a constant array of made-up concepts you have to digest in order to make something happen in the DOM. It's such a pain in the butt, and you constantly keep running into it -- whenever you need to output a URL to the view, you get to go hunting for the docs for $sce and figure out your exact use case just so you can spit out the damn URL.
    - marknutter 12y ago

andrewstuart2 12y ago

I'm glad to see official Google support confirmed, but I wasn't too worried about that. It's an open source project, always available on github at any version, and if Windows XP can survive this long without those provisions, then I'm sure Angular 1.x will be last a long time. I think the one thing that I would change for Angular 2.0 is the project name. With so many of the framework elements being killed, and the whole thing rewritten from scratch on a different language (AtScript, compiled to JS), with a different API, with different paradigms, the name "Angular" and the expected meaning it's built up to all developers involved doesn't apply anymore. I will soon need to update my resume to say that I'm experienced in Angular 1.x. I'll need to ask people developing projects built on Angular, "But which version do you use?" I'd say the same gripes apply to Python 2 vs Python 3. I don't want to go all Romeo and Juliet on the name here, but maybe there's room for a semver 2.1 that specifies the hitherto-unspecified contracts you can expect to be upheld if a project keeps the same name.

juleska 12y ago
> I'm glad to see official Google support confirmed, but I wasn't too worried about that. It's an open source project, always available on github at any version, and if Windows XP can survive this long without those provisions, then I'm sure Angular 1.x will be last a long time. For example, I still using ExtJS 3.1.1 in some projects, even the 4.x version is available for a long time, so, i totally agree with you.
cheriot 12y ago
Keeping the name succinctly describes how 1.x will stop adding new features and the team behind it is building 2.0. It's a good move if the community stays with them.

iamgopal 12y ago

I read it till the end, and if its all true, they are just providing new syntax to do old things, which will end up where it ended up previously. :( This I have seen in many project recently at Google, it seems like they are aggressive pushing lots of code and feature and technology in to every project without considering its effect oor its future, just keep throwing and see what sticks.

jeswin 12y ago

I don't think Angular can be fixed, without throwing out everything in 1.x. What's wrong: 1. UIs are complex. Angular tries to solve this by attaching a lot of programming capability into its templating language. That makes the template itself very complex, which is the situation with Angular right now. Instead of injecting some programming capability into html-like templating, a better way would be to insert templating into a full programming language. Example, JSX. 2. One of the great things about the evolving JS ecosystem (as seen in say, the npm registry) is that components and libraries are tiny, and usually they do only one thing. While there are a few disadvantages to this, it also gives incredible flexibility. From my experience it reduces risk (because components are smaller and better understood) and makes it possible to adopt newer ideas/tech faster (because you could incrementally add small components). Angular on the other hand, tried to do too much. 3. Frameworks should enable users to re-use what they already know, instead of making them go through dozens of pages of documentation. Learning Angular takes as much time as learning JavaScript. We should encourage libraries which take advantage of what programmers already know, so that they can spend time working on features instead of learning the framework.

ep103 12y ago
I don't necessarily disagree with any of your points, but 2.0 is doing the exact opposite on all three points. The front end UIs are now _more_ complex, does _more_, and requires more Angular tie in.
Bahamut 12y ago
The general idea behind directives is still there in 2.0. JSX does come with one fatal flaw in order to accomplish what it does - it requires extra build tooling from the get go, which makes it that much more difficult for junior developers to pick it up, along with the assault of other technologies, code structure, and paradigms they have to pick up at the same time. The beauty of the declarative direction of Angular is that it still is just regular old HTML. I do agree with #2, and it is a large part of why Angular is changing so drastically with 2.0 - part of this can be evidenced in 1.x with components being split into official optional modules (ngRoute, ngSanitize, ngAnimate, ngTouch, etc.). I somewhat agree with #3 - I feel like in order to properly use any framework, there is no way around combing through documentation and the source code. I have found that true with most libraries I have used. Angular's documentation at least has the benefit of being very thorough compared to most at least. I do disagree that libraries should only use what programmers already know though - we should be pursuing how to best foster productivity in the long term, and sometimes this means exploring new patterns.

trainwrecks 12y ago

sorry I just have to vent a little... I feel like I got wrecked twice jumping on the GWT and then the Angular train. I am not sure if I have the energy to jump on the Angular 2.0 train and get wreck once more... Any advice would be helpful.

watty 12y ago
My only advice is to leave web development if you're afraid of changing technologies. The web is moving at light speed, any framework you pick today will likely be significantly different or gone in 10 years.
nfriedly 12y ago
Well, on the one hand, GWT and Angular 1.x both still work. They might not be new and shiny anymore, but they do still get the job done. Personally, I still like using Backbone.js. I liked it from the start because I could read and easily comprehend the entire codebase. That might be a decent rule of thumb before getting very invested into a tool/framework/whatever.
VeejayRampay 12y ago
Google built their brand-new email product Inbox with GWT apparently. GWT might not be hip but it was still their technology of choice to build an extremely complex, intricate and convoluted web application.
sgt 12y ago
Angular 1.x is still highly useful right now, and will be for a years going forward. I don't think we'll see much 2.0 adoption though, but we'll see.
marknutter 12y ago
Don't take this the wrong way, but perhaps you should rethink your career choice. If tools changing and be supplanted by other tools causes you too much stress then I have unpleasant news for you - it will never stop. The good news is, it doesn't have to be stressful. If a tool you like works, use it! Don't worry about the shiny new stuff coming out, worry about being productive today, and you will find that your stress level will decrease dramatically. But above all, become comfortable with the fact that you will always be learning new things until the day you retire. You aren't flipping burgers.

sidcool 12y ago

Very very comprehensive article.

marknutter 12y ago

I'm really hoping this thread doesn't devolve into a framework flame war, but those who are interested in angular or currently using it would find this post very interesting. It clarifies a lot of the reasons why the Angular team felt that they needed to do a complete rewrite instead of incrementally improving 1.x and it also outlines a lot of the exciting new features they hope to include in 2.0. I personally appreciate their dedication to the web components specification and a desire to seamlessly co-exist with it. Atscript illuminated a lot of interesting programming concepts I'm not personally familiar with as a front-end developer and I'm intrigued by them. Definitely worth a read if you have time, Rob Eisenberg has a very extensive understanding of Angular.

RivieraKid 12y ago

I haven't read the article (I never used Angular), any idea how does it compare to React? Does it use the one-way-only data-binding powered by shadow DOM?

marknutter 12y ago
It really only makes sense to compare React to Angular's Directives because they are both trying to simplify the process of creating isolated, reusable components with data binding built in. In fact, they both use in-memory representations of the DOM to track model changes, although they differ in the actual mechanisms for doing so. Angular uses "dirty-checking" which basically tracks whether or not a model has changed in any way from its previous value and it does this on a loop. It's very simple and inexpensive but can start to perform poorly when dealing with large lists of items (in the tens of thousands). React also has an in memory representation of the DOM they call the "virtual DOM" (not to be confused with Web Components' "shadow DOM") and differs from Angular in the way it employs its diffing algorithms to efficiently and surgically respond to only the elements that need to change when a model is updated. It performs better than Angular when dealing with very large collections of items but I believe Angular is as performant or better than React in the small case. React also enforces certain restrictions by default when it comes to mutating data. While Angular encourages "two-way binding" where data can be changed by two different sources (e.g. the controller and the user changing the input field), React encourages a strict policy of one-way data passing. It is possible to restrict Angular directives to function exactly like React components, however, if you subscribe to React's core philosophies about data handling. For large applications, though, React applications get messy as they need to pass data down a very long tree of nested components. They wrote the "Flux" pattern to address this concern, but it really ends up looking like yet another version of MVC (although I like it, personally). Where React and Angular differ dramatically is in how they handle templating. Angular's philosophy from the start was to embrace HTML and a declarative programming style. They believe HTML should be embraced and extended using "Directives" which is very much in-line with the philosophies behind the coming Web Components standard. React's team, on the other hand, challenges long-held assumptions about web development like not including markup in your code, opting instead for a framework that not only encourages it, but requires it. This is a controversial aspect of React, but it makes sense when you actually try it. Some logic is better written imperatively (like if statements, map/reduce, etc.) and it's nice having everything required to render the component in one file. It does, however, require a compilation step unless you use their imperative DOM manipulation library so in that respect Angular is far easier to get up and running with (which is part of its dramatic success). In my mind, the only aspect where React really has a clear advantage is the ability to run server-side, which allows you to pre-render components before sending them to the client. This solves a variety of SEO and time-to-render issues single-page web applications often struggle with. The only caveat is that single-page apps don't typically need to be SEO friendly (like gmail or google docs, for instance) so it remains to be seen how important this differentiator really is. The React team admits it was really a happy side-effect of the virtual DOM and not really the main reason they built it, but it's compelling nonetheless. One last thing I'll mention is that currently it's a very difficult time to pick a horse in front-end development world. All signs point to Web Components becoming the next big thing, but React has made a lot of people question whether or not that's the correct approach. React has not made it a stated goal of theirs to align with the Web Components specifications like the Ember and Angular teams have. I can't say whether this is incredibly wise or foolish, but again, it's compelling. edit: I forgot to answer your original question directly: > Does it use the one-way-only data-binding powered by shadow DOM It allows for both the use of one-way binding and two-way binding, which React actually does too (although React's core team discourages using two-way binding). Neither is powered by shadow DOM so I'll assume you meant virtual DOM. I kind of answered this above but to re-iterate, both frameworks build up virtual representations of the DOM in memory to better serve data-diffing, but they both chose different mechanisms for doing said diffing which is outside the scope of this post but definitely interesting to learn about. The important point to take away is that you can restrict Angular directives to function exactly the same as React components, the only functional difference being the diffing algorithms under the hood and the templating systems used.

ttrashh 12y ago

Rob is a brilliant guy. We've used his WPF/Silverlight mvvm framework for years. Our consulting company uses durandal.js for current projects. It looks like Durandal v2 is now called Aurelia. I have high hopes for it, he knows how to write a framework. https://github.com/aurelia https://github.com/aurelia

pavlov 12y ago

When AngularJS was first created, almost five years ago, it was not originally intended for developers. It was a tool targeted more at designers who needed to quickly build persistent HTML forms. I guess this confirms it -- Angular really is the modern Visual Basic.

Nekorosu 12y ago

The Angular's level of complexity looks overwhelming. I feel like it creates more problems than it solves. I do hope I'm wrong, the man-hours put into it are not in vain and there is a good niche for this framework.