fetch 毕竟还不是正式标准，如果要用还是建议用一个库

1. 实体版可以卖二手，可以借给其他机器玩，电子版随时可以在不同机器上使用（登陆自己账号）
2. PSN 港服支持银联卡
3. 可行，很稳

正美花了很多的心血在上面，有看过它的源码，很多地方能看出认真打磨的痕迹，只是，生不逢时
前端开发也许也进入了快餐节奏，大公司背景，作者的名气，如何推广自己
当然，从另一个角度来讲，现在的 mvvm 都是想让开发者用更简单的方法来完成更复杂的任务的，每个 mvvm 框架都有自己主打的场景
不如看看 avalon 的源码，也许可以学到很多东西、

因为现在 ecma rest operator 不支持 object
object 的 rest operator 是 stage 3 的规范
https://github.com/sebmarkbage/ecmascript-rest-spread

@nanlong
坑肯定还是有的。
定义 schema 麻烦，官方库的标准定义方法，结构复杂以及数量上来了确实是写吐，我们使用工具来通过简单的定义方法生成最终的 schema 。
js 自身数据类型太弱，比如 long 类型的数据或者 unix timestamp 处理起来就烦。
对 SOA 服务的调用参数和返回值都最好进行约束，不然就是凭空增加工作量，尤其我们 Java 和 Python 的服务同时在使用， Python 还是走的 thrift 协议。
前端使用时编写查询语句显然是比以前增加了工作量。
还有 node server 去调用其他服务时的各种问题。

方便快捷自然是要有的。
参考 github 现在开始提供 graphql 版本的 API ，使用非常灵活，前端自行获取需要的数据结构，后端也不需要关心 web api 层面的机构。
独立的 type 可以自由选择需要的 fields ，不同的 type 也可以自由组合。
另外像是 enum 和 input 也很大程度上提升了服务的健壮性。
同时由于类型系统和自省机制，配合各种工具，可以快速的查看整个 schema 定义。

关于是否解决痛点。
最大的体验就是原来占用大量开发工时的 web api 接口开发，很大一部分都可以被替代掉了，只要不是新的业务模型，很多都可以通过调整查询语句结构来完成，非常高效和方便。
接口的不确定性（不能知道接口的参数和返回值）的问题也得到了很大的缓解，最起码前端到 graphql 的通信是稳固的。
异常处理也很好用。

N9AGJRM76R13U4DK2K7VPSM

已用，感谢

你自己看进程啊，又不是说一定要启动了 QQ ，才会启动这个进程，我记得名字叫 msgBox 什么鬼的

这个是 QQ 弹出来的

https://www.google.com/get/noto/help/guidelines/

没错，就是你说的那样子必须列出来使用

Random rd = new Random();
Convert.ToInt32(Math.Floor(65536 * (1 + rd.NextDouble()))).ToString("x").Substring(1);

加上就是了。。。

并不能，可以考虑使用 uglifyjs 移除 dead code

你都说了，这只是你以为的完美而已

GSAP 的动画写得太多了，没有优化

BES 和 BIS 的特点就是全程走黑莓自己的信息通道加密，对外不可见，如楼上所说，有一段时间国内也有运营商提供这两种服务，大概 10-12 年左右还是有少部分运营商（地区）提供的，后来就没下文了。
配合黑莓的邮件服务，推送速度快，又加密，所以早期还是有吸引力的。
但是
现在各大操作系统都有自己的推送服务了，推送速度也没什么优势了。
至于你说的管理员是不是可以看到你的 BES 信息。
当然是可以的，所有通过 BES 服务器的信息管理员都是可见的（跟 BBOS 的版本也有关系，但是最近的机器应该都是有这种能力的）

RC 的时候，每个版本 Breaking changes 一堆，搞得生不如死

$49.99 真的太贵了，打算换了

现在自然没有必要买了，最差也等新款出来 6p 降价再买
体验的话
续航一般般
是用一些 大型应用容易发烫（ 810 背锅，但是有时候莫名其妙的就发烫了）
最后， 摄像头比较差， 虽然我在 V2 遇到很多人说 6p 的摄像头好，还是专业级什么什么的，但是，真的很一般

动不动就要别人把工作成果开源不太好吧
主要是收益问题，可能是发现多看商城的收益不够理想吧，现在 kindle 的型号越来越多，适配其实还是比较繁琐的，后来的系统更新可能也使得开发变得更加复杂

Cool!