观点

成为一名更好的工程师、享受性能优势并更快行动的简单方法是不要过度设计您的代码。很多时候我都看到项目遭受过度设计的影响。真的。这通常是根本原因。我们需要杜绝假设复杂性与智能相关。聪明人总会让事情变得简单易懂。

如果您对自己的手艺感到自豪，那么追求代码的简洁性是很有诱惑力的。做一段时间。但不要止步于此。不要成为一个干净的代码狂热者。干净的代码不是目标。这是试图从我们正在处理的系统的庞大复杂性中找出一些意义。让干净的代码引导你。然后让它随风而去。

如果您的初次交互是可见的，例如阅读文章或查看图像，则使用 HTML 来承载这些内容。大多数框架现在都提供服务端渲染的功能——只要确保客户端 JS 正在加载时没有呈现大量不起作用的按钮。您可以延迟加载和执行零散交互的代码，按照用户最有可能需要它们的顺序加载它们。

代码应该为人类（包括未来的你自己）而不是为计算机编写。几乎每一个性能优化都是在速度和其他东西之间进行权衡。在大多数情况下，你放弃了可读性、表达性和/或惯用语。这些基本价值不会出现在你的评价标准中，但这并不意味着他们能被忽视。

工程师的经验应该为用户体验服务。我们开发的终极目标是关注那些使用我们网站的人。我们考虑网站上的用户体验挑战时，我们可以调整经验来引导工程师自然而然地去做正确的事情。我们应该只提供我们需要的资源，并应该努力让它们在需要之前达成。

让代码保持简单。使其易于他人阅读和维护。设计模式很棒，但是当它们明显增加价值时使用。把一切都分解成简单的想法。保持代码清晰、简洁和重点突出。团队将赞赏这可以增加的清晰度。

当前对 SPA 的辩论中，往往缺失了一个环节：“现代 SPA” 的定义。老派的 SPA：在任何渲染或交互之前加载整个应用。现代 SPA：SSR（或提供静态页面）用于快速渲染 (FCP)，最小路由级别代码拆分以实现更快的交互性。

我对抽象的哲学（如 React 组件）：如果你的抽象在 10 个案例中有 9 个有效。那是好的抽象。如果在其中一种情况下还不够，那么复制/粘贴（即分解成小的片段）并针对这种情况进行调整。不要改变抽象。

大多数站点会加载大量第三方库。衡量和了解这些对用户初始加载体验的影响非常重要。Airbnb 优先考虑用户可以输入搜索词的位置，这需要我们加载一些 JavaScript 并使用 React “注水”到我们的页面。在这一关键时刻完成之前推迟某些任务可能是有意义的。

归根结底，交付一个需要更少代码来的架构是未来的你自己（或同事）会感谢你的一种长期收益的做法。有可能——甚至很可能——采用这样的模型需要更多的前期设计思维。很少有自备全套工具库的选项可用于将应用程序分解为可独立交付的小部件。

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

如果你觉得你有充分的理由相信最佳实践或技术不适合你的应用，那么你应该相信你的直觉并继续你自己的解决方案。有时，在许多情况下可能运行良好的技术或最佳实践实际上可能在另一个给定上下文中的反模式。

性能是一个多方面的东西。如果我们可以将它减少到一个单一的指标，比如捆绑大小，那就太好了，但是如果你真的想涵盖所有的基础，那么有很多不同的角度需要考虑。这些可能包括运行时 CPU 成本、功耗和内存。

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

仅仅“禁用所有 JavaScript”并假装这对大多数网站来说就足够了是不够的。实际上，我们想要世界上最好的。我们想在 React/component 模型中开发（热重载等）-> 让它在构建时创建 HTML ~> 只在需要时加载微小的 JS。

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

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

前端技术分歧很多时候可以概括为不愿意从不同的角度看待项目。文档和应用的 CSS 作用范围不同。JS 复杂性有时是业务需求所必需的。它永远不会“只是”一个答案。

根据具体情况，存在细微但常见的权衡，这使得两种选择（在 SPA 与 MPA 辩论中）都是完全合理的。写下你的目标和非目标，然后分析选项的取舍，并选择一个似乎以更少的取舍实现更多目标的选项。

促进局部推理。您应该能够独立地关注代码的每个部分，而无需将整个系统放在脑海中。以我的经验，这是使复杂系统规模化的关键，尤其是（但不仅）在大型组织中。

不同的应用类型会导致不同的 LCP 结果。SSG（使用 getStaticProps() 在构建时获取您的数据并预渲染您的应用程序），SSR（使用 getServerSideProps() 获取您的数据并在请求时预呈现您的应用程序），CSR（服务器上的应用程序外壳，然后在客户端获取您的数据并重新渲染）和 ISR（您可以在其中为某些页面子集静态构建站点——并按需渲染其余页面）。

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

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

如果我们使用能够让我们用更少的代码表达相同想法的工具，就像 jQuery 所做的那样，我们的应用程序将会更加健壮。我的职业生涯是在新闻和软件的交叉领域度过的，我开始相信编写代码与写散文的共同点比与工程的共同点要多。

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

在构建 Jamstack 站点时，从“静态优先”的理念开始。当您必须渲染大量页面时，请使用延迟渲染。每当内容无法静态呈现时，请明智地使用 SSR。当您需要修改已经渲染的页面时，使用边缘渲染。

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

对于初学者开发人员，“反模式”意味着“从不这样做”，而实际上，它应该意味着“评估是否/何时应该这样做并理解警告”

性能预算让每个人都在同一个页面上。它们有助于营造一种共享热情的文化，以改善现场用户体验。有预算的团队也发现更容易跟踪和绘制进度图。这有助于支持执行发起人，然后他们可以通过有意义的指标来证明所进行的投资是合理的。

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

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

您不应该将 Context 用作全局状态。如果需要，您应该使用状态机，但是将您的状态向下移动通常会解决您遇到的任何“重新渲染过多”问题。

停止将您的代码视为将传给后人的珍宝。他们不在乎你的抽象、你的 DRY 或你出色的设计。祖传代码的价值在于能稳定工作而无需触碰的特质。

这是我对 UI 作为纯函数对比拥抱 DOM 的可变性的看法……没有人在乎。人们使用易于使用的东西并让他们感到高效。其他一切都是您围绕项目建立的神话，以使其成功看起来比这更深刻。