先从一个需求说起

之前在做界面组件的时候，有很多地方都用到了边框，我都是顺手就打上了 1px 的宽度。但是 MR 上去以后，组里的大佬问我有没有听说过一个极细边框的技术，我就赶紧去 google 了一下，发现这个概念原来很早就有了。早在 2014 的 WWDC 上面 Ted O’Connor 就讨论过有关 “retina hairlines” 的技术，可以实现比 1px 还细的边框。

在传统的 web 优化中，我们可以采取压缩、拆包、动态加载等方法减少首屏资源大小，也能通过离线包、页面直出等方案加速 html 返回，之前一篇 h5 秒开大全有部分简析。在大部分场景中，这些方案都足够用，也能得到出色的效果。但仍有两种无法尽善尽美的地方：其一是短暂的白屏现象不可避免，其二是对于超大型 web 应用难以做到秒开。结合客户端特性，我们有没有办法，进一步做到极致，打开 web 页面和打开客户端页面无差异的体验呢？

2015 年 HTTP/2 标准发表后，大多数主流浏览器也于当年年底支持该标准。此后，凭借着多路复用、头部压缩、服务器推送等优势，HTTP/2 得到了越来越多开发者的青睐。不知不觉的 HTTP 已经发展到了第三代，鹅厂也紧跟技术潮流，很多项目也在逐渐使用 HTTP/3。本文基于 QQ 兴趣部落接入 HTTP/3 的实践，聊一聊 HTTP/3 的原理以及业务接入的方式。

在最近的开发工作中，遇到了一个聊天场景的应用（Web 和小程序），类似于我们再熟悉不过的 QQ 和微信，一个正常的聊天界面是大致上是长这个样子的：

前言：

webpack5 的令人激动的新特性 Module federation 可能并不会让很多开发者激动，但是对于深受多应用伤害的腾讯文档来说，却是着实让人眼前一亮，这篇文章就带你了解腾讯文档的困境以及 Module federation 可以如何帮助我们走出这个困境。

在推行代码规范的时候，绝大多数情况下都会遭到不小的阻力，一来每个人的代码习惯不一致，要人轻易改变习惯确实也不是一朝一夕的事情，二来一般都会带来额外的开发成本和其它困扰。我们不禁在想，推行代码规范的困难点在哪里，以及如何解决这些痛点，让各个角色更容易接受呢？

归纳起来，推行规范的过程中，最常听到的几点担忧有：

1. 是否带来额外的开发成本
2. 规范的执行力度有强制性吗
3. 已经开发的分支，合入的时候遇到大量冲突谁来解决
4. 存量代码如何解决
5. 被修复的代码，后面一看最后修改人全部都是运行 eslint --fix 的那个人怎么办

测试的意义是什么？

在编程术语中，测试意味着检查我们的代码是否符合某些期望。例如：一个名为 “ transformer” 的函数应在给定某些输入的情况下返回期望的输出。

Web 开发者与 iOS 长达四年的较量，终于在 iOS 13 发布这一刻落下帷幕。

iOS 8.2 和它的键盘难题

2015 年三月，iOS 发布了 8.2 版本。这在当时看来也许只是这个现代的操作系统的一次小更新，但在 Web 开发者眼里，有些微妙的问题产生了。这是一件在 Android 世界里想象不到的麻烦事儿。

在此之前 Web 开发者都非常清楚，在 window 全局对象上的 innerWidth/innerHeight 表示浏览器窗口中可以看到页面的区域的尺寸，而 outerWidth/outerHeight 表示浏览器窗口整体的尺寸。可以看到页面的区域又被称为「视口」（Viewport），在 CSS 的世界里，任何 position: fixed 的元素都会脱离文档流并以视口为基准进行定位，以便在页面滚动时让这些元素相对于窗口固定，例如桌面 Web 设计中常见的头部、侧边栏、「返回顶部」按钮等等。

可是从 iOS 8.2 开始，这些概念开始不那么灵了。

英文原文链接

Dodrio 是一个用 Rust 和 WebAssembly 编写的虚拟 DOM 库。它利用了 Wasm 的线性内存和 Rust 的低层次控制 api ，围绕指针碰撞（bump allocation）的方式来设计虚拟 DOM 渲染机制。初步的基准测试结果表明它比现有的虚拟 DOM 库性能都高。

在线文档是一个数据一致性要求很强的项目，我们经常会提到一个在线文档的技术：“协同冲突处理算法——OT”。这是协同编辑处理的核心。因为它保障了在多客户端同时提交修改的情况下的数据一致性，用通俗一点的方式描述：多人在线编辑，每个人提交的内容不一样，但通过协同冲突算法，最终都能看到一样的内容。