推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
这是一个创建于 4081 天前的主题，其中的信息可能已经有所发展或是发生改变。
https://github.com/RubyLouvre/avalon 国产的,感觉完全不想国际化/有兼容到 ie6和只兼容到 ie10 的两个版本可选/小巧
http://vdisk.weibo.com/s/aMO9PyIQCnLOF/1375154475 MVVM框架介绍,内有 knockout ember angular 等的介绍和比较
http://www.cnblogs.com/rubylouvre/p/3181291.html 入门教程,里面最开始把其他的 MVVM 的缺点说了一堆,说得我现在不想用 angular 了
http://vdisk.weibo.com/s/aMO9PyIQCnLOF/1375154475 MVVM框架介绍,内有 knockout ember angular 等的介绍和比较
http://www.cnblogs.com/rubylouvre/p/3181291.html 入门教程,里面最开始把其他的 MVVM 的缺点说了一堆,说得我现在不想用 angular 了
第 1 条附言 · 2013-12-06 22:42:09 +08:00
经过自己的实际使用和内部推广,一句话:用过的人都说好!
 |
1
yakczh 2013-09-25 09:57:32 +08:00
还有其他兼容ie6的框架吗,掰着指头数一下
|
 |
2
chrisyipw 2013-09-25 10:56:56 +08:00  7
Client-side 的 MVVM 建议还是用社区成熟的，除非你有能力也愿意去贡献。
针对第三个链接的回复： 首先，看到「司徒正美」就呵呵了…… 他说的 AngularJS 问题我只认同一点：「空间换时间」，AngularJS 团队也是建议「在 DOM nodes 小于 2000 的项目上用」，以达到最佳的开发效率和性能的平衡。 而其他，并没有他说得那么严重，一个 injection 也就是这样： angnular.controll('MainCtrl', [ '$scope', '$q', '$timeout', '$window', function ( $scope, $q, $timeout, $window ) {} ]) 上述代码这是抗压缩的。 AngularJS 为了达成 <input ng-model='username'> <h1 ng-bind='user'></h1> 的自动更新和 $scope.$watch('username', function (username) { if (!username) { $scope.username = 'Tell me your name' } }) 的数据监控，自然不可避免地阻止「实时」 DOM 更新，否则性能会有隐患。 这一切，都是一种选择的问题。 AngularJS 的上手是很快的，完全感觉不到司徒正美说的「上手难度非常高」（好吧，为了 single-page app 确实耗费了不少时间在 nested views 上，直到我遇到 ui-router，这也侧面证明了 AngularJS 的社区力量）—— @sofish 和我看了一下文档就知道怎么写，他当天问我一些问题之后，几天内就发布了 AngularJS 版的 staticfile.org。难吗？用 AngularJS 甚至可以不改原有架构（见 http://joome.net/lab/partners 源码，不是一个好例子，这场景该用 doT）。 最后，对司徒正美的个人看法：我也订阅过他的博客很长时间，很清楚他的技术积淀有多深厚，同时也察觉到他对性能的异样追求，所以在他 AvalonJS 入门文章出来之后，果断取消了订阅。 正如七牛云储存许式伟说的「大部分 C++ 程序员热衷于性能偏执，甚至是异常的偏执」（ http://open.qiniudn.com/golang-and-cloud-storage.pdf ），我也在司徒正美身上看到了这个偏执。 我们这个时代其实是不错的时代，因为： - I/O 瓶颈？上 SSD。 - CPU 瓶颈？上集群。 - Client-side 速度慢？V8 引发了引擎竞赛的大潮，Blink 也很有可能引发 DOM 性能竞赛的潮流。 过度关注性能，有意义吗？我知道这没有正确答案，但从 Rails 和 AngularJS 的火，多少可以窥见大众和市场的选择。（此外 AngularJS 对技术的选择相当前卫，可以让你保持 updated，有兴趣可以粗略了解一下 http://blog.chrisyip.im/posts/2013/09/11/great-posts-about-angularjs-and-emberjs ） 但「我们」这个时代也是一个糟糕的时代，IE 6、7 的份额降不到 0，欲哭无泪。 |
 |
3
xlhuang 2013-09-25 11:38:30 +08:00
其实我也非常关注性能……
|
 |
4
clino OP @yakczh 使用者也可以选择不兼容ie6的版本嘛.我想能兼容ie6也说明这个框架比较小巧才比较容易能做到
@chrisyipw 没看懂你说的抗压缩和他说的有没有矛盾,不过我看angularjs官方文档翻译版里有提到:"由于AngularJS是通过控制器构造函数的参数名字来推断依赖服务名称的。所以如果你要压缩)PhoneListCtrl控制器的JS代码，它所有的参数也同时会被压缩，这时候依赖注入系统就不能正确的识别出服务了。" 你举的栗子是规避的方法吗? "「上手难度非常高」" 这话我也觉得可能会比较夸张,不过你没怎么碰到问题会不会是因为还没怎么碰到 angular 比较坑的地方? "由于基于编译，许多行为都不是即时的，可预见的。"这个说法应该是靠谱的吧? "过度关注性能，有意义吗？" 这句话我觉得你本身就给出了答案,因为已经有一个"过度",但问题到底是不是"过度",我觉得如果提供的功能差不多,性能明显有问题和性能较好的两个肯定选性能较好的了,当然要考虑其他方面,不过性能也是一个重要的指标 |
 |
5
FrankFang128 2013-09-25 12:55:50 +08:00
谈客户端JS的性能？算了吧。绝大部分网站没必要谈这个。
|
|
6
FrankFang128 2013-09-25 13:01:17 +08:00
选择开源框架，还是选择一个社区成熟的比较好。
|
|
7
chrisyipw 2013-09-25 14:50:24 +08:00 2
@clino 我举的例子就是官方的方案，官方文档和翻译都比较坑，没有很明确地说明其实可以和压缩器友好相处，详情可以看 $inject 的文档。
司徒说的其实这样：angular.controller('MainCtrl', function($scope){}) -> angular.controller('MainCtrl', function(a){})，因为 AngularJS 的黑技术原因，需要 $scope 保持 $scope 这个名字，理解成字符串匹配好了，匹配不了，就认为这有错。 angular.controller('MainCtrl', ['$scope', function($scope){}]) 就像 source map，明确告诉 AngularJS，函数参数的第一个变量，就叫 $scope，这样 AngularJS 就知道找什么对象。另一个用法： function MainCtrl ($scope) {} MainCtrl.$inject = ['$scope'] 一样的效果。我手头的 AngularJS 全部都是经过 uglify.js 压缩的，用的是 CoffeeScript，都正常运行。 上手难度的问题嘛，别说我没碰到问题，比如 $httpProvider 自定义 headers 的坑……只不过大部分都可以通过 StackOverflow、文档解决，所以谈不上坑，这也就是我说的社区力量。 关于性能的问题，你的话也有问题，「性能明显有问题 vs 性能较好」，本身就有答案。事实上 AngularJS 真不是有问题（ http://jsperf.com/angularjs-vs-backbone http://jsfiddle.net/jashkenas/CGSd5/ ）。 $parse getter 的效率 http://jsperf.com/angularjs-parse-getter/4 但 AngularJS 不适合重型 app 是事实，看这个 http://jsperf.com/angularjs-digest/2 ：利用 $new 建立了 100 个 $scope，每个 $scope 还要设立 100 个 $watch，在 Chrome v30 里只有可怜巴巴的 2000 ops/sec（AngularJS 版本是 1.0.1/1.0.2）。 拿 10s 和 1s 比，傻子也知道该选 1s，但 10ms 和 100ms，就没所谓了。这就是为什么 http://builtwith.angularjs.org/ 里的项目有 10 页之多。 我认为司徒对性能过度偏执，就是这个原因。比如 forEach 等方法和 for loop 的选择，司徒会毫不犹豫选择 for loop 吧，毕竟在 Chrome v29 里 forEach 跑 7000 ops/sec 的时候，for loop 是 20000 ops/sec 的（ http://jsperf.com/for-vs-foreach/100 ），但是一秒跑 7000 ops/sec 对我来说足够满足大部分场景，所以我喜欢： if ( arr.some(function(item){ return item == whatever } ) { /* do something */ } or arr.some(function(item){ if (item == whatever) { /* do something */; return true; }) 而不是： for (var i = arr.length; i--;) { if (arr[i] == whatever) { /* do something */ } } 我对性能的看法是，针对场景选择最适合的，比如说，不管是什么 MVVM 都不可能比得上 elem.innerHTML 的效率，算上下载的体积，生成模板必定比不上 doT 等模板库（不算额外库，doT.js 3,324 bytes, AngularJS 1.2.0rc2 91,028 bytes，Ember.js 235,368 bytes，屌爆了有没有）。 |
 |
9
est 2013-09-25 15:44:19 +08:00
其实我用angularjs就一个原因：你们其他社区能有那么多widgets直接套着用嘛？谁谁给我个emberjs的select2看看？支持icon和多选神马的。
|
 |
11
lisposter 2013-09-25 16:17:42 +08:00
轮子太多了。。随手选一个大家在用的就好
|
|
12
est 2013-09-25 16:23:35 +08:00
@kangjia 看了下
/jipiao 这个页面 document.getElementsByTagName("*").length 2284 搜索航班结果页面 document.getElementsByTagName("*").length 1138 |
|
14
chrisyipw 2013-09-27 16:24:41 +08:00
补充：为什么 AngularJS 选择 dirty-checking 而不是 change listneners http://stackoverflow.com/questions/9682092/databinding-in-angularjs/9693933#9693933
|
|
16
clino OP @chrisyipw @est 刚看了司徒正美翻译的一篇“ 为什么移动Web应用程序很慢” http://www.cnblogs.com/rubylouvre/p/3213632.html 觉得在某些情况下性能还是挺重要的，特别是在移动终端上
|
|
18
chrisyipw 2013-09-28 22:55:17 +08:00
|
|
19
chrisyipw 2013-09-28 22:55:48 +08:00
typo #18: chache -> cache
|
|
20
chrisyipw 2013-09-28 22:59:42 +08:00
|
 |
21
turing 2013-09-29 00:51:13 +08:00 1
性能问题真是个月经贴。
无论是服务器性能，还是客户端性能。我个人的想法是，对于web，如果你不是在腾讯的QQ空间或者tmall，淘宝这样随便一个页面都PV上亿级别的公司工作，别太偏执。使用者优先，维护者其次，自己的偏执最不重要。性能问题是有量之后的问题，有量之前都不是问题。所以有量之前你用什么框架，用什么语言那完全看你自己爱好和社区活跃程度（方便），没什么好讨论的。 对于mobile，有两种分歧很大的看法，一种人认为js在mobile上的性能会不断提升，webapp是有发挥空间的，另一种人认为js engine的提示性能非常有限，再过个几十年估计都赶不上native，大一统的web开发时代是没那么快到来的。 我个人其实比较倾向于前者，但js engine的性能问题确实无法在一个短期时间内在mobile上有什么重大的提升，不过未来的事情我们是不好说的，但有一些点确实是可以意识到，一个是h5规范在慢慢淡化光环，新api实现的速度在提高，数量也在增加，也有标准分化趋势（也不见得是个坏事），web开发在逐渐渗透到各种瘦客户端当中（比如ff家的mobile OS，硬件社区的tessel单片机），这种影响有的时候是潜移默化的，不是那么一刀切的。 总的来说，坚持一个原则，不要「过早优化」，做有趣的，有用的好产品才是王道。 |
|
22
clino OP 在 uliweb 下搬了 angular 和 avalon 的一些例子:
https://github.com/zhangchunlin/angular-uliweb-examples https://github.com/zhangchunlin/avalon-uliweb-examples 感觉 avalon 学起来确实比较简单 |
|
23
FrankFang128 2013-12-06 22:56:32 +08:00
「用过的人都说好」不能算推荐理由。
「用过 Angular 也用过 Avalon 后都说 Avalon 好」才行 ;) |
|
24
clino OP @FrankFang128 我是更新一下实际用过一段时间以后的体会,给大家一些参考而已
angular是我首先去学的,和 avalon 对比起来,确实 avalon 更易学易用,angular 相比用起来概念更多更难理解一些 avalon 碰到的一个兼容性问题是不兼容firefox低版本,貌似只兼容14.0以上 |
 |
25
duanxian0605 2015-03-28 17:25:52 +08:00
@chrisyipw 性能还是要的，而且还要追求极致的。我现在手上在做一个管理系统，有一个产品类目组件。
光是类目就有1.7万条。而且生成组件的时候还要绑定各种事件以及生成映射map。如果代码写得太任性的话，拼字符串就让浏览器疯了。 所以我觉得任何时候追求极致都是好的，是很好的，极致才能促进这个行业发展嘛~~ 我前几天项目中也引入了avalon，因为是管理系统，所以view和model之交的交互太多，引入avalon之后明显爽多了~~ 我也看过司徒大部份的博客，我觉得前端就是要这类的人来促进，毕竟前端太年轻，太多半吊子（包括我）。所以我有点不明白你说：”看到 [司徒正美] 我就呵呵了“的意思。 angular我没有用过，看过api，没看过源码，所以不评价。大家都有自己习惯的框架，没必要因为自己用这一个习惯了，就去否定其他的吧。 |
Select Language