3 ms·
> But it's still a risk if you build your application the "Angular Way", That's not true.AngularJS allows a total an clean separation between AngularJS and y
by aikah 12y ago
> But it's still a risk if you build your application the "Angular Way",
That's not true.AngularJS allows a total an clean separation between AngularJS and your code through dependency injection.
It means that your code can be totally decoupled from the framework (even the directives).
That's not the case for Backbone,Emberjs and others.Their first sin is the use of Active Record,which means vendor lockin,and over reliance on inheritance (Backbone.Model.extend ... )
A few month ago I had to make some business logic work in a webworker,without duplicating it ,nor using angulars,in an angularjs project. Because AngularJS uses an IoC container,it just worked,the only thing I had to do is to manually wire up dependencies,but the same code worked without a single line of Angular code.
That's the most important difference between AngularJS and the rest,easy opt-out. And I really hope the javascript world begins to embrace inversion of control ,because frankly,i'm sick of all these spaghetti code apps, I have to maintain. Only AngularJS gives you the tools to write clean and decoupled code without verbosity.
Backbone and Ember suffer from the same "rail's way" problem.AngularJS is a good compromise between configuration and conventions without Active Record .
People often say Backbone is "lightweight" ,actually I think AngularJS is lightweight compared to Backbone,and that's why it is so successfull, with one lib, one gets everything one needs to build small apps as well as large apps,without all the boilerplate.
- shangxiao 12y agoYour rambling incoherence makes your point hard to understand. So you're saying that there's no risk of vendor lock-in by relying on Angular's dependency injection, which isn't used by other libraries? Gotcha. Edit: Oh and it isn't polite to write things like "That's bullshit", then come back and edit it out later on without flagging that you've edited your code.
- kaonashi 12y agoI think he's referring to the tight coupling between the object system and the data-binding/dom-update mechanisms. React and Angular are both able to avoid those.
- aikah 12y ago> Your rambling incoherence makes your point hard to understand. So you're saying that there's no risk of vendor lock-in by relying on Angular's dependency injection, which isn't used by other libraries? Gotcha. > Edit: Oh and it isn't polite to write things like "That's bullshit", then come back and edit it out later on without flagging that you've edited your code. You look frustrated, you sound you chose the wrong framework then came here to complain about those who made a smarter choice. But you're not saying anything,other than arguing on the form.
- shangxiao 12y agoNot really. I use Angular. A lot. I'm not so convinced that it is an "easy opt-out".
- Osiris 12y agoDo you have any recommendations for good IoC containers for JavaScript, specifically node.js? I've looked at several and their are their far too complicated or not polished.
- janjongboom 12y agoArchitect[1] [1] https://github.com/c9/architect https://github.com/c9/architect
- Osiris 12y agoUnfortunately, that's not pluggable into an existing application. I was hoping for something that could be added to an existing application easily.
- mythz 12y agoYou're living in a pipedream if you think you can easily port an AngularJS app to another heavy framework like Ember or React.
- Bahamut 12y agoDepends how well built your application is. Good luck porting a crappy Angular app over - good engineering probably trumps choice of frontend framework the most.