
Refactoring legacy AngularJS - ralmidani
http://conferences.oreilly.com/fluent/javascript-html-us/public/schedule/detail/46677
======
ralmidani
Disclosure: Ember is my preferred framework. I am aware this may start another
Angular vs. Ember discussion.

Given that Angular has been in widespread use for about half a decade, I find
it interesting that there is already a need for a lecture on how to deal with
legacy Angular code.

"A side effect of the popularity of AngularJS is that we are collectively
creating a legacy of enterprise applications that require maintenance and
improvement. In the rush to meet our deadlines, we sometimes take shortcuts
that result in monolithic, confusing code."

The problem, as I see it, is that Angular makes it too easy to take shortcuts.
No concrete model layer, no explicitly declared dependencies when binding,
etc. are a disaster waiting to happen.

Why spend time learning Angular, writing unmaintainable code, then have to
learn refactoring patterns (outside the core framework) when you could have
best practices baked into the framework itself?

Edit: fixed a typo.

~~~
bryanrasmussen
why write unmaintainable code in Angular when the selling point of Angular is
that it provides you a way to maintain your code.

to put it another way, if you're going to be writing unmaintainable code
anyway do it in Vanlla JavaScript.

~~~
ralmidani
My point is that Angular does not enforce separation of concerns, making it
easier to write unmaintainable code even though you're technically using a
framework.

~~~
lollipop25
This is the wrong way of thinking. Angular allows you to be flexible by not
strongly enforcing a convention, a convention that may not fit your needs
technically. If you find Angular terrible, then _it doesn 't fit your needs_.
Move on and find another framework. Nobody is telling you to stay.

However, writing "unmaintainable code" is the choice of a developer and his
team. That has nothing to do with the framework.

