网页设计中的过度架构

一分耕耘，一分收获！既然都打开这篇《网页设计中的过度架构》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新文章相关的内容，希望对大家都有所帮助！

我最近在 X 上读到了 @justinfagnani 的一篇文章，内容是：

“Lit 不是框架。浏览器才是框架。”

这让我思考了近年来我们如何构建网络。

在相当长的一段时间里，如果您了解 HTML、CSS 和 JavaScript，那么您确实不需要框架来构建 Web 应用程序。最多，您可能会使用一些库来简化某些任务，但即使这些也逐渐被合并到平台本身中，例如路由或状态管理。

然而，我们的重点已经转向学习框架，现在是元框架，这确实使构建 Web 环境变得更容易。它们优化页面，自动生成必要的文件（例如 sitemaps.xml），优化图像，删除未使用的 CSS，捆绑、缩小和优化 JavaScript。是的，它们很有效。但他们不遵守标准。

像 Astro 这样的元框架可以让你使用标准，但它们并不能让这一切变得容易。相反，他们以更加用户友好的非标准格式简化使用其他框架或自己的组件，以“简化”组件创建。他们还采用技术来促进 SEO、加载和索引 - 取决于您如何实现它们。

对我来说，这种方法有两个主要问题：

1. 认知超载：开发人员不仅必须学会管理框架本身，还必须学会管理元框架及其工具集，这通常会给项目架构增加不必要的复杂性。

2. 脱离标准：专注于框架意味着我们不会投入时间来了解网络本身的最新发展，而这些发展是巨大的。例如，CSS 在容器查询等功能方面取得了巨大的飞跃。同时，JavaScript 和 HTML 也在不断发展，HTML 可能会引入新的 <select> 元素，该元素将允许 中包含 HTML 和 CSS，从而开辟新的、更灵活的方式来创建丰富的选择器。

但是，在许多框架中，这些创新是通过自己的组件实现的，因此对于开发人员来说，这些新功能似乎是框架发明而不是标准进步。

我记得几年前，当这些元框架刚刚兴起时，一位开发者兴奋地告诉我，“他们发明了SSR（服务器端渲染）；现在我们可以在服务器上生成 HTML，创建静态页面。”我惊讶地看着他。他坚持认为我也对这种“新奇”印象深刻，他说：“这不是令人难以置信吗？多棒的主意啊。”讽刺的是，SSR 从网络早期就已经存在了。

当今的 Web 开发人员，那些研究 Web 开发并进入该领域的人，往往缺乏历史背景。他们不知道网络开发最初是如何运作的。他们不明白我们从服务器端渲染转向客户端渲染并开始使用框架的原因。一路走来，当“Ajax”流行起来时，我们迷失了方向——可能是因为希望标准能够涵盖我们需要的一切，而大公司却在努力在浏览器中强加自己的标准、标签和语言（我仍然记住微软臭名昭著的 VisualBasicScript）。

框架不是问题。一点也不。他们为网络开发增添了力量和价值。它们使我们能够为每个人创建应用程序，刺激了数十万 Web 开发人员和训练营的崛起。

框架和元框架不是问题；问题在于。他们甚至帮助网络开发民主化，使数百万人能够创建应用程序并推动训练营的繁荣。但随着网络平台的成熟和标准变得更加健全，框架创建者有商业动机来保留和推广他们的工具。他们不会说，“停止使用我的框架；现在你可以按照标准做任何事情。”另外，将使用这些框架构建的应用程序迁移到标准几乎是不可能的，特别是根据我的经验，大多数缺乏 E2E 或功能测试来确保迁移保持原始行为。

那么，我们为什么不投资于帮助我们利用当今标准的工具呢？

没有一个元框架“强迫”您使用该标准，从而使这个过程变得更容易。

如果我们想要进行 SSR、CSR、SSG、ISR、Hydration、创建 MPA 或 SPA，我们需要能够帮助我们高效组织项目并协助构建和优化任务的解决方案。但我们应该充分了解自己的需求以及每种选择的利弊。这些工具应该优化图像、JavaScript、CSS，并仅生成必要的文件。他们应该允许使用符合标准的库，并充分弥补平台的剩余差距。他们应该优化和支持 SEO、加载和索引、促进测试并利用平台的力量。

是时候减少我们网络项目中的过度工程和过多的架构设计了。让我们继续学习，不仅要学习如何使用框架，还要学习如何欣赏和应用 Web 标准中令人难以置信的进步。

没有任何借口。

到这里，我们也就讲完了《网页设计中的过度架构》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！