@dimfox
@est

建议少于 2k node 简单的原因是因为 angular 会监控 $scope properties 的变动然后去 render templates，比如更新 {{username}}。

简单的例子，v2ex 某帖子有 2k 的回复，针对每个回复做关键字过滤，不做分页的话，一次跑 2k 势必能感觉得到处理过程，但做成分页，一页十条、二十条，就不会有感觉。

typo #18: chache -> cache

@clino
@est

极度有限的资源还要使用带 **chache** 的框架——脑子有病。

我做移动项目向来不喜欢过多的框架，很多时候都直接上 zepto 了，真心要 tweak 的话，必然是 native JavaScript。

另外，抛开 jQuery、zepto 等问题不说，其实想要在 single page 里承载过多功能都是疯狂的。PhoneGap 就是一直面临着做出来的 app 各方面都达不到 native app 的一半的。浏览器跑 HTML app 就像跑 Java，外头套一层 JVM 还能比得上 native app 才有鬼哩。

补充：为什么 AngularJS 选择 dirty-checking 而不是 change listneners http://stackoverflow.com/questions/9682092/databinding-in-angularjs/9693933#9693933

@NemoAlex 不现实啊亲……三年前我就在先这事了，但 Google 已经宣布终止 Chrome Frame 了（ http://blog.chromium.org/2013/06/retiring-chrome-frame.html ），而且平白无故要下载安装，不是淘宝、网银类的刚性站点，扭头就走了……

@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，屌爆了有没有）。

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，欲哭无泪。

代码什么的必须放 git 里啊，Bitbucket 的 free plan 非常赞，开私有项目往里面 commit 就可以。

我现在主要用 Gist，可以像普通 git repo 一样 clone 下来，写好了直接 push，设为私有的话又不怕被人意外看见。

64 位其实不是为 iPhone 准备的，是为 iPad 准备的。

iPad 有很多外设，也可以承载更多功能，比如编辑音频、视频，靠 iPhone 编辑会让人想死，带 MBA 又不如 iPad 那样便携，更何况 iPad 还能插卡上网。

Near Field Communication (近场通讯） 虽然表面上看起来是个通讯技术，但大家不要被表象迷惑了。带宽仅仅在 kbps 量级的近距离通讯对于现在的日常数据传输没有什么实际意义。所以就不要幻想什么两个手机在没有 3G 和 WiFi 网络的情况下通过 NFC 传输文件这样不靠谱的应用了。数据通讯不是 NFC 的重点，蓝牙才是干这事儿的。

NFC 的主要目标是解决需要亲临现场的身份确认问题。非接触式支付 [移动支付的子集] 是这个问题的特例。从这里延伸出去，有以下两点值得思考：

- 非接触式支付是一个平台技术，而平台技术的推广瓶颈通常不在客户端，而是整个平台的生态链。拿个具体问题想想，可能这句话的含义就好懂了：为什么北京的公交卡不能在上海刷？都是非常类似的的射频卡和读卡器，技术上完全没有任何困难实现一卡通用。这里面牵涉的关联方太多、利益错综复杂，根本不是一项新技术就能解决的。苹果再牛逼也不可能全部搞定盘踞在世界各地的政治、金融地头蛇。仅仅在移动设备里加装个 NFC 收发机离全面实现非接触式支付的梦想差得不止是十万八千里。
- 「亲临现场」是伪命题。NFC 要求通讯距离在一米以内，也就是说如果星巴克采用 NFC 支付的话，你甚至不能在座位上掏出手机点一杯咖啡并完成支付，而不得不去到收银台排队付费。静下来想想，是不是不用离开座位就能完成下单、支付，不用排队，然后坐等服务员送过来比较惬意？NFC 做不到这点，这就极大的限制了 NFC 的想象空间。愈加普及的 3G/4G/WiFi 网络加上灵活自如的 API 才是移动支付的未来；而在方向上，苹果已经有可以说是业界最完善的支付平台了。

source: http://www.zhihu.com/question/20479623?rf=19985343

苹果不是没有 NFC 支付相关的专利（见 http://www.zhihu.com/question/20473697），但因为盈利点还不是很确定的事，集成了反而导致成本不划算，所以没必要推 NFC。

有趣的是，推 NFC 几乎都是 Android 阵营，个人感觉是因为开源和同内核的原因，有一套平台之后，几乎所有 Android 都能用，一堆人做的成本和苹果自己推一个 NFC 支付／应用平台的成本自然要优很多。换句话来说，苹果没找到盈利点之前推 NFC，其实就是帮 Android 继续扩大 NFC 市场——苹果都支持了，咱（店家）也用吧。Android 就普大喜奔了——借助苹果滚大了雪球。

流氓环境下的流氓产物，因为数据都在小米服务器上留着，也就是说，只要有人分享了 Wi-Fi，有心人就可以拿着小米／MIUI 手机不停地试哪家的 Wi-Fi 可连接，连接后监测内网活动，之后能干什么就不必我多说了吧？糟糕的后果有资料失窃，甚至贼人进屋。

想要组织 Wi-Fi 共享又不影响自己使用，最方便的做法是开访客网络，人走了就关掉，下次人来了把访客网络打开即可。毕竟每改一次 Wi-Fi 密码，所有设备都可能要重新输入一遍密码，太烦了。或者直接绑定 Mac 地址。

访客网络只要是 OpenWrt 之类的系统，应该没难度，现在 100 左右新出的路由应该也带有访客网络功能。

AE 卡的话，盖住前面卡号右上角的四位数和背后卡号最后三位即可，有效期盖不盖都没所谓，可能凭触摸就能感觉到大概数字，而且现在很多收据都会打印有效日期。

根据 @kurtis 的话，感觉你是把 Coffee 和 JS 给分离了（看成是不一样的语言）。

其实你说的基本就是 Coffee 的全部了，除此之外，真没啥好说，编译的代码用 JS 也可以写出来，JS 的坑也可以靠经验填上，而且执行效率相差无几，所以就只有语法糖的问题。

Coffee 的语法糖很甜，因为参考的是同样以语法糖很甜出名的 Ruby，相比之下 JS 就太烦人。

我日常写项目是用 Coffee + CodeKit / uglify，编译后会有 source map，调试不成问题，所以，写起来舒服确实让我很爽。

RSS 阅读器因为有阅读场景的问题，所以需要看中的应该是第三方市场，目前来说 Feedly 是比较有前途，第三方市场相对活跃。

@davepkxxx 貌似没什么人提到开发方面的。

我曾经在 Win 下做过 VB.Net 和 C#.Net 的开发，也折腾过 Node.js、Ruby 的环境，现在是完全在 Mac 下开发 JavaScript 有关的。

OS X 和 Win 在开发方面，甚至和 Linux 各种发行版比起来，都是有很大优势。

不坑爹的命令行环境，Win 的 cmd.exe 和 Powershell 就是个笑话（微软自家的产品除外，以下同）。

拿到一台新机器想直接跑 demo？行，内置 Apache、Ruby 2.0.0-p247 (10.9)、Python 2.7.5 (10.9)、PHP 5.4.17 (10.9)，还有 Perl、Git、SVN。

完善的 GUI 程序生态。这是比较粉丝级的 Linux 开发者可能不太在乎的事情，但事实上有和没有是很不一样的，比如查阅文档的 Dash，比如 Alfred Workflows，而编辑器除了 Vim、Emacs 还有 TextMate、Sublime Text 等好用的选择。如果你是一个 Web 相关的开发者，会找到更多实用的 GUI 程序。

Time Machine，忘了 push 而机器突然挂了？拿起另一台 Mac，把 TM 的盘插进去恢复，稍等一会就可以继续无缝工作。

但是 Mac 有一个很坑的地方是，你想要无缝使用一些基础的东西，比如挂载 ext3 的盘，通常的节奏是要么坑爹地折腾，要么掏钱买商业程序。

不过这也是我喜欢 Mac 的另一个特点，有一个程序可以解决你的需求的可能性比别的平台大，只不过通常都是要钱的就是了（笑）。