感谢博主翻译。
跟随最新标准，站在未来的角度上来规划2.0版本本来无可厚非，我唯一不理解的地方，在于AtScript。因为时间精力问题，只能够使用coffeescript，所以也搞不清coffeescript，typescript，atscript之间的关系，而且因为个人喜好问题，一股浓浓的Python即视感真的让人有点纠结。

对官方公布细节的翻译在这里：#8

Nice！

脏检查和observe现在感觉就是背道而驰，这一点估计改动会很大，但也非常值得期待。
打个比方，我喜欢用defineProperty来给$scope添加一些带逻辑的纯getter属性，或者带逻辑的setter属性。
为什么？因为用原始值配合expression绑定可能做不出这么复杂的逻辑，expression绑定也解决不了v->m反向绑定中的逻辑。
而且也许我仅仅是想做一个genderText属性，getter就是return this.gender == 0 ? '男' : '女'，这的确是一个expression，但它也是个逻辑，因为有一天我可能会改成'帅哥'/'美女'，那时候也许会不幸发现那个expression已经遍布全球，改起来很费劲。
但在实际使用中我发现因为脏检查循环的存在，我的getter经常要被调用好几次，原因你懂的。
如果用observe取代脏检查，我们就可以建立起来一个真正的VM层，VM层的数据，甚至是各种复杂类型的字段，是带逻辑的，也就是所谓“视图逻辑”，expression还可以照用不误，方便，灵活。更复杂的组合属性、依赖属性就可以用getter实现了。
web component这一块，我觉得不是“不应该让扫描进入shadow dom的暗世界”，而是就像shadow dom的初衷一个样，就是隔离。外面扫外面的，里面扫里面的，这不正是现在ng的$scope隔离的概念吗。
所以这一点我觉得可真是殊途同归呀~
而我对web component比较期待的地方其实是它的dom事件隔离和css隔离。
dom事件隔离可以让组件的实现和使用都更轻松惬意，具体就不举例了，说起来都是泪。
最近也在用ng，我想尝试语义化（而非结构化）classname，比如用.color-picker>.preview取代.color-picker-preview`，因为“结构化”classname会像叠罗汉一样越来越长，越来越蛋疼。
现在我是靠less来“隔离”，但是写的不好的时候，比如子选择符写成后代选择符的时候，就很容易跪，随随便便就跟别的冲突没商量。css隔离可以让我们对css的架构和规范化这回事的理解产生一定颠覆性的变化，这是我比较期待的一点，而且这是我所知道现在CSS隔离的唯一的一个办法了……

@LiuJi-Jim getter这个的问题在哪里啊，我没明白，getter里面本来就是不该放逻辑的……这种文本的转换应当是通过filter去做啊，因为如果你需要在模型里做getter的转换，基本上一定是给视图用的，所以用filter很合适。假如模型中还存在别的转换，那就是动用$watch的时候，属于在模型内部的关联。

web components这段，可能你没明白我意思，我举个例子：

你有一个组件

<foo bar="123"></foo>

bar属性用于接收一个数字，然后把组件内部的某个东西创建这个数字这么多个，并且显示出来，这本身不会有任何问题，但考虑一个场景，我想把这个数字动态传入，这个数字从哪里来呢？从外层作用域的某个变量中来，如果是普通元素，是不是你要写：

<div ng-controller="TestCtrl">
  <input type="number" ng-model="a"/>  
  <span ng-bind="a"></span>
  <foo bar="{{a}}"></foo>
</div>

你看，a的值可以从输入框传入span并显示，但是传不到组件的bar里。如果你想里面扫里面的，那么，组件在解析插值表达式的时候，从哪里去获取这个a？所以这个问题的关键在于外层世界与组件的传值，别的是没有问题的，其他时候大家都各自做自己的事好了。

样式这块，碰到web components的时候，还是需要重新规划，思路跟之前的大有不同，我想想。

@xufei 我对filter的看法是它应该是高度可复用的util类型的东西，比如urlencode、camelCase这种就是filter，但上面我说的那个例子，或者fullName定义getter为return firstName + lastName我觉得就应该是VM属性，因为它根本不能被除了这个模型以外的别的东西所复用……因为受C#影响，我喜欢用getter/setter，于是这种事情我会觉得不是一码事。

对于<foo bar="{{a}}"></foo>的情况我感觉也没问题啊，如果ng发生了改变那么foo组件会触发attribute的修改回调，这个是web component支持的。web component内部维护一个属性，内部视图可以和这个内部苏醒双向绑定。剩下的就是维护内部属性与外部暴露出来的attribute之间的绑定了。相当于内部的绑定和外部的绑定隔离开了，中间通过attribute来做桥梁。

@LiuJi-Jim 在Angular里面，是可以把filter看作数据getter的装饰器的，它的职责其实就是干这些事。

绑定是有问题的。

这个绑定实现不了，原因是angular不知道组件有bar属性，它必须先穷举，必须预先知道元素上有哪些可插值属性，然后挨个去解析，还要区分找到的是属性还是方法。就算找到了bar，也没法知道它是不是要插值。就算知道它是要插值的，在计算出真实结果传入之前，已经把整个插值表达式传到组件内部了，一个不合法字符串。

所以问题都在内外传递这一步上。

Polymer基础层使用了以下技术：

1. DOM Mutation Oberservers和 Object.observe()：用于监视DOM元素和简单JavaScript对象的改变。该功能可能会在ECMAScript 7中正式标准化。
2. Pointer Events ：在所有的平台上以同样的方式处理鼠标和触摸操作。
3. Shadow DOM：将结构和样式封装在元素内（比如定制元素）。
4. Custom Elements：定义自己的HTML5元素。自定义元素的名字中必须包括一个破折号，它的作用类似于命名空间，为了将其与标准元素区分开来。
5. HTML Imports：封装自定义元素，包中包括HTML、CSS、JavaScript元素。
6. Model-Driven Views（MDV）：直接在HTML中实现数据绑定。仍没有标准化的计划。
7. Web Animations：统一Web动画实现API。

你们所说的问题就是MDV吧，慢慢等吧，否则自己实现扫描器

支持Polymer,未来的趋势!!!

@xufei

这个绑定实现不了，原因是angular不知道组件有bar属性，它必须先穷举，必须预先知道元素上有哪些可插值属性，然后挨个去解析，还要区分找到的是属性还是方法。就算找到了bar，也没法知道它是不是要插值。就算知道它是要插值的，在计算出真实结果传入之前，已经把整个插值表达式传到组件内部了，一个不合法字符串。

我对angular不是很熟，但是对于它解决的问题大概清楚，有点疑问：

为什么angular不是扫描元素的attributes，读到bar，然后根据值bar="{{a}}"进行插值；而是需要事先知道一个元素可插值属性列表['bar',...]。

在计算出表达式结果之前，传入组件内部的值是不合法内容。这不算问题吧，现在的angular+html元素也有这个问题。所以angular在逻辑完成之前会先隐藏内容，计算完成后再更新属性，这时候的属性是合法的，控件对应地更新状态就好了。

Polymer还没碰过，周末看一下先。

@RubyLouvre 正美同学的“不要让数据绑定接触到Web Components”是什么意思？

按说你是区分不出一个自定义元素和html本身元素的，所以机制应该是一视同仁的。

当然你可以说我根据自定义元素的规则（带有 - 的）来区分。可是别忘了还有 type extension 的情况（尽管我觉得type extension这个名字有点问题），就是对现有元素的增强，如 <div is="my-decorator">，所以那上面既有本身html的属性和事件，也有扩展的属性和事件。

@hax 他的意思是：不要让绑定扫描机制跨越组件内外。我举个例子：

之前Angular里面的元素指令，如果我们造这么个元素Panel，把它放在一个div中：

<div ng-controller="TestCtrl">
  <Panel></Panel>
</div>

比如这个TestCtrl是外层的视图模型，里面的所有变量，其实可以在Panel的内部实现中用于绑定。

但是如果用Web Components来实现这个自定义元素Panel，这个事情是非常困难的，所以干脆就不要想这些事，组件外的东西限制到组件外，组件内的东西如果有绑定，内部自行通过一个公共类处理。

但我的疑问在于，假如恰好在组件直接使用的时候，要从外部带入一个值，怎么办？

比如TestCtrl里面有变量a和b，我只是想这样：

<div ng-controller="TestCtrl">
  <Panel title="{{a + b}}"></Panel>
</div>

这个从使用者的角度，并未破坏Web Components的封装性，因为没有干涉内部实现，所以应当还是允许比较好，否则，自定义元素与原生元素的行为就不一致了。

@RubyLouvre “自行通过公共类处理”是什么意思？让组件自己import相关的model？这不是break了封装和复用性嘛。

我理解中组件必然需要数据绑定。因为可以把组件理解为增强性的form controls，所以是最需要数据绑定的部分。

@hax 他意思是，内外各自绑各自的，但是如果像我上面举的例子，那个表达式只能让外层去解析，内层能拿到表达式，拿不到执行上下文，还是绑不了

浴火是了，重生倒未必，我有几点不太同意楼主：

1. module 更多是被 es6 的语言机制 import + class 取代了，至于楼主说的几个所谓的缺点，我认为本来就不是 module 设计上的初衷，楼主似乎把这个东西的设计初衷的臆想成与 AMD 等价物了。
2. 考虑动态加载机制，并不只是 module 机制能解决的问题。其实 hack 2-3行 ng 的源码，动态加载模块的功能就可以实现，所以 module 不是动态加载机制的元凶。hack 以后的代码基本上就是所有节点都 complie-link 一次，差不多就是再运行一次 bootstrap。所以这需要生命周期管理的整个设计要改变，然后各种算法也要重新设计成可以多次重入。所以 ng 的生命周期机制才是动态加载的元凶。
3. ES 没有语法机制的支持，也没有 getter/setter 的编码文化，如果支持 POJSO 除了 dirty-checking 循环比较新旧值，你还有更好的办法吗？就如 Rivet.JS 那样强制使用 getter/setter，但对于多层嵌套的对象，getter/setter 就让编码的难度加大了，缺点也是同样也很明显。
4. web component 一块，我认为“不让扫描进入暗世界”不是正确的思路，入口点应该给予程序员选择的余地，这个参数是按值（组件内不可改变该值）还是按引用（组件内可以改变这个值）传递，都应该予以支持。可以看到 angular.module 的 value 和 constant，directive 的 '@' 和 '=' 传参，都体现了这个属性传递处理的明确性，我认为这个在 ng1 里面就已经没什么可以纠结的了。

所以，还能叫 ng，只是利用了一些语言上的新特性来重写一次 angular。从目前的文档来看，浴火的是：class 取代了 controller，干掉了 $scope，annotation 取代了 module。但是骨架仍然 1.x 的形状，重生是未必。

感谢，文章翻译得好啊，后面的讨论也有趣。谢谢上面各位。

nice

nice.

还打算学Angular，Angular2出来Angular是不是就没用了，还有必要学Angualr么？

大家的讨论很精彩，赞一个。

学习了~原来ng2的变革如此之大！

ng2已经弃用AtScript改用TypeScript了

@xufei 已经说得很清楚了，angular1是不能动态加载组件的 @nighca

比如：

<div id="container" ng-controller="myController">
  <p class="text-center bg-info" ng-hide="testValue">加载中...</p>
  <p ng-show="testValue">testValue: {{testValue}}</p>
  <hello data-some-val="{{testValue}}"></hello>
</div>

指令hello的属性值这样传进去就报错了。所以这时只能通过事件广播的方式对指令进行更新，非常不方便

谷歌把angular毁了。angular本不配称框架，现有知识的敏捷利用的价值让一代备受追捧，但真不是框架，也没想。谷歌非要强加自己天下一统舍我其谁的个性，完蛋。重写也是个自恋的说法，不得不扔出DI，显示性编程，设计模式里的古怪名字来，一团乱麻，又一个Java类语言。本质问题是异步不是主要问题，service根本就是evil。数据本地化才是app的王道，而所谓的稀释依赖不过是自找麻烦，web app那些需求全世界都知道，你多做点，开发人就少做点。占领市场对谷歌才是最重要的，就跟安卓一样，哭的是码农们，跟着这么个利益驱动，没有品味的大佬，永远痛苦抑郁。同样是框架，ember2年前就明白核心问题。完全是好比苹果和安卓的情况。也难怪，ember的创始人就是来自苹果。

啥玩意都不能免俗，临近秋天大家都要吃起羊肉了。。es6、组件化都是当下趋势，与时俱进，蛮好的，各位可以马上玩起来

再谈angularJS数据绑定机制及背后原理—angularJS常见问题总结
http://www.zhoulujun.cn/zhoulujun/html/webfront/ECMAScript/angularjs/2018_0417_8097.html,
依照本人的口味对您的面试题做了些整理。如有不妥，望告知。