后Angular时代二三事 about blog HOT 45 OPEN

居然不提到 Vue，差评（逃

from blog.

关于引入编译流程

这个毫无疑问，编译这一环节现在肯定都会有， 关键是在开发阶段 “是不是要引入发布级”的编译. 比如我们现在其实也会实用browserify + commonjs 来编写较小的单页应用(4人-的项目)， 但是大型工程还是会选择AMD 的方式。 两方面考虑。

• 构建成本，时间真的应该是考虑因素了
• 团队成员的学习成本
• 我觉得是工具本身就应该独立出框架， 而不是没有工具就没法使用这套框架了， 毕竟现在IDE很弱，大部分还是得靠命令行

##关于React 和 Angular

我和飞哥的意见很一致， 入门而言肯定是模板型的更容易入门， vd对于用户是透明的，然而diff却发生在这一层。 但传统mvvm的数据却是用户真实可触碰。 这两者的使用成本不言而喻。 关键是我越来越觉得或者怀疑的是:

其实现在很多鼓吹React的人， 根本就没有尝试过传统的mvvm方案。站队、押宝性质的去接触这个社区， 满嘴一些高级术语和词汇

Angular 和 React 带来的理念都是 颠覆性的， 我觉得两者后面肯定会共存下去， 使用场景根本不是谁取代谁的冲突

关于webcomponent

最大的优势是生命周期， 这个我在昨天会议中也和你提到了， polymer 或许可以绕过， 但是custom element是绕不过的。 好在完全组件化抽象后的框架输出的内容其实很容易注册成一个custom element. 比如regularjs的一个实验性扩展，就几十行代码 https://github.com/regularjs/customelements-register ，这个angular1.0不好处理， 但是2.0 应该也容易做到。

关于路由

ng-route肯定是不够用的， 这个我同意， 关于new-router倒是后续可以仔细关注下。

集中式和动态注册，其实各有优劣， 组件本身不涉及路由配置，你就可以让这个组件参与到多个路由节点， 最好的办法是用户自主选择， 比如我之前的stateman 其实就同时支持动态注册和集中式管理，

还有一个昨天你有个点， 貌似不在文章里

就是组件本身不适合过度封装？ 还给了小马的尾巴的例子。

其实我很赞同了， 因为组件和模块不同的地方是， 组件的模板（或view）是有结构的， 而模块暴露的接口是可以适度重复的（你给的例子其实更适合用来说明模块，有重复但是仍然可用），但是组件不一样，结构只要有细微的不满足， 那整套模板就是不可用的。

所以我们可以安全封装可以冗余的业务逻辑（或vm上的方法）继承下来，因为不涉及到view, 更接近模块的定义， 比如我们内部的ListView其实也是没有template结构的， 而只有业务逻辑封装， 因为模板的变化太大了。

关于模板的封装， 我想到的有两种方式
一种方式是 include, 这个也是你提前定义好哪些可能会被替换， 比如一个modal弹窗的内容区， 显然应该留好这个placeholder
第二种方式可以直接微调模板， 这个有完整parse流程的regularjs就有优势了， 我可以提供hook给用户，直接操作结构化后的AST. Angularjs这种就很难做

结尾

写的有些凌乱， 也算一个记录。

未完待续...

from blog.

很多很好的思考啊，学习了。
关于Office Object Model这部分想法很形象，确实可以和Web类比，不过感觉应该类比的是DOM而不是MV*框架的Model层吧，毕竟除了Backbone其它主流框架的Model其实都没有很heavy。

另外最近很关注React带来的一些新**，然后看了你前几篇关于Angular的讨论，也理解了你对于组件化的意见，就像你在这篇文章最后suggest的那样，组件化的问题就在于复用带来的效率提升和组件构建成本之间的tradeoff，实际上是一个很难的决定。结合之前你在 MVVM时代的Web控件 ——基于AngularJS实现 里面提到的复用Display Logic和相关的一些实践，我想大概梳理一下我的想法。

感觉上对于UI（特指View）来讲，复用性已经不太是关注点了，因为不管是Layout还是Display Logic的复用性都不大，像Accordion算是一个，但实际上因为这个logic太基本，是不是值得复用也不好说（相较牺牲这种复用性而compose大一些的组件），而对于稍复杂一点的UI来说，复杂的state mutation和layout如果works as expectation还好，一旦出问题就比较抓狂，所以想来想去，还是可维护性最重要，不如把相关model和logic都放在一起方便debugging和testing。由此带来的潜在福利应该是很可观的。尽管好多人说MVVM这种对小型项目来说开发效率更高，但是我觉得其实就是遵循了传统后端的web架构**，大家已经熟悉并且接受，写起来没有**负担而已，真要说MVVM模式是否合适，我觉得还是要抱开放一点的心态，跳出套路进行比较。

比如PeteHunt在13JSConf上讲的就是Separation of technologies != Separation of concerns，最早说要把HTML/CSS和JS分离，最重要的是Design和Logic分离，这在web1.0时代是非常有效的，因为当时的static web还主要只是Layout和Style，不需要任何逻辑来支持动态效果。而Templating也是在这个大背景下，从后端渲染的MVC模式直接借鉴到前端的。不过在JS已经是前端主要语言，前端UI所需要的Display Logic的代码量非常庞大的现在，我们的UI已经无法避免要绑定几套不同的显示状态，还要带上underlying的logic handler，而这种时候还要试图分离HTML/CSS和JS就会很难受，MVVM里的VM做了大量后台的工作简化了data和display logic和view的binding，已经做到了declarative HTML as View，但是如果离开JS单看这个HTML template其实就有点无所适从，因为directives的behavior并无标准可循，要track back到JS那边才能完全理解。所以在Against CSS in JS里面KG会说

the mantra of React is to stop pretending the DOM and the JavaScript that controls it are separate concerns

这么想的话，React选择的激进的组件化风格就还是很有其现实意义的。而反思templating的**包袱的话，就是一定要强调HTML和JS分离，相反的结合JSX的话Design完全有能力对组件进行修改，这里就需要我们有一个open mind，接受Engineer和Designer可以是在相同环境中工作的可能性，这个时代，连我们的Designer都会一些JS了，与其让他在一个复杂的cascaded逻辑链或者CSS套用中去做改变，还不如让他在JSX中安心修改单个组件而不用担心side effect要好吧。不过这确实和公司的实力有关系，我认为FB有能力做更好的training给designer所以才能完全把React**执行下去吧。

React最重要的两个**就是VirtualDOM和JSX（embed markup/CSS in JS)，Virtual DOM各大框架都可以adopt，而且个人觉得是React更重要更有价值的部分，但是第二点就和现在流行的MV_框架走的是不同的路，也许是时候考虑一下这种完全革新的架构了，React的设计者们从一开始就只关注UI，把UI作为driving force，才能够跳出一般的思路而把VIew单独拿出来进行思考，所以才能找到一种让开发更有效率的框架实现，而另一边，籍着这种disruptive的思路，Flux也可以跳出MV_的two-way binding的老路，提出一种完全不一样的pattern，让人耳目一新。个人认为也许Flux+React这种看似颠覆式的实现是next gen web的一个信号也说不定。

from blog.

这篇是为Segmentfault 3周年活动前端场准备的，有些仓促，因为最近太忙了……demo稍后整理

from blog.

nice shot!

最近在做一个内部的叫筋斗云的项目,第一次真正在项目中用angular. 于jq相比,第一次使用angular更多的是一种思维的转变,思维转变了接下来就易懂的多...

from blog.

good job ! 👍

from blog.

👍

from blog.

thanks

from blog.

有思考就有收获

from blog.

👍

from blog.

thx！学习

from blog.

最近都在搞scrat, 没关注ng, 看起来ng2的语法似乎稳定了，下个月抽时间可以考虑看看ng2

from blog.

期待 Angular 2 和 TypeScript 方面的进展.

关于 React 的对比, 最近注意到一个点, 就是当我们后端工程师跟我讨论组件的时候,
他熟悉 Rails 和 Node 方面的做法, 对组件的理解应该说是更接近面向对象,
比如说一个 field 内容封装组件, 就暴露方法获取和改变 field 具体数据..
跟他讨论过程中我意识到 React 完全不同, 不赞成从外界获取和操作组件内部数据了
而是传给组件属性, 传给组件修改属性的方法.. 这个思路跟以往的大不相同
我对 Angular 当中做法不够明确. 不过这个套路和 jQuery 时代已经完全不一样了

from blog.

@jiyinyiyong angular也不赞成从外部对组件进行操作，但web components这个东西的理念是跟他的理解很接近的。所以，不管react还是angular，都会在web components上面再来一次抽象，隔离开发者对它的直接操作。

polymer应该更适合你同事的理解

from blog.

@leeluolee 有几段文字和插图没补上，刚加上了

from blog.

飞哥，赞！

from blog.

from blog.

这图片很费心思啊 😅

from blog.

学习学习~

from blog.

TypeScript 用起来有java的语法特点，但是貌似多态搞不了，还有很多待了解

from blog.

对于大型Web应用来说，组件化是必须的，但是如何实现组件化，每个人都有自己的看法，所以组件化这个词就像**，法制一样，容易谈，难做。

实际在用组件，尤其UI组件的时候，会出现很多尴尬的地方，比如说同一个组件在不同场景下形态不一致，所以我们需要多个层次的组件复用级别。

在Angular 1.x中，组件化并不是一个很明确的概念，它的整体思路还是：逻辑层+模板层这样的概念，此外，有一些指令（directive），用于表达对HTML标签、属性的增强。

组件化

实际开发中， 合理规划组件的粒度十分困难。 必须承认， 我们团队开发的组件整体质量还不高， 大家都在摸索中 。

但由于分工css 与 js 岗位职责的分离 ，这些质量参差不齐的组件，在缺少文档， 测试， 一致的命名规范的情况下， 为CSS 样式的工程化管理带来很大的挑战。 与此同时， 在团队合作中， 还有产品经理、 UI 后端等各个岗位的配合上也存在问题。

可以说， web component 还不成熟。 无论是技术上 还是 人才上。

在新旧交替之际， 怎么让前端开发拥抱新技术。 同时保证让团队各个环节合作顺畅， 项目稳步前进。 是我们值得思考的， 以下是我在angular1.x 中得实践经验：

1. 减少组件的状态，子组件嵌套的深度不超过2层。
2. 减少路由的状态， 不要过度使用ui-router, 尽量使用单路由， 嵌套深度不超过2层。
3. 将controller与路由写在一起， 因为路由的所依赖的数据和实际业务无法分离（在controller中加载数据会导致页面闪烁，同时route 成功 hook 不正确。 同时导致应用有状态， 导致用户无法F5等等）。 综合权衡只有舍弃路由的全局配置管理， 将路由和业务层代码放在一起。（和angular2不谋而合）
4. 为了规避1、2 损失的灵活性。 partial采用模板引擎管理（jade）， 使用 extend include conditionals 等模板语言特性。 在构建期间生成真正angular使用的模板 。 这样提高性能， 增加复用性， 使用原生标签布局，减少学习、沟通成本。 进一步隔离样式 与 组件的， CSS 与 JS组件， 设计人员 与 系统业务
5. directive， 使用动态 directive ； directive 中使用lodash template 模板预编译； 合理使用 compile 配置，在angular程序运行的不同周期， 动态改变模板。 减少不必要的双向绑定， 优化性能， 增加灵活性、复用性， 降低学习成本。

关于angular2

angular2 彻底摒弃了 angular1 中过于复杂概念， 拥抱标准。 更容易的总结出一套一致的最佳实践

同时使用typescript ， 类型定义更清晰， 对IDE 更友好， 写代码应该更容易， 更健壮

期待。

from blog.

去年尝试过 TypeScript，随着项目变大编译时间越来越慢，有时候甚至要等 2 分钟，加上编译检查过于严格，好多代码都不知道怎么写了，所以真正用起来的体验是超级不爽。。。

from blog.

现在的前端流行的做法都需要编译，但是编译会随着代码量增加而越来越慢。项目大之后如何分模块开发又是一个问题了。
目前正在开发一个超大型单页应用，重度交互应用。遵循commonJS规范开发，使用babel编译ES6语法，webpack按需加载js进行分包。现在的初次编译已达到2.5min，随着项目的变大，编译的问题也急需解决。不知道大家有什么好的方法。

from blog.

@nwind 项目变大这个问题不是很大，因为如果用它写全项目，我建议的方式是先规划后编码，引用的时候，把已确定的东西都先搞成类型文件，那部分的东西单独构建，这样，当某个人写自己模块的时候，依赖的东西基本都不需要编译，所以不至于特别慢。

至于说编译检查过于严格这事，确实带来不少学习成本，但我觉得如果纯逻辑代码的话，还好啊，在ng2或者aurelia的场景里，只用来写model和view model，应该不会这么可怕。

from blog.

@luqin 编译时间应该也可以算ts比es6的优势之一，因为可以引入预先定义的d文件，所以被依赖的东西不必每次都编译，每个业务开发者其实只是在编译自己的部分。

from blog.

学习！！

from blog.

@yyx990803 不熟悉的东西我实在不敢说。。。

from blog.

@xufei 我是一个Angular新手，看了这篇文章感觉获益良多。刚刚在看了Angular2的文档后，我有一些疑问：

1. 我看到Angular2提供了Component和View，看上去有点像React利用JSX创建virtual dom然后render到real element的方式（也许只是看上去像...），请问在Angular2中这样得到的组件是存在于内存中还是会成为页面上的一个real dom呢？
2. 如果是内存中virtual dom，那么可以理解更新视图有性能提高，如果是渲染成一个real dom，那么Angular2是怎么优化dirty-check之后更新视图的操作呢？

我的见解可能比较浅薄，但是仍然希望您能给我解答一下

from blog.

11年开始使用angularjs，刚开始被它的双向绑定、路由、指令等功能吸引，后来随着项目越来越庞大，性能方面存在一定的问题，想尽各种方式进行优化，却不得其果。
angular2和react在性能方面的确有很大优势，目前正在考虑迁移过来

from blog.

angularjs 对百度的seo，一般用什么思路来实现呢？

from blog.

@joeylin 尝试一下Prerender，预渲染页面让搜索引擎来爬取和收录

from blog.

希望来一期React，:)

from blog.

之前一直用Angular，现在突然宣布2.0不向后兼容，Angular应该掉了很多粉。
现在个人比较倾向React这种职责单一的玩意儿，以后就算React新版本也不向后兼容，升级甚至替换的代价也要小很多。

from blog.

angular使用中，我遇到一个问题，我$watch('width')中修改height，$watch('height')中修改width, 最终产生一个错误， 大家遇到这种需求的时候，一般是怎么解决的呢？

from blog.

@joeylin 只要是在几步操作之内能收敛就行了，不能一直变下去。

比如说，你在width里面写：height = width * 2;
在height里面写：width = height / 2;

这样，无论是对哪个赋值，都能很快收敛回来，两个式子的结果都不再变化，尽管效率未必高，但结果是可以了。

你什么需求会这么写啊，详细说说，感觉逻辑没有理清楚……

from blog.

@xufei 我想让一个div的宽高，强制按比例缩放，比如增大width，height也同时增大，增大height，width也能同时按相应的比例增大。

from blog.

@xufei 对，这样的值，正常是可以的，我担心的是，在计算的时候值出现一些微小得差异，最终造成，无法收敛。

from blog.

@joeylin Math.round? 1px内的误差应该可以接受。

from blog.

赞，写的真好

from blog.

学习了

from blog.

写的真好，赞！ 👍

from blog.

版本已经迭代到rc4，那么现在新项目是时候选择angular2了？

from blog.

赞，很棒的。

from blog.

from blog.

from blog.