@YuJianrong 用hybrid的好处不就是更新迭代快。不需要发版么？

@YuJianrong 如果js都是静态打在app里面的话更新js不是需要发版？

你算下http请求过程. 数据出来的网络耗时过程就知道了

如果你的js是外链的：
请求页面->请求js->请求ajax接口->完了
如果你的js是行内的
请求页面->请求ajax接口->完了
请求页面->完了

怎么着也要慢...

除非你页面资源做 manifest 那么除了第一次慢还是
请求页面->请求js->请求ajax接口->完了
之后就是
请求ajax接口->完了

第一种如果不做资源缓存能慢死你。你想象多少串行请求么.

关了chrome就好了。

@polandeme 确实。如果需要的话可以邮件我。然后加QQ说。 邮件你可以点我头像找到。

pushstate是不可少的。不然中间的历史就丢了。用户也没法用url回溯到当前浏览的页面了。

quickling 意思只是不做跳转的方式切换页面。

中间用什么去做切换呢。很多方式可以。用ajax可以。用一个iframe去请求回调parent的方法也可以，jsonp也可以。只要能拿到数据啥都可以。

后端吐的数据还是拼好的html呢。都是可以的这个就看你自己怎么处理了。就看怎么和现有架构结合了。

这种技术选型是很灵活的。没有最好的只有最适合的。

说facebook怎么做的。
目前我看facebook已经基本用react了。就是属于模版在前端，后端吐数据的方式。ajax还是ajax，高级浏览器都支持ajax都已经支持Chunked transfer。就没必要去用iframe中间过程的方式来实现了。

说些有的没的。react在facebook真的用啊。不想某angular是吧。

天猫 iPad 客户端已经有业务使用 React Native 进行开发，同时后续会有更多的业务进入进行尝试和探索

你们动作还是蛮快的么...

500真不贵。你看官方店里一个转 type-c + hdmi + usb的也 500多了 这个功能多多了。

有啥好折腾的...

command c / v 这快捷键 用的非常不爽 可能是手指短吧 -.-

这手指也太短了吧........

@Lucius 中午过去，被包场了..

commits log 其实我感觉并不重要。代码逻辑清晰。注释或者文档详细就可以了。

要不中午去买杯奶茶？

去楼下眼镜店要一块就齐了。闹啥

@polandeme 其实对大型网站来说。多几次请求并没有什么问题。
qq 也是iframe

用firefox

@polandeme 我是已一个大站的角度说的。

1. 首先是实现Quickling的成本。你的javascript对于每个模块的的instance需要销毁重新绑定。可能需要一个管理器。和每个模块需要修改挂在到管理器。那个页面需要加哪个js。哪个css。css和css之间会不会冲突。因为原来再不通的页面。这两个死活不会遇到的。

2. 在Quickling区域外部的dom结构需要一致。包括样式名className。不然你还需要在跳转页面时用javascript去修改来匹配样式差异。

3. 用Quickling那么用户在你的页面上基本就不会刷新页面了。那么很多状态的修改都需要用javascript来保持了。这个会在不经意的时候发生。然后很容易手足无措。

4. 你需要适配你目前的所有页面。