xufei

2015年11月15日，南京GDG，幻灯片：http://xufei.github.io/slides/2015/revolution-of-angular.html#0

@sinoon 目前如果要用的话，1.x还是可以用，但写的时候要注意淡化框架相关的一些东西，这个后面我再写一篇来详细说。 虽然2.0可以用ES5来开发，但强烈建议你学ES6，未来几年内，这是必备技能。至于TypeScript，用它会有好处，也有负担，看你团队意愿了。

@imcotton 感谢提醒，忘了这里内部不是异步了。。。

@zeroone001 module后面的那个引用数组吗？我是默认这个模块已定义了。。。如果单独跑的话，要写 ``` JavaScript angular.module("app", []) ``` repeat错误这个，是因为数组序号不对，加了个0，或者用track by $index

@zeroone001 现在加上0了应该是对的啊，刚才你说的那个错误，是因为数组中会出现重复元素，索引失效。

@dolymood 我明白你的意思，就是专门弄一些空壳子，这些js文件中，每个只放module的声明对吧，这个可以解决问题，但主module必须把所有的壳子module文件全部加载进来，并且在依赖中包含。真正的业务实现的js中，不能声明module，只能使用。这么一来，这些壳子就纯属浪费了，所以我觉得还不如不要，所有的都挂主module的名字下

@jinwyp 如果只在自己的一个项目中，怎么搞都是可以的。你考虑把项目中的一个或多个部分拿出去在几个项目之间共享，尤其是这些公共部分要做懒加载的时候，就比较难受了。

@hjzheng @chinfeng 我这个不是误解，是说会有这么一种预期，比如一个新上手的人，他有很大概率会这么预期。。。

所以，前年我基于angular搞一个平台规划的时候，是这样的： https://github.com/xufei/blog/issues/7 其中有一段： > 所以我们期望的是，在每个编写的JavaScript模块中只存放具体实现，而把依赖关系放在我们的平台上管理，这样，即使当前模块作了改名之类的重构处理，处于外部项目中依赖它的那些代码也不必修改，下一次版本发布的生成过程会自动把这些事情干掉。 意思就是，模块只存放内部的controller那些实现，依赖关系外置到这个管理平台（预期是类似npm）中，然后在构建的时候，给它生成这些module的配置。这样，如果有一天我们需要把目录整体调整，也不至于到处要修改这个模块名。 如果不这样，我们就面临这样： angular.module("aa.bb.cc").controller("aa.bb.cc.ControllerD", [...]) 这样的写法，然后模块如果需要做业务上的调整，比如下沉一级目录，这些controller上面的名称都得跟着改，否则就会出现物理路径和逻辑路径不一致，也容易出现冲突。 angular 1.x其实在合理规划下，是足够支撑大型项目的，但这个module机制反而制约了它在大型工程上的使用体验，所以沦为中小型方案。其他部分并没有这么严重的缺点。 @myst729 你看看

@markyun 明明我先离职了你才去的……