注：这是一个相当笼统的帖子，写给好奇的人如何思考"前端"。然而，我认为它与感兴趣的人类的所有知识和技能水平有关。
上周我写了一篇名为 "实用前端架构"的帖子。它得到了一些意想不到的爱黑客新闻，并取得了头版。现在很多人都读过那个帖子，我希望我能重写它。
其一，尽管其宏伟的标题，该帖子狭隘地专注于我们在 Liferay 云面向企业的用例和我们在最近的堆栈升级期间实施的一些模式。事后看来，我宁愿详细介绍更多我的建筑特定想法。对于两个， 这意味着这是 "另一个反应 + 下一个.js技术帖子" 在互联网上。
React + Next.js下一步有什么问题吗? Maybe. 这取决于你正在建造什么。
了解前端
正面不能免除良好的软件制造的严谨和清醒。毕竟，前端是软件。"前端"实际上只是指"支持接口的软件"，界面传达数据。整个软件系统中有很多接口，包括后端。
无论在哪里交换数据，都有一个界面。每个界面都旨在满足特定的数据交换需求集。后端接口往往适合面向计算机的需求;正面接口往往适合以人为本的需求。归根结底，计算机是有价值的，因为它们帮助人类。因此，由于前端支持计算机和人类之间的界面，因此构造良好的前端是更大的硬件-软件-人际关系的重要组成部分。
前端接口可能为不同于后端接口的消费者提供服务，但前端接口系统不应比后端系统更小心。只要前端代码糟糕透顶，后端系统就无法为人类提供价值。
后端通常是显而易见的
以我的经验，后端是比较明显的。构建后端时，需求是明确的，技术解决方案往往会直截了当：
_
我们需要移动这个文件，计算机。嘿！我说我们用这个工具上次我检查时，它把文件移到那台电脑上。
move-file-to-that-computer... 我运行了该工具，但该文件不在计算机上。
move-file-to-that-computer 工具必须损坏。 也许是模块 move，或者我想可能是适配器 that-computer。_
后端工程主要涉及将已经制造的东西插入对方，并编写最小、清晰的胶水代码。诀窍是明智地选择质量已经制造的东西，保持这些东西尽可能简单，设计一个明显和实用的系统，利用这些东西的优势，当定制的东西需要做，使他们尽可能聪明，因为他们需要，并没有更聪明。_
有时，整个程序必须从相对零开始编写。可能会出现复杂的问题，如多阅读，使工程师有必要弄清楚在线程之间传递的消息是否是一种适当的解决方案。然而，"原则"通常规定软件应该是模块化的，显而易见的，简单的，接口在打开和关闭之间达到适当的平衡（每个用例）。
前端很容易过度工程化
根据我的经验，前端系统经常被刑事过度工程化。虽然不好，但有充分的理由让这一点发生。
前端管理着一个巨大的数据转换。前端系统在通过其接口传送数据时，通常需要显著转换该数据，将其转换为可视信息。让我们列出一些来自计算领域重大数据转换的例子：
- electrical frequencies/amplitudes/voltages → binary
- binary → another base (基础 10 是我个人的最爱)
- numbers → letters (字符代码)
- numbers → larger sets of numbers (内存引用)
- sets of numbers → dank memes on a screen (前端)
如果您没有注意到，最后一个项目总结了大多数曾经存在或将永远存在的前端系统的唯一目的。不是模因;在屏幕上显示数据。
将扩展数据转化为可视信息是一项不小的任务。幸运的是，硬件（无论如何，对我们来说）为我们做了大部分的工作。然而，所涉及的复杂性需要整个演示语言系列，每个语言都有自己的完成工作的方式，具体取决于其目的。
例如，HTML 是一种无处不在的加价演示语言，使工程师能够在 Web 浏览器上表示数据。其他一些演示语言实际上只是面向对象的编程语言，如Objective-C 或 Swift，它们都充当工程师操作 iPhone 硬件和管理视图的 SDK。组织演示逻辑的需求已让位于许多在屏幕上显示整个应用程序的流行模式，例如模型视图控制器（MVC，即"数据源、演示代码、逻辑"）和模型视图模型 （MVVM）。
旁白：前端模块应该是"哑巴"。前端界面通常被称为"演示层"是有原因的：前端接口的单一责任是将它们消耗的扩展数据呈现给 Web 浏览器或其他 UI，并且此演示责任足够繁琐，而无需在方程中添加数据转换。前端代码不应负责缩放数据转换;这就是后端代码的工作。因此，应用状态管理应尽可能"后退"到服务界面上。如果前端状态管理似乎有必要，则后端接口应进行审核。如果确实有必要，例如依赖高度动态数据的复杂应用，则数据应作为后端和演示代码之间的"服务层"以直截了当的方式进行消耗和表示。前端的工作是演示，而不是计算。
视觉数据远比缩放数据复杂。从：艺术博物馆存在。让我知道， 当一个数字博物馆弹出， 我会退缩。有一个众所周知的添加数字的方法，这就足够了。有一百万种方法来显示颜色和形状，我们想要更多。因此，在 Web 浏览器上显示颜色和形状的"新方法"总是如出一片。这两者都很好 （如果你喜欢变形， 照耀你疯狂的钻石） 和有点问题 （吉米克大风） 。但有一点是肯定的：前端涉及的可能性大于后端。
冗余解决方案揭示了问题空间
视觉数据的复杂性和与显示它相关的巨大可能性意味着人们将发明（发现）许多不同的方式做同样的事情：从计算机向人类传递数据。这增加了前端世界的噪音，使得在众多反模式中更难找到生产模式。
虽然生产性前端模式难以辨别，但我们已经可以通过观察前端技术历史上的冗余周期来了解问题空间的存在。随着技术的进步，可能会有新的问题需要解决，但阳光下没有什么新鲜事。网络系统中只有如此多的需求，这意味着有效满足这些需求的方式是有限度的。辨别好的方法是理解问题空间前沿边界的关键，因此，是制定有效的模式和解决办法的关键。
我们看到的一个冗余周期是模板发动机。20 年前，有 PHP 。12年前，有胡子。8 年前， 进入反应 （切片面包以来最酷的东西） 被无端地应用到太多的应该静态的博客网站计数的方式。 Mustache.
解决特定问题的好方法只有这么多。无端反应网站就是一个例子：我们目睹了太多的坏方法。
围墙花园问题
我之前帖子的一位评论员这样说：
我认为这是我与现代前端模因的烦恼， 他们感觉像墙花园的任意知识， 只适用于他们的生态系统， 而不是一些关于软件的基本学习。
这是一个有据可查的问题，并不是什么新鲜事。jQuery UI 也是如此（不是说我在身边）也是如此，下一个广受欢迎的包罗万象的工具包也是如此，它承诺快速赢得 Web 开发人员。 documented problem
不知道什么是"hydration"? 没事的它完全特定于"动态模板引擎"（如反应）的工作原理，在球体之外没有意义。如果你刚刚了解了水化，或者大多数任何其他类似反应的概念，那么想想它可能是深奥的。换句话说， 不要试图告诉你当地的福特兰狂热分子， 你正在 "保湿" 你的网站...他会看着你搞笑。
知道"什么是hydration"可能不会使任何人成为一个更好的软件工程师，但知道为什么它很重要的反应只是可能。反应是一个很酷的工具，由聪明人谁决定"水化"这个词应该是指他们的好主意，附加事件处理程序预先渲染HTML，而不是直接重新渲染它，提高服务器渲染的反应应用程序的第一加载性能。
优秀的工程师不只是使用工具，他们做事。
不要使用工具，做一件事
行话并不令人印象深刻;它经常混淆比什么都重要。让我们说清楚。
反应只是将 HTML 以特定方式在浏览器中抛入其中的一种花哨方式，具体取决于动态数据。Vue、角和斯维尔特也做了同样的事情， 但方式与反应略有不同。
Svelte 斯维尔特很有趣：让我们尽快揭开它的神秘面纱。当 Svelte 检测到 HTML 中显示的动态数据的变化时，它实际上会根据 DOM 中的数据存在的位置对 HTML 进行手术更改。这与 React 不同，后者实际上维护了 DOM 的整个虚拟副本，其中包含对所显示动态数据的引用。响应不断解释代码，当数据发生更改时，运行一个衍射算法来检测 HTML 的哪些部分应从虚拟 DOM 中重新呈现。
如果您正在构建必须显示动态数据的前端，则上述知识是相关的。但是，在一天结束的时候，永远记住：它只是一个花哨的模板引擎，为动态应用。提高我们连接和插值 HTML 的能力的质量工具，无论是静态的还是动态的，都将受到欢迎和赞扬。但我们永远不能忘记我们在幕后的实际工作。
不要使用反应：渲染 Html 。
不要使用工具。做事。
认真对待代码
编写代码是严肃的。编写代码使事情发生。向系统添加代码通常意味着增加复杂性、混淆系统的目的（较长的句子往往不太集中）或危及安全性。编写代码应该是一项清醒的任务，在作出决定之前应考虑所有相关因素。
Hammurabi's 代码?
从 The Zen of Python:
应该有一个 - 最好只有一个 - 明显的方式做到这一点。
我有时想知道，如果前端的世界可能受益于完全重置到某种法律或代码，迫使前端工程师放弃所有的虚荣心和价值严格遵守一些无聊，但有效的原则。
幸运的是，我们确实有一个相当非正式的前端代码的制作。首先，存在合理的违约。浏览器中的用户代理样式在大多数情况下是perfectly accessible and appropriate. 此外，还做了大量工作，以制定有效的frontend design patterns 并在广大前端工程师中推广 accessibility-minded 的方法
然而，创新和前端是相当同义词，这是一件好事。与其试图遏制前端的动态性质，我们应该让工程师做好适当的准备，以优雅地管理混乱。在前端系统工作的工程师必须加倍辨别、清醒和负责，以抵消前端问题空间的现实。
如果你不知道它做什么，你就不允许使用它
我很早就学到的一条规则是： 除非你知道它的作用， 否则不要复制和粘贴堆栈溢流中的代码。本着"不要使用工具：不要使用工具，做事"，我认为这个原则可以概括：
如果你不知道它做什么，你就不允许使用它
编写设计文档是（或应该）任何软件编写过程中的一个基本步骤。同样，阐明"它的作用"应该是任何软件模样选择或架构过程中的一个基本步骤。 design docs
做出有意的决定。使用响应、运行服务人员或利用 并不能使 Web 应用变得良好。可能正好相反：不必要和无意地使用技术等于袜子和拖鞋。别这样。（除非你明白你在做什么，无论如何，在这种情况下，去和变形的人出去玩。
无论如何， 你可能不会出错与一个普通的 Html + Css 网站。
精神: 来自 vs. substance
营销人员可能比我们更了解我们。这项消费者心理学研究是研究人类自我概念和他们购买的东西之间联系的众多研究之一。我们消费的东西提供了我们重视什么，我们认为我们是谁，我们想成为什么样的人一瞥。This consumer psychology study
前端认为他们是谁？前端想成为谁？你是谁不是艺术， 变化无常的前端？
前端是性感的， 这可能是坏的
前端工程主要涉及张贴你早上喝咖啡的照片， 而你吊索反应组件周围和缓存一切全球， 而不考虑适当的国家管理。好吧，最后一句话是我只是把油漆扔到墙上。但有一个真理的戒指。
我找不到硬数字来支持这一点， 但我的看法是， 前端是一个更成熟的目标， 新的工程师比后端。前端感觉很熟悉。建立网站是花哨和乐趣。您不需要了解数据库技术或获得对旧系统的感觉;所有你需要知道的都可以在一系列 Instagram 可使用的博客文章中找到。
对于新的前端工程师，尤其是像我这样不学习计算机科学的工程师来说，前端世界是华丽、令人兴奋和容易接近的。需要运行构建时间任务？There's a package for that. 需要执行算法而不学习任何算法？There's a pretty bulky package for that too. 需要检查数字是否为 10，000There's even a package for that.
安装神奇的 NPM 模块很容易，这意味着很容易构建一个巨大的、脆弱的、不必要的依赖树来权衡您的应用。NPM近年来一直与争议相邻，但NPM只是人类使用的工具。NPM 本身没有问题;是人类人类是X因素，除非我们更清楚，否则我们人类会倾向于闪亮的东西。
我不相信为帮助劳动人类制作更好的软件而制作的工具应该像面向消费者一样进行营销。成熟的工程师知道，只有有效地完成正确的任务，工具才是好的。如果说有什么不同的话，那就是工具炒作分散了不太成熟的行业成员（包括工具用户和工具制造商）对软件工程最终目标的注意力：构建有用的东西。
前端的性感是工程师，特别是新工程师，要想开发有效的系统，必须拥有特殊的智慧和清醒的另一个原因。以前端为中心的人类应该小心和务实，前端文化应该反映和培养这些特征。
在无服务器上唠叨真的很快
不仅仅是前端。有时后端试图性感， 当它发生时， 它是显而易见的。"无服务器"就是一个例子。
"无服务器"一词的用词（读：混乱、行话、虚假承诺）实际上只是意味着"云公司只向您收取您使用的资源费用，因为它们在超时后取消为您的后端提供"。仍有服务器涉及：它只是被称为 "无服务器"， 因为没有任何单一的服务器只为您工作。如果有什么应该被称为"方式比以前更多的服务器"。无服务器的一个主要缺点是，您的"无服务器"程序如果不经常使用，就会入睡，当实际使用与配置的唤醒性不匹配时，会导致极端的启动延迟。
无论如何， 你不会知道它的名字， 但没有服务器是有用的...取决于工作。
没有金锤
以前说过，我会再说一遍：用最好的工具做手头的工作。你的模具性感和令人兴奋吗？特别小心，确保它不不切实际。
在一天结束的时候，应用程序可能做一些非常简单的事情，它可能做许多其他相当简单的事情来实现这个目的。批判性地思考手头的工作，并尝试了解满足要求所必须发生的一切。记住，如果你不知道它做什么，你不允许使用它。如果你不明白你在做什么，为什么，你不允许这样做。
缩小后，前端只是一个数据管道，将数据从计算机传送给人类。
