来自网络各处的我们正在阅读并有一些想法的内容。有没有我们应该知道的链接？告诉我们！
Stacey Tay 的一篇发人深省且有趣的文章，讲述了 Carousell 团队如何收集指标来定义性能预算，进而为其客户创造了更好的体验。
我们新的 PWA 列表页面加载速度比旧的列表页面快 3 倍。发布此新页面后，与我们历史最高周相比，我们从印度尼西亚获得的有机流量增长了 63%。在 3 周的时间里，我们还看到广告点击率提高了 3 倍，以及在列表页面上发起聊天的匿名用户增加了 46%。
该团队内联了关键 CSS，减少了应用程序加载的资源数量，并实施了延迟加载策略，以及许多其他事项。我认为值得注意的是，他们还以某种方式更改了应用程序的设计，以使性能更佳。我认为很容易陷入认为性能仅仅是开发人员的任务的陷阱，而这样的帖子证明了它比这更具协作性。
Rachel 为我们提供了 CSS 工作组正在讨论的内容
scrollbar-width和scrollbar-color之类的属性。我们现在拥有的最好的方法是专有的 WebKit 内容。intrinsicsize内容配合良好，则处理起来会更容易。:where()是不带特异性的:matches()，而:matches()可能会变成:is()。这是 Aditya Agarwal 关于 React 中渲染 Props 和高阶组件之间区别的一篇很棒的文章。我特别喜欢他用来解释这两者的演示。但总而言之
**高阶组件 (HOC) 接收一个组件并返回一个组件。**因此，假设您有一个名为Username的组件，它只返回用户名称的字符串，并且您希望在某个地方将其大写 - 这是使用 HOC 的绝佳机会，该 HOC 包装该Username组件并更改每个字符。就像Kingsley Silas 在 CSS-Tricks 上撰写的优秀教程一样。
monday.com 是一个集中的平台，团队可以在其中管理其工作的每个细节，从高级路线图规划到日常任务的细节，同时构建透明的文化。它是一个适用于任何规模团队的工具，可以从两个自由职业者一起工作开始，到遍布全球的数千人协作。该工具在非技术团队中非常受欢迎，通常可以替代繁重的 Excel 文件、白板和过长的会议。
最主要的是它不限于科技公司，它被教堂、建筑公司、学校和大学、初创企业、包括 WeWork、三星、探索频道、Wix、NBC、General Assembly、麦当劳、优步、Wix、AOL 和阿迪达斯在内的财富 500 强公司使用。目前，它拥有超过 22,000 个付费团队。
我认为 Facundo Corradini 在这里指责我们的推文是正确的。如果您将文本斜体化是因为它应该以这种方式设置样式（例如，使用斜体显示人物的内心独白，如我们的示例所示），那么那是<i>而不是<em>，因为<em>用于强调 - 就像在说话时，你会用你的声音强调一个词来影响意义。
此外，我总是喜欢关于少数几个 HTML 元素细微差别的长篇幅文章！
非常感谢Wufoo 对 CSS-Tricks 的支持！Wufoo 是一款表单构建器，您可以在其中快速构建任何复杂程度的表单。从简单的联系表单到与 Salesforce 同步并处理网站集成的退出调查的多页逻辑复杂的申请表单，它可以处理许多用例！
Wufoo 还有另一个强大的功能：收款。在我看来，它尤其值得了解，因为它非常实惠。它本质上是电子商务，无需在您的付费 Wufoo 帐户和支付处理费用之上收取任何费用。更不用说您可以将它们集成到您自己的网站中并根据自己的喜好对其进行样式化。
我们一直在大量讨论性能 - 不仅仅是最近，而且全年都在讨论。现在，Harry Roberts 通过识别三种可以测试性能的方式来发表意见。
特别值得注意的是第一种测试类型
团队应执行的第一种测试是主动测试：这非常有意和谨慎，并且是主动尝试识别性能问题。
这采取开发人员在执行工作时评估其每项工作的性能影响的形式。这里的想法是我们发现问题，然后再让它变成问题。毕竟，预防比治疗更便宜。在这个阶段捕获性能问题比在它们上线后发现它们要好得多。
当我与团队合作时，我一直在考虑这种类型的性能，尽管我从未给它命名过。
我想我一直在思考的是，我们如何尽早地将前端工程师引入设计流程？我发现，当前端工程师和设计师一起集思广益解决方案时，最终产品在性能方面要好得多。也许协作制定性能检查表是一个良好的开端？
凭借我们强大的 SDK、超级干净的仪表板、详细的文档和世界一流的支持，HelloSign API 是市场上最灵活和强大的 API 之一。立即开始免费构建。
每当我看到有人在浏览器中非常有效地调试 JavaScript 时，他们都会使用 DevTools 工具来完成此操作。设置断点并跳过它们等等。这与在代码周围散布console.log()（以及朋友）语句形成对比。
Parag Zaveri 写了关于过渡的文章，它显然引起了很多人的共鸣！（在我撰写本文时，Medium 上有 7.5k 个赞。）
我知道我对此有一些顾虑……
但它确实很强大。设置断点（只需单击行号）意味着我不必在我的代码中散布额外的垃圾，也不必选择要记录的内容。本地和全局作用域中的每个变量都可以在该断点处供我查看。我在 Parag 的文章中学到，您可能甚至不需要手动设置断点。例如，您可以让它在每次单击（或其他）事件触发时中断。此外，您可以输入您要专门监视的变量名称，因此您不必四处寻找它们。我将尝试更频繁地使用适当的 DevTools 进行调试，并看看效果如何。
不过，既然我们正在谈论调试……几个月来我一直都在想：为什么 JavaScript 没有日志级别？显然，这是许多其他语言中非常常见的概念。您可以编写日志语句，但只有在配置指示应记录时，它们才会记录。这样，在开发中，您可以获得详细的日志记录，但在生产中仅记录更严重的错误。我之所以提到这一点，是因为在代码中保留有用的日志语句会很好，但如果设置了console.level = "production";或其他内容，则不会实际记录它们。或者，它们可以在构建步骤中被编译掉。
我记得当我第一次开始使用flexbox时，世界对我来说就像灵活的盒子一样。这并不是说我忘记了浮动、内联块或任何其他布局机制的工作原理，我只是发现自己默认使用 flexbox。
现在网格已经出现，我发现自己正在处理可以自由使用它的项目，我发现自己大部分时间默认使用网格。但这并不是说我忘记了 flexbox 的工作原理或认为网格取代了 flexbox - 它只是非常有用。Rachel 表达得非常好
询问您的设计是否应该使用网格或 Flexbox 有点像询问您的设计是否应该使用字体大小或颜色。您可能应该根据需要同时使用两者。而且，如果您使用的是“错误”的，没有人会来追赶你。
是的，它们都可以布局一些盒子，但它们本质上有所不同，并且设计用于不同的用例。包装长度不一的元素是一个很大的区别，但 Rachel 在这篇文章中介绍了许多不同的用例。