来自网络的我们正在阅读并且有一些想法的东西。 有我们应该知道的链接吗？ 告诉我们！
这是 Eric Higgins 关于重构和技术债务的精彩文章。 他将大型重构项目比作俄罗斯方块
与经营企业类似，俄罗斯方块玩得越久就越难。 方块移动得更快，变得难以跟上。
与经营企业类似，你永远无法赢得俄罗斯方块。 没有真正的终点线。 你只能控制你输的速度。
与经营企业类似，在俄罗斯方块中积累太多空白会导致你失败。
我喜欢这个比较，尽管我的俄罗斯方块技术很一般。 感觉即使是“简单”的开发也会随着项目的技术债务增加而变得更加困难，就像俄罗斯方块的方块速度加快，随着堆叠的增长，留给反应的时间也越来越少。 但是，我认为我可能对技术债务持更加乐观的看法。 如果你 慢慢地、谨慎地 工作，那么你可以建立重构文化，并随着时间的推移积累动力。
在网络上，没有一种真正的方法可以隐藏东西。 也应该没有，因为隐藏太模糊了。 你是视觉上隐藏还是暂时隐藏（比如用户菜单），但内容仍然应该可以访问吗？ 你是故意从辅助技术中隐藏它吗？ 你只向辅助技术展示它吗？ 你是在某些屏幕尺寸或其他情况下隐藏它吗？ 还是你只是简单地一直把它隐藏起来，不给所有人看？
Paul Hebert 详细分析了这些场景。 我们也做过一个关于这个主题的视频。
感觉很多 CSS 属性在隐藏或显示内容方面都发挥着作用：display、position、overflow、opacity、visibility、clip-path…
2015 年有 24,000 种不同的 Android 设备，每台设备都能够下载图片。 而这仅仅是开始。 移动时代正在加速发展，移动访客数量开始超过桌面访客。 有一点是肯定的，在移动时代构建和运行网站需要对图片采取完全不同的方法。 你需要考虑桌面、笔记本电脑、平板电脑、手表、智能手机的用户，以及视窗尺寸、分辨率，最后才是浏览器支持的格式。
那么，有什么好的图片优化选项可以帮助你应对所有这些需求，同时又不牺牲图片质量和页面 SEO 策略呢？
跟 Optimole 打招呼吧。
这是 Ahmad Shadeed 写的一篇很棒的文章。 它深入探讨了网站标题的实际构建过程——我们许多人经常做的那种工作。 乍一看创建标题似乎很简单，但随着屏幕尺寸、边缘情况、交互和 CSS 布局可能性等因素的加入，它开始变得复杂起来。 这甚至还没有考虑跨浏览器问题，这些问题在最近 已经没有那么让人头疼，但始终存在。
有时很难解释定义我们前端开发工作的有趣和棘手的场景，而这篇文章很好地展示了这一点。
Rachel Andrew 表示，CSS 工作组在最近的一次会议上 设计了一个纵横比单位。 这个想法是为了找到一个优雅的解决方案，来应对我们想要根据元素的宽度计算元素的高度，反之亦然的情况。
对所有网站进行大而化之的陈述太常见了。 Jason Miller
我们经常对我们在现实中看到的应用程序进行概括性描述，无论是轶事性的还是统计性的：“单页应用程序比多页应用程序速度慢”或“TTI 低的应用程序加载速度快”。 但是，这些概括性描述对我们所关心性能和架构特征的程度各不相同。
就在前几天早上，在 An Event Apart 的早餐会上，我坐在一个在大学网站上工作，拥有大量页面的人旁边。 坐在同一桌子的还有在一家媒体公司工作的人，他们拥有广泛的品牌，但大多数网站都是博客式内容。 还有一个从事开发工具工作的人，该工具主要依赖仪表盘。 我们都关心可访问性、性能、可维护性等，但适当的技术栈和交付流程在我们的实际工作以及我们可能应该做的事情方面都大不相同。
这不是一篇赞助文章。 我在一段时间前申请了名为 Stackbit 的网站的测试版访问权限，前几天收到了邀请，我认为这是一个非常好的主意，与我们这些网络极客相关——尤其是那些创建大量 JAMstack 网站的人。
我非常喜欢 JAMstack 网站的整个理念。 以我们新的 前端开发会议网站 为例。 该网站是使用 11ty 构建的自定义主题，在 GitHub 上进行版本控制，托管在 Netlify 上，并使用 Netlify CMS 进行内容管理。
每个 JAMstack 网站都是 服务 的一小部分选择（⬅ 我正在重建该网站，使其更加 JAMstack 化！）。 我认为 Stackbit 可以帮助我们快速做出这些选择，这一点很聪明。
Leslie Cohn-Wein 的主要观点
虽然 [大量 div、内联样式、焦点管理问题] 是有效的担忧，但需要注意的是，React 中没有任何东西阻止我们构建可访问的网络应用程序。
没错。 我很有能力（而且不幸的是，我有罪）用 React 或不使用 React 构建不可访问的界面。
我一直告诉人们，提升你的前端设计和开发技能的一种方法，尤其是在你早期的时候，就是 理解如何更改类。 我可以编写几行 JavaScript 代码来添加/删除一个 active 类，并快速构建一个选项卡式界面。 但是，我是否以一种默认情况下可访问的方式构建了 HTML？ 我是否处理了键盘事件？ 我是否处理了所有相关的 aria-* 属性？ 我在这里自己回答：没有。 随着时间的推移，我在这方面有所改进，但不幸的是，我对 正确模式 的肌肉记忆并不总是存在。
我也倾向于倾听那些我信任的可访问性专家 的话，他们说 SPA 的激增（其中 React 是主要参与者）与可访问性问题的激增明显重合。
但我仍然很乐观。 例如，React 拥有 一个经过祝福的选项卡解决方案，它在开箱即用时就是可访问的。 我会使用这些解决方案，因此我现在构建选项卡的肌肉记忆会产生更可访问的产品。 而且当我需要使用 React 进行路由/链接时，我会使用 Reach Router，并且我得到了 “内置”的可访问性，正如他们所说。 就像他们所说，免费获得“免费”的东西是一件很强大的事情。
Jamie Corkhill 撰写了这篇关于 Node 的精彩文章，我认为这可能是阅读过的最好的技术文章之一。 这篇文章不仅充满了信息，适合像我这样不是每天都编写 JavaScript 代码的人，而且 Jamie 还非常有条理地从 JavaScript 的基本知识（如同步和异步函数）逐步讲解，直到使用我们自己的 API。
Jamie 写道
Node 究竟是什么？ Node 的“异步”到底意味着什么，它与“同步”有什么不同？ “事件驱动”和“非阻塞”到底意味着什么，Node 如何融入应用程序、互联网网络和服务器的更大图景？
在本系列中，我们将尝试回答所有这些问题以及更多问题，我们将深入了解 Node 的内部工作机制，了解超文本传输协议、API 和 JSON，并利用 MongoDB、Express、Lodash、Mocha 和 Handlebars 构建我们自己的 Bookshelf API。
如果你不是每天都从事 JavaScript 工作，但一直想更详细地了解 Node，我强烈推荐这篇博文。
Manuel Matuzovic 指出，为了在一些相当简单的标记场景中使用 CSS 网格，我们可能会倾向于 扁平化我们的 HTML，以确保我们需要的所有元素都可以参与到网格中。 我们需要的是 subgrid 和没有错误的 display: contents;，所以我希望在一年左右的时间里，我们就能摆脱这个问题。