10 ms·

Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event list

Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event listener for every onclick, onchange, and onkeypress. I want the values in my models and the values in the DOM to be in sync. I like using nearly straight up HTML as my template. I do this in Django, so why not in Angular? I like that I don't need to render things server-side because then the server is just running a REST-ful API. That way I can write different clients for the API and don't have to change the server (mobile app, desktop UI, etc.) I like the clean separation between presentation (HTML templates), UI logic (controllers), and communication (services). I feel like Angular's biggest problem is the documentation. It starts out talking about things like dependency injection and why that's good, instead of simply displaying how to use the framework. It's got a steep learning curve and it just seems that people get scared of the documentation and run away before they really give it a try.

jfoster 11y ago
I think Angular is so widely used because so many people do like it. It has quirks and shortcomings (per the article), but those are only relevant because it is generally liked and used by so many. I agree on the documentation being unusual. I found the Angular Style Guide to be a huge help: https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide
- wallawe 11y ago
  Totally agree. That style guide has changed the way I write Angular apps completely, and it feels so much cleaner.
lhorie 11y ago
> it just seems that people get scared of the documentation and run away before they really give it a try Anedoctally, as the author of another JS framework (http://mithril.js.org http://mithril.js.org), I see a lot of people migrating away from Angular due to complexity, bloat and performance issues. I, myself, spent a good two years wrestling w/ Angular problems full time before jumping ship. Our apps were quite complex and we were fully invested in trying to make Angular work, and definitely not just making a half-assed effort to like it. So it's definitely not just newbies.
- code_sterling 11y ago
  I like Mitiril, but the way you manage your view layer doesn't work for me. I've tried several "build a Dom in code" approaches before, and they haven't proven to be very maintainable in the long run, especially for larger and more complex solutions. Additionally, the cost of migrating an app is much much higher. So while this post is mostly FUD, your points are valid, I feel all frameworks come with a tradeoff.
  - davexunit 11y ago
    I love Mithril's (and other's) "build a DOM in code" approach. Traditional templating systems are always limited domain-specific languages that add lots of complexity for things that should be simple, template "partials" and iteration come to mind instantly. Making the virtual DOM tree a first-class value that can be treated as a persistent data structure is a huge win. Templates are functions that return a virtual DOM node. Rendering a list is a map from Thing -> virtual DOM node. Redundant rendering is avoided with memoization. "Partials" are just functions. The system handles escaping and prevents XSS vulnerabilities by distinguishing plain strings from DOM nodes, which string-based templating systems do not do. All of the complexity and difficulty of working with templating systems goes away when we can just use the usual functional combinators we all know and love to compose views. On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. Angular just doesn't compose well with other things like Mithril and other primarily functional libraries do. I should really write a blog post on this.
    - Touche 11y ago
      > On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. How are you using an FRP library with Mithril? I thought with vdom libraries you never touch the real DOM.
      - davexunit 11y ago
Scarbutt 11y ago
I like that I don't need to render things server-side because then the server is just running a REST-ful API. That way I can write different clients for the API and don't have to change the server (mobile app, desktop UI, etc.) How is that specific to Angular?
- IgorPartola 11y ago
  It's not, but TFA mentions lack of server-side rendering as an Angular drawback.
reitoei 11y ago
I've been working pretty much exclusively with Angular for the past 18 months on some high volume financial processing systems. Shipped 3 codebases that would probably be considered 'large'. It's been one of the best development experiences I've ever had. The learning curve is steep, but when you get into the groove, when it finally clicks, then you can really take off with it. I love the tooling (node, Yeoman, Grunt, jshint, karma, protractor etc.). While not perfect, it's definitely helped me write better, more readable code. The one article that helped me get to my 'gotcha' stage was this one by Todd Motto: http://toddmotto.com/rethinking-angular-js-controllers/ http://toddmotto.com/rethinking-angular-js-controllers/
- PretzelFisch 11y ago
  We have been dealing with a large angular front end and our big problem is really more along the lines of using watchers to take the place of what should be handled by a domain model. I don't think this is a problem with Angular but an issue with JSON. I have yet to find something that can take serialized JSON and hydrate a domain object in javascript.
deleted 11y ago
[deleted]
at-fates-hands 11y ago
I really like Angular and have been able to pick it up faster than other frameworks. Mainly because its a complete framework as opposed to having to mix it with other frameworks like Backbone or React has to do with Express or Ampersand My only gripe is having so much code in the HTML that it makes it nearly unreadable. Maybe this is just the people I've worked with who do this. I think most of this could/should be put in separate controllers?
untog 11y ago
IMO there is no problem with Angular, except when people use it as a square peg with a round hole. It's ideal for your use case - lots of data entry, forms, etc. etc. But then someone tries to write a blog platform with it, or something. I think part of the problem is that everyone wants there to be The Next Thing that will solve all problems, when that doesn't exist.
- crimsonalucard 11y ago
  This is the problem with angular. Why are people using it as a square peg with a round hole? Is it because people are stupid or is it because angular is stupid? Looks to me angular is a round peg disguised as a square one.
coldtea 11y ago
>Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event listener for every onclick, onchange, and onkeypress. I want the values in my models and the values in the DOM to be in sync. React solves all of those in a cleaner way. >I like using nearly straight up HTML as my template. And yet you don't. You use Angular-ized HTML as your template.
- cloakandswagger 11y ago
  I work with React daily and love it but will freely admit that using it for simple data-binding for input heavy forms is a gigantic ass-pain. If you're using Flux, you end up with an immense amount of boilerplate action and store code around every input field. The other option is to violate the model, make all your inputs uncontrolled and have boilerplate onChange listeners for each one. Choose the right tool for the job. Angular's no-questions-asked data-binding is perfect for this scenario.
  - i_s 11y ago
    It is incredibly easy to write a function that creates an input field and keeps track of the state wherever you want, so I don't think that is a valid criticism at all.
  - bryanlarsen 11y ago
    I've got a React app which is basically just one giant form. My inputs are not uncontrolled, I use boilerplate onChange listeners, and I'm not violating the "model".
seanwilson 11y ago
I agree with this, I've been using Angular for a while now and like it. Every time I read these criticisms of Angular, I always think...compared to what? For example, I don't find fixing occasional performance issues when using two way binding a big deal. Two way binding makes my UI code much more concise and free from bugs concerning keeping models and the DOM in sync. I've worked with Backbone before for instance and found that dealing with listeners and syncing manually was a huge source of bugs.
- 3pt14159 11y ago
  Compared to Ember. Most of the time all you need is a computed property. It simplifies the code base and allows the framework to make optimizations where it needs to. If you really need a two way binding you can always do it with a computed alias.
  - seanwilson 11y ago
    Are there any cons to the way Ember does things?
  - grumblestumble 11y ago
    ember's computed properties are irrelevant if you're targeting any kind of modern browser. Object.defineProperty is the standardized way to do this and perfectly possible within Angular-land (and more performant than literring your code with $watches)
    - bluepnume 11y ago
      How are Ember's computed properties analogous to defineproperty? The latter doesn't give me dependencies for my properties, so may as well just be functions. Ember's properties will only need to be recalculated when their dependent properties change.
    - deleted 11y ago
      [deleted]
ebbv 11y ago
I enjoyed Angular 1.x. But I feel burned really badly by 2.0. I learned 1.3 shortly before 2.0 was announced and it was a really frustrating experience to have just felt like I learned this tool and then have everything thrown out the window. So, I'm not excited about learning 2.0 and haven't yet. I believe the claims that it's faster/better, but the way they threw everything out the window with 2.0 makes me concerned that I'll get burned again.
- lloyd-christmas 11y ago
  You can upgrade bits and pieces as you learn it: http://angularjs.blogspot.de/2015/08/angular-1-and-angular-2-coexistence.html http://angularjs.blogspot.de/2015/08/angular-1-and-angular-2... It will end up being no different than any other tech learning curve without breaking your application.
thoman23 11y ago
> "I like that I don't need to render things server-side because then the server is just running a REST-ful API." Thank you! I never understood the big push towards server-side rendering. I did server side rendering for 10+ years in JSP land. I love having a clean separation between client and server, freeing me to experiment with different languages and frameworks on the server side. Likewise, if I want to experiment with a React component consuming my REST API I can. Not to mention my AWS expenses are kept minimal as most of the processing is offloaded to the client side. > "I like using nearly straight up HTML as my template." Agreed again. Am I the only one who works with people who know HTML, CSS, and a little bit of Javascript who can contribute to the front end design? I feel like if I threw a "DOM in code" type of approach at them they would feel lost.
steven777400 11y ago
I like those things (data bindings, values in models) too but Angular isn't the only solution. I don't like Angular's heavy handedness, and I really really don't like mixing JS and HTML (which rules out Ember or React). I personally find Knockout to be almost the sweet spot. Very lightweight, plays well with others, doesn't "take over" or try to impose a top-down ordering on the page. I know the rest of the developer world has moved on but I'm hoping I can hold on to using Knockout long enough until another MVVM system which separates view and model but binds them together comes along.
cmdkeen 11y ago
I'm also a major fan of two way binding, but I agree with the problem the article raises re dirty checking. I much prefer Knockout because for the price of writing observable(value) rather than field = value I don't have to worry about dirty checking or the knock on effects of updating a value. Combine it with Typescript and you quickly get over the learning curve of calling to set a value rather than assigning. On the server side rendering front I'd be curious to know if you do LOB apps. In my in house dev world where people are almost always within 100m of the server and used to Oracle Forms the experience you are describing is easy, fast and blows user's minds.
aikah 11y ago
I have no issue liking angularjs. It's everywhere in the industry so let's not think that everybody hates it. It has problems , but I've yet to see a framework that allows developers to write complex front-end apps faster. There is none in my opinion. Anything that involves settings up events in some ways (and React usage involves writing event handlers) is a no deal for me.
mcv 11y ago
> Sometimes I feel like I'm the only one who actually likes Angular. Why? You're obviously not the only one, considering Angular's immense (and deserved) popularity. The simple fact is that popularity does not immunize it to having some problems. Angular is great, but it's hardly perfect. The issues with scope (gone in 2.0), the complexity of directives (also gone in 2.0, I think) are well known and being addressed.

jfoster 11y ago

I think Angular is so widely used because so many people do like it. It has quirks and shortcomings (per the article), but those are only relevant because it is generally liked and used by so many. I agree on the documentation being unusual. I found the Angular Style Guide to be a huge help: https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide

wallawe 11y ago
Totally agree. That style guide has changed the way I write Angular apps completely, and it feels so much cleaner.

lhorie 11y ago

> it just seems that people get scared of the documentation and run away before they really give it a try Anedoctally, as the author of another JS framework (http://mithril.js.org http://mithril.js.org), I see a lot of people migrating away from Angular due to complexity, bloat and performance issues. I, myself, spent a good two years wrestling w/ Angular problems full time before jumping ship. Our apps were quite complex and we were fully invested in trying to make Angular work, and definitely not just making a half-assed effort to like it. So it's definitely not just newbies.

code_sterling 11y ago
I like Mitiril, but the way you manage your view layer doesn't work for me. I've tried several "build a Dom in code" approaches before, and they haven't proven to be very maintainable in the long run, especially for larger and more complex solutions. Additionally, the cost of migrating an app is much much higher. So while this post is mostly FUD, your points are valid, I feel all frameworks come with a tradeoff.
- davexunit 11y ago
  I love Mithril's (and other's) "build a DOM in code" approach. Traditional templating systems are always limited domain-specific languages that add lots of complexity for things that should be simple, template "partials" and iteration come to mind instantly. Making the virtual DOM tree a first-class value that can be treated as a persistent data structure is a huge win. Templates are functions that return a virtual DOM node. Rendering a list is a map from Thing -> virtual DOM node. Redundant rendering is avoided with memoization. "Partials" are just functions. The system handles escaping and prevents XSS vulnerabilities by distinguishing plain strings from DOM nodes, which string-based templating systems do not do. All of the complexity and difficulty of working with templating systems goes away when we can just use the usual functional combinators we all know and love to compose views. On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. Angular just doesn't compose well with other things like Mithril and other primarily functional libraries do. I should really write a blog post on this.
  - Touche 11y ago
    > On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. How are you using an FRP library with Mithril? I thought with vdom libraries you never touch the real DOM.
    - davexunit 11y ago

Scarbutt 11y ago

I like that I don't need to render things server-side because then the server is just running a REST-ful API. That way I can write different clients for the API and don't have to change the server (mobile app, desktop UI, etc.) How is that specific to Angular?

IgorPartola 11y ago
It's not, but TFA mentions lack of server-side rendering as an Angular drawback.

reitoei 11y ago

I've been working pretty much exclusively with Angular for the past 18 months on some high volume financial processing systems. Shipped 3 codebases that would probably be considered 'large'. It's been one of the best development experiences I've ever had. The learning curve is steep, but when you get into the groove, when it finally clicks, then you can really take off with it. I love the tooling (node, Yeoman, Grunt, jshint, karma, protractor etc.). While not perfect, it's definitely helped me write better, more readable code. The one article that helped me get to my 'gotcha' stage was this one by Todd Motto: http://toddmotto.com/rethinking-angular-js-controllers/ http://toddmotto.com/rethinking-angular-js-controllers/

PretzelFisch 11y ago
We have been dealing with a large angular front end and our big problem is really more along the lines of using watchers to take the place of what should be handled by a domain model. I don't think this is a problem with Angular but an issue with JSON. I have yet to find something that can take serialized JSON and hydrate a domain object in javascript.

deleted 11y ago

[deleted]

at-fates-hands 11y ago

I really like Angular and have been able to pick it up faster than other frameworks. Mainly because its a complete framework as opposed to having to mix it with other frameworks like Backbone or React has to do with Express or Ampersand My only gripe is having so much code in the HTML that it makes it nearly unreadable. Maybe this is just the people I've worked with who do this. I think most of this could/should be put in separate controllers?

untog 11y ago

IMO there is no problem with Angular, except when people use it as a square peg with a round hole. It's ideal for your use case - lots of data entry, forms, etc. etc. But then someone tries to write a blog platform with it, or something. I think part of the problem is that everyone wants there to be The Next Thing that will solve all problems, when that doesn't exist.

crimsonalucard 11y ago
This is the problem with angular. Why are people using it as a square peg with a round hole? Is it because people are stupid or is it because angular is stupid? Looks to me angular is a round peg disguised as a square one.

coldtea 11y ago

>Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event listener for every onclick, onchange, and onkeypress. I want the values in my models and the values in the DOM to be in sync. React solves all of those in a cleaner way. >I like using nearly straight up HTML as my template. And yet you don't. You use Angular-ized HTML as your template.

cloakandswagger 11y ago
I work with React daily and love it but will freely admit that using it for simple data-binding for input heavy forms is a gigantic ass-pain. If you're using Flux, you end up with an immense amount of boilerplate action and store code around every input field. The other option is to violate the model, make all your inputs uncontrolled and have boilerplate onChange listeners for each one. Choose the right tool for the job. Angular's no-questions-asked data-binding is perfect for this scenario.
- i_s 11y ago
  It is incredibly easy to write a function that creates an input field and keeps track of the state wherever you want, so I don't think that is a valid criticism at all.
- bryanlarsen 11y ago
  I've got a React app which is basically just one giant form. My inputs are not uncontrolled, I use boilerplate onChange listeners, and I'm not violating the "model".

seanwilson 11y ago

I agree with this, I've been using Angular for a while now and like it. Every time I read these criticisms of Angular, I always think...compared to what? For example, I don't find fixing occasional performance issues when using two way binding a big deal. Two way binding makes my UI code much more concise and free from bugs concerning keeping models and the DOM in sync. I've worked with Backbone before for instance and found that dealing with listeners and syncing manually was a huge source of bugs.

3pt14159 11y ago
Compared to Ember. Most of the time all you need is a computed property. It simplifies the code base and allows the framework to make optimizations where it needs to. If you really need a two way binding you can always do it with a computed alias.
- seanwilson 11y ago
  Are there any cons to the way Ember does things?
- grumblestumble 11y ago
  ember's computed properties are irrelevant if you're targeting any kind of modern browser. Object.defineProperty is the standardized way to do this and perfectly possible within Angular-land (and more performant than literring your code with $watches)
  - bluepnume 11y ago
    How are Ember's computed properties analogous to defineproperty? The latter doesn't give me dependencies for my properties, so may as well just be functions. Ember's properties will only need to be recalculated when their dependent properties change.
  - deleted 11y ago
    [deleted]

ebbv 11y ago

I enjoyed Angular 1.x. But I feel burned really badly by 2.0. I learned 1.3 shortly before 2.0 was announced and it was a really frustrating experience to have just felt like I learned this tool and then have everything thrown out the window. So, I'm not excited about learning 2.0 and haven't yet. I believe the claims that it's faster/better, but the way they threw everything out the window with 2.0 makes me concerned that I'll get burned again.

lloyd-christmas 11y ago
You can upgrade bits and pieces as you learn it: http://angularjs.blogspot.de/2015/08/angular-1-and-angular-2-coexistence.html http://angularjs.blogspot.de/2015/08/angular-1-and-angular-2... It will end up being no different than any other tech learning curve without breaking your application.

thoman23 11y ago

> "I like that I don't need to render things server-side because then the server is just running a REST-ful API." Thank you! I never understood the big push towards server-side rendering. I did server side rendering for 10+ years in JSP land. I love having a clean separation between client and server, freeing me to experiment with different languages and frameworks on the server side. Likewise, if I want to experiment with a React component consuming my REST API I can. Not to mention my AWS expenses are kept minimal as most of the processing is offloaded to the client side. > "I like using nearly straight up HTML as my template." Agreed again. Am I the only one who works with people who know HTML, CSS, and a little bit of Javascript who can contribute to the front end design? I feel like if I threw a "DOM in code" type of approach at them they would feel lost.

steven777400 11y ago

I like those things (data bindings, values in models) too but Angular isn't the only solution. I don't like Angular's heavy handedness, and I really really don't like mixing JS and HTML (which rules out Ember or React). I personally find Knockout to be almost the sweet spot. Very lightweight, plays well with others, doesn't "take over" or try to impose a top-down ordering on the page. I know the rest of the developer world has moved on but I'm hoping I can hold on to using Knockout long enough until another MVVM system which separates view and model but binds them together comes along.

cmdkeen 11y ago

I'm also a major fan of two way binding, but I agree with the problem the article raises re dirty checking. I much prefer Knockout because for the price of writing observable(value) rather than field = value I don't have to worry about dirty checking or the knock on effects of updating a value. Combine it with Typescript and you quickly get over the learning curve of calling to set a value rather than assigning. On the server side rendering front I'd be curious to know if you do LOB apps. In my in house dev world where people are almost always within 100m of the server and used to Oracle Forms the experience you are describing is easy, fast and blows user's minds.

aikah 11y ago

I have no issue liking angularjs. It's everywhere in the industry so let's not think that everybody hates it. It has problems , but I've yet to see a framework that allows developers to write complex front-end apps faster. There is none in my opinion. Anything that involves settings up events in some ways (and React usage involves writing event handlers) is a no deal for me.

mcv 11y ago

> Sometimes I feel like I'm the only one who actually likes Angular. Why? You're obviously not the only one, considering Angular's immense (and deserved) popularity. The simple fact is that popularity does not immunize it to having some problems. Angular is great, but it's hardly perfect. The issues with scope (gone in 2.0), the complexity of directives (also gone in 2.0, I think) are well known and being addressed.