Kev Quirk 的一篇简短观点文章：为什么我不使用静态网站生成器。Kev 使用 WordPress
想在iPad 上写博客？我可以。想在手机上写？没问题。在我不常使用的机器上写？只要有浏览器，都不是问题。
首先，值得了解的是，使用 WordPress 并不意味着你无法使用静态网站生成器。WordPress 具有一个API，这为在构建过程中调用该 API 并以此方式构建网站打开了大门。 Gatsby 就是这么做的，有一个插件可以导出静态网站，而像Frontity这样的项目则模糊了界限。
但我同意 Kev 在此处的推理。出于他所有以及其他 1000 个原因，运行 WordPress 网站是一个完全可以接受且通常很明智的选择。我认为它在稳健性和功能完备性方面具有优势。需要电子商务功能？它就在那里。需要表单？有很多很棒的插件。需要增强 CMS 的工作方式？您可以控制内容类型及其内容。需要身份验证？这是核心功能。希望获得很棒的编辑体验？Gutenberg 非常棒。
一次又一次地，我用 WordPress 快速有效地构建我想要构建的东西，这让我感到高效和强大。但我不希望专门针对 WordPress 来说明这一点；对于任何“经典”CMS 来说，这都是正确的。Craft CMS 具有一个开箱即用的 GraphQL API。我们刚刚发布了关于Drupal + Jamstack 网络研讨会的信息。
在相对较新的静态网站领域，一件小事最终可能变成一段研究和实施的旅程，就像你是地球上唯一第三个这样做的人一样。
说了这么多……
我对静态网站生成器和Jamstack 世界的看法如何？它们很棒。
我认为用这种方式构建网站有很多值得称道的地方。数据和前端的解耦非常聪明。安全性极佳。DX，加上部署预览和基于 Git 的一切，都非常棒。一开始获得的速度令人惊叹（从 CDN 提供 HTML 是一项壮举）。
就像经典的服务器端 CMS 不会阻止你构建静态网站一样，使用静态网站构建也不会阻止你进行动态操作——甚至是非常花哨的动态操作。Josh Comeau 有一篇很棒的新文章深入探讨了这一点。他构建了一个花哨的小应用，在浏览器中使用 React 进行了大量操作，但这并不意味着他仍然不能静态地提供大量内容。他称之为“思维方式的转变”，指的是你可能认为你需要数据库调用，但真的需要吗？数据库调用是否可能已经发生并生成了静态文件？如果没有，那么仍然可以部分生成，最后一部分通过动态方式获取。
我迫不及待地想要看到一个世界，在这个世界里，我们开始真正看到两全其美。我们尽可能多地使用静态方式，我们通过 API 获取无法以静态方式获取的内容，并且在整个过程中不会牺牲最佳工具。
何时选择静态网站……
- 如果可以，你应该考虑它，因为它的速度和安全性无与伦比。
- 如果你正在处理一个 Greenfield 项目。
- 如果你的项目构建自可访问的 API 并使用这些 API，你可以在构建过程中调用该 API，以及在初始 HTML 加载后使用它。
- 如果某个静态网站生成器看起来非常适合你正在做的事情。
- 如果成本分析表明它更便宜。
- 如果某些功能（如构建预览）对工作流程非常有帮助。
何时选择服务器端软件……
- 如果你需要经典 CMS（例如 WordPress）的功能，并且从那里转向静态的的技术债务过高。
- 如果你已经深度参与了一个服务器渲染项目（Ruby on Rails、Python 等），并且没有遇到任何现有问题。
- 如果你的团队在该方面拥有最多的专业知识。
- 如果成本分析表明它更便宜。
- 如果想要构建的内容周围没有好的静态解决方案（例如论坛软件）。
- 如果你遇到极端情况，例如数百万个 URL，并且静态构建时间过长。
避免静态网站的错误理由……
- 你需要使用服务器来做一些事情。（为什么？你仍然可以在服务器上调用 API，无论是在构建时还是在运行时。）
- 你需要身份验证。（为什么？Jamstack 可以使用 JWT 等完美地实现身份验证。）
- 你甚至还没有考虑过以 Jamstack 方式做事。
选择服务器端软件的错误理由……
- 你甚至还没有考虑过以 Jamstack 方式做事。
- 因为你认为使用舒适/现有/经典/成熟/受支持的工具会让你无法构建任何静态内容。
- SEO 之类的东西。（如果有的话，静态渲染的内容应该表现得更好。但如果转向静态意味着转向像产品数据这样的客户端调用，这是可以理解的。）
我认为值得更深入地探讨这个话题。例如，性能如何？我当然不是一个可以谈论性能的人（我的网站都非常依赖 JS），但有人可能会争辩说，Jamtack 方法会导致网站变慢和变重，因为它将如此多的逻辑放在客户端（参见https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/）。
这与 Jamstack 诞生于传统的静态网站有些矛盾。但是，当你开始谈论身份验证、API 等时，你必须承认你的用例与几年前 Jekyll 或 Middleman 所做的事情几乎没有共同之处。
在某些情况下，你可以将两者的优点结合起来，对于普通用户使用的更新频率较低的内容页面和新闻，像 Laravel Export 这样的工具可能会派上用场：你可以为他们构建一个漂亮的 CMS 来使用，但让他们每次更新都部署静态网站。但显然，你仍然需要一个合适的托管来保持构建链的运行。
完全同意选择 WordPress 或构建服务器端应用程序都是合理的选择。我对他的文章唯一的问题是，它传播了一种过时的错误观念，即在 Jamstack 网站上编辑内容需要通过 SSH 连接到服务器，并使用 vim 手动编辑文本文件。
作为一名前端开发人员（CSS 爱好者），我创建了我的最后一个应用程序，完全是客户端的，但缺少了一样东西，并且由于网站有很多页面，它对此没有解决方案，只能使用服务器技术：使用开放图和 SSR 的社交网络预览……