Comment by aikah | Hacker News Reader

Comment by aikah | Hacker News Reader

Parent Full thread

> 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.

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.

I 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.

> 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.

Not really. I use Angular. A lot. I'm not so convinced that it is an "easy opt-out".

You're living in a pipedream if you think you can easily port an AngularJS app to another heavy framework like Ember or React.

Depends how well built your application is. Good luck porting a crappy Angular app over - good engineering probably trumps choice of frontend framework the most.

Do 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.

Architect[1]

[1] https://github.com/c9/architect

Unfortunately, that's not pluggable into an existing application. I was hoping for something that could be added to an existing application easily.

Reply on news.ycombinator.com