是否静态？

静态网站生成器？我为什么不用？ Kev Quirk 的简短评论：Kev 使用 WordPress：

想在 iPad 上写博客？没问题。想在手机上写？也可以。在我不常用机器上写？只要有浏览器，一样没问题。

首先，值得一提的是，使用 WordPress 并不意味着你不能使用静态网站生成器。WordPress 有一个 API，这使得在构建过程中调用 API 来构建你的网站成为可能。Gatsby 就是这么做的，它有一个导出静态网站的插件，而像 Frontity 这样的项目则模糊了界限。

但我同意 Kev 的理由。基于他的所有理由，以及其他无数理由，运行一个 WordPress 网站是一个完全可以接受的，而且通常是明智的选择。我认为这关乎健壮性和功能的完备性。需要电子商务功能？WordPress 有。需要表单？有很多优秀的插件。需要增强 CMS 的功能？你可以控制内容类型及其内容。需要身份验证？这是核心功能。想要出色的编辑体验？Gutenberg 棒极了。

一次又一次，我快速高效地用 WordPress 构建我想要的东西，这让我感觉高效且强大。但我不想特别谈论 WordPress；这同样适用于任何“经典”CMS。Craft CMS 原生就具有 GraphQL API。我们刚刚发布了一个关于 Drupal Jamstack 网络研讨会的帖子。

在相对较新的静态网站世界中，一件小事最终可能变成一段漫长的研究和实施过程，感觉就像你是地球上唯一一个这么做的人。

话虽如此……

我对静态网站生成器和 Jamstack 世界的看法如何？它们很棒。

我认为以这种方式构建网站有很多好处。数据和前端的分离很明智。安全性很高。开发人员体验也很好，部署预览和基于 Git 的一切都很棒。启动速度惊人（从 CDN 提供 HTML 服务是一项壮举）。

就像经典的服务器端 CMS 不会阻止你构建静态网站一样，使用静态网站也不会阻止你做动态的事情——甚至是超级高级的动态事情。Josh Comeau 有一篇很棒的新文章深入探讨了这一点。他构建了一个在浏览器中使用 React 完成大量工作的漂亮小应用程序，但这并不意味着他仍然不能静态地提供大部分内容。他称之为“思维方式的转变”，指的是你可能认为你需要数据库调用，但你真的需要吗？数据库调用是否已经发生并生成了一个静态文件？如果没有，那么仍然可以静态生成一部分内容，剩下的部分动态获取。

我期待着一个世界，在这个世界里，我们开始真正看到两全其美。我们尽可能多地静态生成内容，通过 API 获取我们无法静态生成的内容，并且在整个过程中不会牺牲最佳工具。

何时选择静态网站……

• 如果你可以，你应该考虑一下，因为它的速度和安全性无与伦比。
• 如果你正在处理一个 Greenfield 项目。
• 如果你的项目构建自并使用可访问的 API，你可以在构建过程中调用该 API，以及在初始 HTML 加载后使用它。
• 如果某个静态网站生成器看起来非常适合你正在做的事情。
• 如果成本分析表明它更便宜。
• 如果某些功能（如构建预览）对工作流程非常有帮助。

何时选择服务器端软件……

• 如果你需要经典 CMS（例如 WordPress）的功能，并且从那里转向静态的的技术债务太高。
• 如果你已经深入参与了一个服务器端渲染项目（Ruby on Rails、Python 等），并且没有遇到任何现有问题。
• 如果你团队在该领域拥有最多的专业知识。
• 如果成本分析表明它更便宜。
• 如果没有针对你想要构建的内容的好的静态解决方案（例如论坛软件）。
• 如果你遇到极端情况，例如数百万个 URL，并且静态构建时间太长。

选择静态网站的错误理由……

• 你需要使用服务器。 （为什么？你仍然可以在构建时或运行时调用服务器上的 API。）
• 你需要身份验证。（为什么？Jamstack 可以通过 JWT 等完美地实现身份验证。）
• 你甚至都没有考虑过 Jamstack 方式。

选择服务器端软件的错误理由……

• 你甚至都没有考虑过 Jamstack 方式。
• 因为你认为使用舒适/现有/经典/成熟/受支持良好的工具会阻止你静态构建任何内容。
• SEO 之类的问题。（如果有什么不同的话，静态渲染的内容应该表现更好。但是，如果转向静态意味着转向客户端调用来获取产品数据等内容，这是可以理解的。）

以上是是否静态？的详细内容。更多信息请关注PHP中文网其他相关文章！