前端框架的隐性成本

我们都希望我们的网站看起来有吸引力，并且在多种设备和屏幕尺寸上感觉快速且响应灵敏。前端生态系统中开发了一些常用工具来帮助构建此类界面。

最常见和众所周知的是 react，还有许多其他人共享这个空间，例如 svelte、solidjs、angular、vue、qwik 等。所有这些都是令人印象深刻的工程壮举，并带有大胆的陈述。

反应：

web 和本机用户界面的库

固体：

用于构建用户界面的简单且高性能的反应性。

vuejs：

一个用于构建 web 用户界面的平易近人、高性能且多功能的框架。

无论如何，他们都有一些共同点......

javascript

如果您打算使用这些框架之一编写整个项目，那么无论好坏，您都将用 javascript（或 typescript）编写所有逻辑。毕竟，javascript 是网络语言，对吗？它就在浏览器中，用同一种语言编写 web 应用程序似乎是很自然的事情。

仅，如果您要编写一个全栈应用程序并拥有服务器渲染或静态渲染的页面，您很可能会使用元框架，例如 nextjs、remix、sveltekit、solidstart。

这意味着您将需要一台服务器，并且它也将运行 javascript。您在这里实际上没有选择，框架在这种情况下强制要求您的架构。

方便胜过简单

但这不是问题吧？我的意思是，上手非常简单简单。让我们看几个启动和运行的示例。

nextjs：

npx create-next-app@latest
cd my-project
npm run dev

solidstart：

npm init solid@latest
cd my-project
npm install
npm run dev

在这两个示例中，它都会使用一些合理的默认值引导项目，并让您在几分钟内启动并运行具有开箱即用热重载功能的开发服务器。这太棒了，感觉像是一次很棒的开发者体验，对吧？

假设您想为您正在开发的项目构建一个新的 web 应用程序。您可以在几分钟内让 nextjs 中的服务器端渲染交互式应用程序启动并运行，然后开始构建。这可能感觉很棒，但是您的应用程序真的需要进行如此设计才能满足其需要执行的功能吗？

你真的需要一个构建步骤来将模块和 jsx 转译为 js 包，该包可以在服务器上运行以生成初始 html，使用一堆 js 流式传输到客户端以水合 dom 节点并让客户端侧状态跟踪虚拟 dom 并在每次更改时重新渲染？

快速启动和运行可能很方便，但我们不要忘记，方便并不等于简单。在幕后，抽象层层叠加，让“魔法”发生，随着时间的推移和项目规模的扩大，这可能会给你带来困扰。

跟上依赖关系

在上面的示例中，我们设置了一个基本项目以在 nextjs 和 solidstart 中启动并运行。不过，这里有一些有趣的事情我想强调一下。安装 nextjs 后（在多个已弃用的软件包警告下方），npm 会输出这一行：

added 361 packages, and audited 362 packages in 10s

对于 solidstart：

added 569 packages, and audited 572 packages in 18s

这些是我们初始化项目时 nextjs 和 solidstart 分别需要和下载的包的数量。

这仅适用于框架，它不包括您在项目中可能需要访问的任何包。想要有一个代码格式化程序来强制格式化一致吗？下载更漂亮。想要强制执行一些代码规则吗？下载 eslint。想要有类型吗？下载打字稿。想要运行测试吗？下载 jest（或者可能是 vitest），这样就会一直持续下去。

虽然这看起来微不足道，但我认为这表明我们可能没有按照预期使用 javascript，并且我们最终不得不使用包来执行相对常见的操作。这会导致依赖关系与依赖关系（在此处插入node_modules meme）。

需要如此多的依赖关系本质上会让你的项目变得热血沸腾。如果您 6 个月不碰这个项目，当您再回来时可能会发现它已经过时了。

不用担心！您不需要让事情保持最新，对吗？嗯，这取决于。假设您具有安全意识，并使用 dependabot 之类的工具来扫描您的依赖项是否存在漏洞。您可能会发现每周都有几个，特别是如果您的项目有数千个依赖项，这对于中型到大型项目来说并不罕见。

假设您根本不关心更新。项目越老，避免释放依赖瀑布就越困难。最终，当需要更新 node、想要使用新发布的功能或添加与另一个过时依赖项不兼容的新包时，您将不得不打开闸门。

另一方面，我见过一些项目想要保持所有依赖项的最新状态，这可能会导致每天多个包更新，有时会引入一系列有趣的错误和怪癖，使其通过测试并投入生产.

将其推广到多个项目，突然之间，它会让人感觉像是一种持续的背景压力，并且每周需要测试和更新项目以保持它们的相关性并避免积满灰尘。

快速发展的生态系统

您可能已经看过“又一个 js 框架”的表情包。从更积极的角度来说，我们可以说生态系统正在不断创新、进化和变化。这些项目投入的大量工作和热情确实令人印象深刻。然而，在生产环境中开发 web 应用程序时，这也会产生负面影响。

如果您已经在这个领域工作了一段时间，您可能已经使用 create-react-app 创建了您的第一个 react 项目来帮助您启动并运行。太糟糕了，现在它已被弃用，也许你应该转向 vite。也许您使用 gatsby 制作了第一个静态 react 项目。嗯，现在已经不推荐使用了，您可能应该迁移到 nextjs 或 remix。已经在使用 nextjs 了吗？您可能应该迁移到应用程序路由器。也许您开始将 react 组件编写为具有逻辑生命周期挂钩的类。嗯，这是旧方法，您现在应该编写功能组件，并希望将正确的依赖项传递给 useeffect 挂钩。但是等等！等一下，react 服务器组件就在这里，并且智能编译器正在路上。

这种不断的转变和试图保持领先地位增加了技术债务，并增加了保持项目最新的负担。想一想今天使用 react 时需要了解的所有概念，与 2016 年刚刚出现的人相比。值得称赞的是，react 一直保持向后兼容，但我们不能忽视与时俱进所需的认知开销今天的最佳实践。

开发者经验谬误

这让我想到了开发者体验。当然，到目前为止我们所看到的一切都可以被视为对这些框架必须提供的出色开发人员体验的权衡？

虽然我确实相信目前的开发者体验很棒，但我觉得经常被忽视的是开发者体验随着时间的推移。当然，在几秒钟内启动一个新的开发服务器，并且几乎可以即时热重新加载更改，感觉很棒 - 但如果您多年来跟踪每次需要重构、升级或维护项目的情况，那么突然之间，这种体验就变得很糟糕。没有那么好，这一点不应该被忽视。

那么，有哪些要点呢？

使用适合工作的正确工具

在构建 web 应用程序时，不要仅仅接受 web 框架是默认且最佳的选择。查看您的用例。它需要是单页应用程序吗？您需要这样级别的客户端交互吗？您可以使用 htmx 之类的东西和您选择的任何语言来生成页面来实现类似的目标吗？

保持简单

技术很酷，但有时我们只需要一些足够好的并且以简单的方式完成它需要做的事情。这可以帮助我们保持理智并避免倦怠感。避免过早抽象，尝试遵守网络标准并且不要扩展到月球。

作为开发人员，我们可能会担心太多，并专注于完美和最好的做事方式。让我们不要忘记享受乐趣、探索和学习。如果不起作用，那就意味着您学到了一些东西，以后可以随时更改它。

以上就是前端框架的隐性成本的详细内容，更多请关注其它相关文章！