@learnshare #24 刚测了一下，iOS 版 UC 使用 UIWebView，是 scroll 阻塞 dom 的实现，position:fixed 不会飘走。

@learnshare #14 可不可以用 css 实现。

前端界好像有个倾向，用 js 代替一切。内容用 js 生成，排版用 js 控制，这个有点跑偏。

@linking #13 我觉得把讨论的议题换成，在浏览器中，给 UI 线程高优先级，并允许其钳制 JS 线程的资源使用，那么投赞成票的应该会多一点。UIWebView 的处理方法显现了一点雏形。

感谢您提供 WKWebView 取消类似机制的信息。不知道取消后，有没有相关的机制优化体验，还是全凭 Web 开发者的自觉。

可能我更多的从用户的角度写代码，当我看到那些优化的很差的页面，也没有办法从系统层面给他去抖时，心情是很沮丧的，我希望浏览器给我选择的余地。

@leeg810312 #8
@miniwade514 #9

Apple 上一次为了一点点用户体验，做了一个取舍，一刀切了 Flash。是不是进步不知道，android 很快学去了。

@ileenhow #7 我又查了一下，就是常说的去抖 debounce。记录事件的时间戳，和上一次的比较，低于阈值(还在滚动中)延迟回调，高于阈值(滚动完毕)执行回调。

@coolzjy #4 不懂您的意思，touch 卡就卡一点，scroll 卡会卡一串，谁是大头

@yyfearth #1 感谢您提供 passive 的参考。我大概看了一下，说的不是同一个事情。

passive 的背景是：对于一个 cancelable: true 的 UI Event，因为可能存在 preventDefault，所以浏览器会等待回调执行完毕，确定是否存在 preventDefault，再决定是否触发 UI Rendering。

passive 允许开发者提前声明是否 preventDefault，来压缩 touchstart 到 UI Rendering 的等待时间。

但是 scroll 是 cancelable: false 的 UI Event，不能从 passive 得到任何好处。

iOS 的阻塞机制，是 UI Rendering 之后的流程，指的是一个页面一旦开始 scrolling，UI 和 Event Stream 被冻结，scrollend 后解冻，这是彻底解决 UI 卡顿的机制。

@zjsxwc 您的脚本思路反了，应该用字符串生成时间对象，并和当前时间对象比较。而不是把当前时间字符串化，去比较两个字符串。

format 方法和后写的构造函数是多余的，应该完全去除，这是经典的锤子钉子困境。

去广告本质是前端逆向工程
不要依赖选择器，那是表象
去读他加广告的代码

「 Date.prototype.format = ... 」

扩展原型真的好么，还是油猴自己有沙盒？

和楼主探讨一下

「结论：在 addEventListener()和 removeEventListener() 所有参数（ event，Handler，useCapture ）全部一致的情况，且第二个参数非匿名函数的情况下，可以认为是同一个事件处理程序。其他情况，都不能认为是同一个事件处理程序」

我觉得，判断为同一事件处理程序的关键，并不是 Handler 是具名函数，而是要求两次的 Handler 指向同一个对象。只要是同一个函数对象，不管是什么形式，都认定为同一事件处理程序。

所谓同一个对象，包括但不限于
1. 一个全局函数对象
2. 一个局部具名函数对象，在第一次被指定为 Handler 后，一直没有销毁，直到第二次被作为 Handler
3. 一个匿名函数，以某种方式把其指针保留下来，并被第二次作为 Handler

无论是多次监听认定为同一个 Handler 而只触发一次，还是监听后能否正确移除监听，判断标准都是这样。

2.4G 鼠标，可以在 UEFI 里用，可以在双系统里用，按钮点一下(罗技快切)可以在另一台电脑上用，蓝牙这些都不行。

希望大家都不压缩代码，与人方便自己方便

我觉得

框架
是给懂的人
节省开发时间的

不是
给不懂的人
节省学习时间的

不懂的人
用框架
写的代码
也是一团糟

无意冒犯
有啥说啥

@Tuisku 亮点在函数名，缺点在不是事件驱动的

别听他们的，就这么比
t1 - t2 == 0
// true

var t1 = new Date('2017-01-01 23:24');
var t2 = new Date('2017-01-01 23:23');
t1 - t2 > 0
// true