洞察

成为一名更好的工程师、享受性能优势并更快地前进的一个简单方法是不要过度设计你的代码。我经常看到项目因为过度设计而受苦。真的。这通常是根本原因。我们需要停止假设复杂性与智力相关。聪明的人会尽可能地保持简单易懂。

如果你对你的手艺感到自豪，那么追求代码的整洁性是很诱人的。这样做一段时间吧。但不要止步于此。不要成为一个洁癖代码狂热者。洁净代码不是目标。它试图让我们理解我们正在处理的系统的巨大复杂性。让洁净代码引导你。然后放手。

如果你的第一个交互是视觉性的，比如阅读文章或查看图片，那就为这些东西提供 HTML。大多数框架现在都提供某种服务器渲染功能——只需确保你没有在客户端 JS 加载时提供大量无法使用的按钮。你可以延迟加载和执行代码以进行离散交互，并按用户最有可能需要的顺序加载它们。

代码应该为人类（包括你未来的自己）编写，而不是为计算机编写。几乎每一次性能优化都是速度与其他因素之间的权衡。在大多数情况下，你放弃了可读性、表达力和/或习惯用法。这些元价值不会出现在你的测量结果中，但这并不意味着它们可以被忽略。

工程师体验应该为用户体验服务。我们开发的最终目标是关于使用我们网站的人。当我们考虑我们网站上的用户体验挑战时，我们可以调整体验来引导工程师默认情况下做正确的事。我们应该只提供我们需要的资源，并且应该努力让他们在我们需要之前到达。

保持代码简单。使它易于被其他人阅读和维护。设计模式很好，但只有在它们明确地增加价值时才使用它们。将所有内容分解成简单的想法。保持代码清晰、简洁、切中要害。你的团队会感谢这种清晰度带来的好处。

在当前的 SPA 争论中，有一点被遗漏了：“现代 SPA”的定义。老式 SPA：在任何渲染或交互之前加载整个应用程序。现代 SPA：SSR（或提供静态页面）以实现快速渲染 (FCP)，最小路由级别代码拆分以实现更快的交互性。

我对抽象（如 React 组件）的理念是：如果你的抽象在 10 种情况下中有 9 种有效。这是一个好的抽象。如果它在这 10 种情况中的一种中不够用，那么复制/粘贴（即分解成它的组成部分）并针对这种情况进行调整。不要改变抽象。

大多数网站加载大量的第三方库。重要的是衡量和理解这些库对用户初始加载体验的影响。Airbnb 优先考虑让用户能够输入搜索词，这要求我们加载一些 JavaScript 并使用 React “水化”我们的页面。将某些任务推迟到这个关键时刻完成是有意义的。

归根结底，发布一个需要更少代码来完成某事的架构，是你的未来自我（或同事）将感谢你的长期益处。这可能是——甚至可能是——采用这种模型需要更多前期设计思考。对于将应用程序分解成独立可交付的窗口小部件，有更少的“开箱即用”选项可用。

在“厚”客户端应用程序中，产品代码（其他所有内容）占客户端捆绑包大小的大部分。这里有一个真正的机会将其移到服务器组件中，这可以显著减少占用空间。例如，考虑最终呈现为单个 div 的深度包装组件的情况。服务器组件可以帮助消除这种抽象税。

如果你认为你有充分的理由相信最佳实践或技术不适合你的应用程序，那么你应该相信你的直觉，并继续使用你的解决方案。有时，在许多情况下可能非常有效的技术或最佳实践，在其他情况下可能实际上是一种反模式。

性能是一个多方面的概念。如果我们能将其简化为一个指标，比如捆绑包大小，那将很棒，但如果你真的想面面俱到，那么需要考虑许多不同的角度。这些可能包括运行时 CPU 成本、功耗和内存。

当你正在一个新项目上工作时，你很少知道哪些代码将长期重要，哪些代码即将被删除。在我的职业生涯中，我已经丢弃了足够多的代码，从而意识到快速、混乱的编码有时是有价值的。当你开始一个新项目时，有点混乱是可以的。

仅仅“禁用所有 JavaScript”并假装这对于大多数网站来说已经足够了，是不够的。实际上，我们想要所有世界的最佳。我们希望在 React/组件模型中开发（热重载等）——>让它在构建时创建 HTML——>只在需要时加载少量 JS。

(大型公司) 的工程师想出的解决方案并不适用于绝大多数软件商店：它们通常最适合能够负担得起设置高工程标准、能够负担得起大型基础设施团队和运营团队的大公司。开发者影响者正在写的内容与大多数开发者的日常现实之间存在着巨大的差距。

UI 是组件（Angular、React 等）的组合，包含复合组件和叶子组件。同样，在文件系统中，我们有目录和文件。由于组件树和文件系统具有相同的结构，因此我们可以在它们之上应用相同的算法。

前端技术的争议很多时候可以归结为不愿意从不同的角度看待问题。对于文档和应用程序来说，CSS 作用域是不同的。JS 复杂性有时是业务需求所必需的。它永远不会“仅仅”是唯一答案。

有一些微妙但常见的权衡，使得根据情况完全合理地做出两种选择（在 SPA 与 MPA 争论中）都是正确的。就像任何其他工程决策一样。写下你的目标和非目标，然后分析选项的权衡，并选择一个看起来能够用更少的权衡来实现更多目标的选项。

促进本地推理。你应该能够独立地关心你的代码的每个部分，而不用把整个系统放在脑子里。根据我的经验，这是使复杂系统能够扩展的关键，特别是在（但不仅限于）大型组织中。

不同的应用程序类型会导致不同的 LCP 结果。SSG（使用 getStaticProps() 在构建时获取你的数据并预渲染你的应用程序）、SSR（使用 getServerSideProps() 在请求时获取你的数据并预渲染你的应用程序）、CSR（服务器上的应用程序外壳，然后在客户端获取你的数据并重新渲染）和 ISR（你可以静态构建你的网站的一部分页面——并在需要时渲染其他页面）。

编写枯燥但易于理解的代码需要相当多的经验。我认为你不应该因为没有经过严格的 CS 训练而认为自己没有资格编写软件，但我也认为你不应该忽视它们。我采取了一种务实的做法，首先做了很多愚蠢的事情，这有助于揭示我需要学习什么才能让它变得更好。

重要的是要注意，每个网站和用户群都是不同的。许多发布超过 300 KB JavaScript 的开发者对它对大多数用户的性能没有问题，这很好。但是，如果你担心你的 React 网站的性能可能对你的用户来说更好，那么分析始终是一个好的第一步。

如果我们使用工具让我们用更少的代码来表达相同的想法，就像 jQuery 那样，我们的应用程序将更加健壮。我在新闻和软件的交汇点工作了我的整个职业生涯，并且我开始相信编写代码与写作散文更相似，而不是与工程。

我最近一直在大量使用 Eleventy，并且非常喜欢它，因为它很好地处理了完全静态的极端情况，而 Web 组件处理动态方面，并且由于它们只是 HTML 元素，因此可以轻松地与 Eleventy 集成。这是一种非常棒的开发和用户体验。

在构建 Jamstack 网站时，首先从“静态优先”的理念开始。当你需要渲染大量页面时，使用延迟渲染。在内容无法静态渲染的情况下，谨慎地使用 SSR。当你需要修改已经渲染的页面时，使用边缘渲染。

如今，有多少 Web 开发人员在构建应用程序时没有在手机上本地进行测试？这不仅仅是关于小屏幕，我们需要假设我们正在为更弱、更慢的计算机构建应用程序。我认为我们需要将移动设备融入我们的开发工作流程，而不仅仅是作为一些最终的发布前检查。

对于初级开发人员，“反模式”意味着“永远不要这样做”，而实际上，它应该意味着“评估你是否应该这样做，什么时候应该这样做，并了解注意事项”。

性能预算让每个人都保持一致。它们有助于营造一种对改善用户体验的共同热情的文化。拥有预算的团队更容易跟踪和绘制进度图。这有助于支持执行赞助商，他们随后有有意义的指标可以用来证明所做的投资是合理的。

随着 (React) Web 应用程序变得越来越复杂，新的解决方案出现了，以便更轻松地在组件之间共享逻辑。Redux 迅速成为最流行的状态管理解决方案。React Context 为我们提供了一个第一方解决方案来在组件之间共享逻辑。这在许多情况下解决了 UI 状态。最终，我们将拥有“useSelectedContext”。

我建议组件只应该使用自定义钩子，而不是原始钩子。通过自定义钩子封装你的关注点并正确传递上下文。

你不应该使用 Context 作为全局状态。如果你需要，应该使用状态机，但将你的状态向下移动通常可以解决你遇到的“太多重新渲染”问题。

不要把你写的代码当作传给未来世代的珍贵宝石。他们对你的抽象、你的 DRY 原则或你的天才设计并不关心。遗留代码之所以成为遗留代码，是因为它出色地完成了自己的工作，以至于没有人想触碰它。

这是我对 UI 作为纯函数与拥抱 DOM 可变性的看法......没有人关心。人们使用易于采用并让他们感觉高效的东西。其他一切都是你围绕你的项目构建的神话，让它的成功看起来比实际情况更深刻。