Question

AngularJS 有没有缺点？MVVM 框架中有比它更好的吗

Answer 1

1. 源码太重了，有啥问题想自己干点猥琐事情的时候，很难分析和入手

2. 架构太重了，干点屁事架子一大堆。（当然，这个其实从某种意义上讲是angular的优点，为何呢，因为angular其实本质上是将后端的开发模型引入到了前端，因此呢，前端工程师可能会觉得太麻烦，后端工程师呢，就算觉得麻烦，但是理解起来很轻松，所以上手很快，跟在服务端写java没啥区别嘛。）

3. 绑定复杂的UI设计的时候，还是有些麻烦。这个很多人都提到过，directive相当复杂，我们做完一个项目都没人愿意去写directive，宁愿自己写jquery。很多人提到jquery直接操作dom是个坑，这个我完全同意，但是对我们却不是问题，因为我们的团队里的人相对来说对这些东西的关系相当清楚和熟练（事实上，我很久以前曾经在其他项目中实现过一个mini的类angluar框架，当然，那个不通用，也没法开源，但因此对angular的内部实现思路我可以说非常清楚，不用读代码我都知道他会怎么做，他能怎么做，那些坑我可都是一个一个填过来的），可以自由的在angular和jquery之间进出，因此对我们来说，写jquery比写directive方便。

4. 跟第三点也多少有些关联，就是我们希望有更“方便”的绑定的声明方式。话题稍微延伸一下，我们公司有一个自己的后端框架Asta4D，它实现了一个数据绑定和模板完全分离的模型，也就是说，我们的html里面（几乎）不会嵌入框架的任何动态声明，数据绑定的声明完全在Java代码端完成，这种模型对不但对设计非常友好，而且对后端开发人员也很友好，因为无论设计人员给出如何复杂炫酷的HTML，我们的后端人员都不需要去碰一个指头，都在自己的Java代码里面就能够完成绑定声明了。尤其是在页面有重构发生的时候，设计人员重构完的页面，在理想的情况下，我们可以无须修改数据绑定的声明，事实上，这是大多数的情况。因此，话说回来，我们的团队在习惯了这种开发模式后，对于嵌入到HTML中的数据绑定声明，有一种天然的厌恶心理，因为大多数时候设计人员修改了页面之后，开发人员都要介入修复被破坏的数据绑定。