ts 不是只有好处没有坏处的。

一个是很多人提到的场景问题，前端开发中会存在着大量的月抛甚至周抛型任务，但这类任务中又有相当一部分需要从头开始开发，本身也不复杂，使用弱类型语言一把出货，又快又好，这种情况下上 ts 反而是徒增心智负担。

第二个，原因，是我个人感受。不知道有没有人和我持类似的想法，但这个可能没法解决。ts 里有一些优秀的特性我觉得应该是进入 js 里面去的，但 js 既然保证了对历史版本的兼容，意味着基本做不到了。ts 永远只能是一个方言的形式存在。
最后跑起来的还是 js，意味着，ts 是一个从开发层面实现了更友好支持的方言，但最终跑起来的运行时优化，是和 ts 本身没多大关系的。
这很像 python 里现在的类型提示，很大程度上可以借助 IDE 或者某些类库实现友好的提示，帮你写出更好的代码，但跑起来后还是一套动态一起上。
而真正的强类型，编译语言，是可以在运行时上做到针对性的优化的。这事，注定是 ts 的短板。

所以 ts 的场景，我们可以大概认为，它应该是主要面向开发这层做优化，更方便协作，能写出更工程化的东西。
但这样的事，我更觉得，应该让原生 js 增加这些 feature 才对。

ts 应该进入 js 。

但回头看看 js 这边的一些新提案，再看看 python 那边花里胡哨的一些提案……唔，感觉官方们都还集中在语言本身的 feature 改动上，而对工程化的支持，似乎都是社区在自行推进周边的支持。

目前看来最舒服的居然是 go …… 不挑刺，我知道 go 的问题和不爽，但总的来说，在工程化，效率，性能，语法上，我觉得当前阶段是一个蛮舒服的结合点的。

。。。。。。

这次真的不是产品经理问题。
是技术人员的问题。

自己写的屎，自己吃下去。

@javalaw2010 对对对，这个问题我也想过。
我甚至联想到了游戏服务器上，多玩家联网操作的逻辑同步。

但引申来了一个新问题。
我不同端操作先后有别，那我为了保证某种程度的最终一致性，后端除了记录数据，是不是还得记录下来自多个客户端的所有操作，类似 binlog 日志那样。
感觉又增加了存储队列上的额外操作。

@littlemcdull 其实这个模式我想过，颇有点类似 MySQL 了。
要实现同步数据，一个是传统的模式，拿最终数据。
二个是像这种模式一样，拿所有的操作行为日志，再完整走一次，就可以追回最终数据了。

但我想了下，这种前后端的场景中，走日志的模式代价远比直接获取最终数据高。

@DGideas 道理都对。

但给普罗大众这样的解释，更像传销了。

最起码传销组织也最爱用这样的东西把人唬的一愣一愣的，哈哈哈哈。

等两个月，我在写。

不用就对了。

vanillajs

小程序的 onPageScroll 我没用过，目测和浏览器环境下用法差不多。

使用 onPageScroll()方法，该函数有一个参数 e，通过 e.scrollTop 可以访问你所滚动的高度。

onPageScroll: function(e) {
console.log(e.scrollTop)
}

你可以计算 e.scrollTop 来决定要不要开始执行动画。
但应该不能在里面用不停的去 setData 的方法来做，会有严重的性能问题。它更应该是一个触发开关，开关打开后去调一次动画。

可以玩游戏了。。。

Pro.

移动多就 iPad Pro.

Just Pro it.

明明很吵，被你这个标题说出了一种萌萌的感觉。。。

这啥分类啊。

一般我们把 QWERT 叫标准，其他的叫非标……

它的书籍的整理机制我也不是很满意。。

我对它的颜色的选择和字体设置偏少持有怨念。

这点上还是不如微信读书、多看阅读等。

不过也正常，对中文的阅读，排版，视觉观感等，应该在这个应用里还没重视到。

我倒是也用，为了可以多设备同步，但确实目前体验还是不够好，算是原生应用里的短板了。

同步是真香。但在中文排版阅读上，也基本找不到比它更差的了。

我一般不关。和大多数人理由一样，有任务要跑，或者为了第二天上班进入状态快。

偶尔有时候行政检查了要求关机。

那我也从来不解释。直接关就是。

说到底，不是自己的东西，不值得投入心力，不值得和人解释。

楼主好可爱。。。

唔。。。