131–140 of 150 posts
> we’ve been working with Angular for almost nine months now (the original article in italian is dated February 2015)
it means this post is just a translation of something experienced a year ago (Angular 1.1) A half of the comments reply to solutions arrived on 1.4, with hindsight.
This delay is definitely not clear, but casts new light on the content.
= Problem #1: Scope inheritance and dynamic scoping
Use directive controllers
= Problem #2: Dirty checking
Use immutability
= Problem #3: Dependency injection
I'm not really sure what the author is saying here. It sounds like he's confused and thinks DI and modules solve the same problem. The one statement he has bolded is completely false: > Angular forces you to use a third, custom designed alternative mechanism: one that is inferior to the already existing mechanisms available. You can use a module system if you want. Nothing is stopping you.
= Problem #4: Pointless complexity
> providers, values, factories, services, constants [...] All five concepts could easily be assigned a single identity. True, so just use providers if that makes you happy. Angular 2 also simplifies things.
= Problem #5: Server-side rendering
He stated a solution for angular 1. Personally, I don't really care about server side rendering so I won't elaborate. Angular 2 will have angular-universal
= Problem #6: Angular 2
> Not convinced yet? Well, what if we were to tell you that the next major version of Angular will take a scorched earth approach to the existing structure that means it will have zero retro-compatibility with what exists today?
> it would be simply foolish to use Angular 1.x for new applications.
LOL, fear mongering. The angular team has already stated there will be a migration path to angular 2. They also announced they will continue to support angular 1 as long as people are using it. It's funny that he complains about angular 2 when it addresses his problems with angular 1.
EDIT: Warranted a downvote. Wow.
Earlier quoted context omitted.
Not to mention his example is just straight wrong about $scope and ng-if. His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds scope inside an ng-if. I agree that angular 1.1.5 had it's warts, if that's what this is supposed to be about. The current release version of angular is 1.4, about to be 1.5. Edit: After fully reading through this blog post; it's almost all wrong. Dirty Checking: Yes,…
Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model. As someone who's going to need to make a recommendation soon about whether or not to use Angular on a new project, this part worries me. The apps my company buil…
Earlier quoted context omitted.
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 a…
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.
Earlier quoted context omitted.
Because React solves only the directive part of Angular? I'm not saying it's great BTW, but comparing React to Angular is silly. That's like saying you chose lodash.js over Angular.
> like saying you chose lodash.js over Angular. It's a valid comparison, if you feel Angular tries to solve problems you don't have, and in doing so, causes other headaches.
Earlier quoted context omitted.
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 D…
> 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.
VDom lets you express UI as a function of the state
Observables let you express state as a function of user interactions
This article is about 2 years late. These are solved problems in angular 2 by default and have solutions in angular 1. = Problem #1: Scope inheritance and dynamic scoping Use directive controllers = Problem #2: Dirty checking Use immutability = Problem #3: Dependency injection I'm not really sure what the author is saying here. It sounds like he's confused and thinks DI and modules solve the same problem. The one sta…