3 ms·
Refactoring legacy AngularJS
- ralmidani 11y agoDisclosure: 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 11y agowhy 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 11y agoMy 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 11y agoThis 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.