1.The Shared Element Transitions API and Origin Trials
chrome 提供了一个名为Shared Element Transitions API的新提案，它为我们提供了“一种在页面状态之间切换的高级动效”。这个新的 API 旨在使单页应用程序的所有这些过渡动效变得更加容易。现在可以在chrome的Origin Trial版本试用。
2.React Native 0.65
React Native 0.65 版发布，其中包含新版 Hermes、可访问性改进、软件包升级。 Hermes是 Facebook 为 React Native 优化的开源 JavaScript 虚拟机，已升级到 0.8.1 版本。此版本中的一些突出功能包括：
- 一个名为“Hades”的新并发垃圾收集器，可在 64 位设备上将暂停时间缩短多达 30 倍。
- ECMAScript 国际化 API（ECMA-402 或Intl）现在内置在 Android 上的 Hermes 中并默认启用
- iOS 版 Hermes现在支持 Apple M1 Mac 和 Mac Catalyst！
- 内存改进，包括 SMI（小整数）和指针压缩，可将JS 堆缩小 30% 。
- Function.prototype.toString修复了由于功能检测不当而导致的性能下降的问题，并支持源代码注入用例。
3.CSS module scripts: import stylesheets like JavaScript modules
微软和谷歌合作为 Chromium 带来了对 CSS 模块脚本的支持，将从 Microsoft Edge 和 Chrome 93 版开始提供。新的CSS 模块脚本功能可用于加载带有import语句的CSS 样式表，就像JavaScript 模块一样。
import sheet from './styles.css' assert { type: 'css' };
document.adoptedStyleSheets = [sheet];
shadowRoot.adoptedStyleSheets = [sheet];
4.An amazing error message if you put more than 2^24 items in a JS Map object
如果在 JS Map 对象中放置超过 2^24 个项目，则会出现错误消息:"未捕获的范围错误：未定义的值超出范围未定义的选项属性未定义." 这不是错误，只是实现定义的限制。
限制由以下因素决定：
Map 的 FixedArray 后备存储的最大大小为 1GB（独立于整体堆大小限制） 在 64 位系统上，这意味着 1GB / 8B = 2^30 / 2^3 = 2^27， 则每个 FixedArray 的最大元素数为 134M 一个 Map 每个条目需要 3 个元素（键、值、下一个桶链接），并且最大负载因子为 50%，并且其容量必须是 2 的幂。2^ 27 / (3 * 2) 四舍五入到 2 的下一个幂是 2^24。
5.Compat2021: Improving CSS Grid compatibility with GridNG
Microsoft Edge 93中将发布对 CSS Grid 1 模块（“GridNG”）的重写，将大大提高Edge对 CSS 网格属性的兼容支持性，并且提升了Edge对复杂嵌套网格布局的性能问题。
6.HTTP/3: Performance Improvements
HTTP/3 实际上是 HTTP/2-over-QUIC，因此，新版本中没有引入真正的、重大的新功能。
- 1.理论上 QUIC 遭受的丢包（以及相关的行头 (HOL) 阻塞）较少，因为它独立处理每个资源字节流上的丢包。但QUIC 实际上使用与 TCP 非常相似的带宽管理技术。这意味着它不会比 TCP 神奇地更快地下载您的网站资源。然而，QUIC 的灵活性意味着试验新的拥塞控制算法将变得更加容易，这应该会在未来改善 TCP 和 QUIC 的情况。
- 2.QUIC 握手总共只需要一次往返即可完成，这比 TCP + TLS 1.3 少了一次往返，没有额外的大量速度提升。
- 3.QUIC 的连接 ID (CID) 允许它在切换网络时执行连接迁移。我们通过一个客户端从 Wi-Fi 网络迁移到 4G，同时进行大文件下载来说明这一点。在 TCP 上，该下载可能必须中止，而对于 QUIC，它可能会继续。
- 4.在通过减轻队头 (HoL) 阻塞问题，使 QUIC 在具有大量数据包丢失的网络上更快。虽然这在理论上是正确的，但我们将看到在实践中这可能只会为网页加载性能提供很小的好处。
- 5.QUIC 和 HTTP/3 的第五个性能方面是关于它们在网络上实际创建和发送数据包的效率和性能。我们将看到 QUIC 使用 UDP 和重加密可以使它比 TCP 慢一点（但情况正在改善）。
7.React 18 如何支持 Strict Effects
随着 React 18 的发布，StrictMode 增加了对 Strict Effects 的支持。在严格模式下，React 会对新安装的组件调用两次 effect（mount -> unmount -> mount）。与其他严格模式下的行为一样，React 仅在开发环境中执行此操作。这篇文章主要介绍如何将现有的组件修改为支持strict Effects的模式。最有可能因为挂载多次而受到影响，导致需要修改 effect 的情况分为以下两类：
- 在卸载时需要执行清理操作的 effect
- 只执行一次的 effect（挂载时或依赖变化时执行）
8.前端工程化：你所需要知道的最新的babel兼容性实现方案
作者在最新babel7的基础上，给大家带来了最新的babel兼容性方案剖析，让大家对babel的兼容性处理机制有更透彻的了解。 目前，babel处理兼容性问题有两种方案：
- @babel/preset-env + corejs@3实现语法转换 + 在全局和实例上添加api，支持全量加载和按需加载，我们简称polyfill方案；
- @babel/preset-env + @babel/runtime-corejs3 + @babel/plugin-transform-runtime实现语法转换 + 模拟替换api，只支持按需加载，我们简称runtime方案。
两种方案都依赖核心包corejs@3，只不过依赖的模块不同，导致实现方式不同。两种方案各有优缺点：
- polyfill方案很明显的缺点就是会造成全局污染，而且会注入冗余的工具代码；优点是可以根据浏览器对新特性的支持度来选择性的进行兼容性处理；
- runtime方案虽然解决了polyfill方案的那些缺点，但是不能根据浏览器对新特性的支持度来选择性的进行兼容性处理，也就是说只要在代码中识别到的api，并且该api也存在core-js-pure包中，就会自动替换，这样一来就会造成一些不必要的转换，从而增加代码体积。
