似乎还有这样的想法你应

rmamin

该采用一切新的东西并立即抛弃你过去 12 个月一直在使用的一切。还有一种想法是，你应该设计企业级的工程，但你应该像一家拥有 400 名工程师的大公司那样来完成每个小项目。这两种想法实际上根本不兼容。拥有数百名工程师的大公司正在使用旧的硬性技术，因为它可靠并且他们有太多的动力。他们讨厌放弃它并拿起新的东西。所以我认为这两个想法是间接冲突的。

克里斯：是的。这很有趣。你总是看到这样的整体嗯它会 电报号码数据 扩展吗？它会扩展吗？”这样的事情一直存在。有必要吗？您是否正在为 Facebook 规模的受众构建产品？我确信你会在……嗯，你会到达那里，但如果你在某个时候到达那里那就太好了，但是，如果你今天不在那里，也许这不一定是你需要的开始。就像这些不是你今天的需要一样。你正在预先设计一个问题，但你不必这样做，这会损害你已经解决的一些问题。

克里斯：我认为这里的另一件事是有这样的假设：因为 Facebook、谷歌或 Twitter 所做的事情，这是一个好主意，或者对每个人来说都是一个好主意。但事实并非一定如此。这些公司做了很多正确的事情。但他们也做很多事情很糟糕，他们这样做是因为他们必须做出工程权衡，因为他们的团队的结构或他们在做出这个决定时遇到的非常具体的内部问题，或者因为某个地方的某些高管对某件事感觉非常强烈，并让内部团队去做，尽管当时不一定是最好的。然后这些东西就一直存在。所以，是的，我认为我所看到的对我们自己不利的行业中发生的最大的事情之一就是关注那些少数真正大型可见技术公司并思考，“如果他们这样做，我也必须这样做，”或者“这对每个人来说都是正确的呼吁。”

克里斯：它是如此古老，就像没有人因为雇用 IBM 之类的东西而被解雇一样，但适用于它是否对 Google 足够好，或者它对 Twitter 或其他什么足够好，所以是的。我同意。我认为我们做了很多这样的事情，也许我们不应该这样做。

德鲁：我早些时候在 Twitter 上问过，是什么让人们对现代 Web 开发最佳实践感到沮丧，从我得到的答复来看，人们对当前的状况肯定有很多不满。一种趋势在过去几年中势头强劲，就像使用 Jamstack 构建网站的方法一样。从表面上看，这似乎回到了客户端应用程序，而服务器上没有任何复杂的东西，听起来像是回到了基础，但它真的这样做了吗？是它还是只是以不同的方式掩盖了堆栈的复杂性？



克里斯：这取决于。我在这里有点偏见，因为我个人喜欢 Jamstack，但我也见过……好吧，我不应该说我见过。我想我在这里想说的是 Jamstack 是一个术语，它可以适用于多种方法，甚至包括一端没有服务器端渲染的真正大的 2 MB JavaScript 单页应用程序。然后在另一端，完全不使用 JavaScript 的平面 HTML 文件会立即加载您的浏览器，并且恰好是从 CDN 或类似的东西发送的。从技术上讲，这两者都是 Jamstack，而不是平面 HTML 的东西。因此，Jamstack 本质上并不比服务器渲染的更好，但在许多情况下确实可以。

克里斯：对于那些不知道的人来说，Jamstack 曾经是 JavaScript、API 和 Markup 的缩写，后来他们改变了拼写并稍微改变了定义。它确实包含了一种不依赖服务器端渲染的 Web 构建方法。因此，您所提供的任何内容都已经编译并组合在一起，这就是浏览器中提供的内容。如果发生任何其他处理或脚本，也会发生在客户端中。不一定，但经常会。因此，我认为 Jamstack 的厉害之处在于，如果以某种方式完成，它可以极大地提高您正在构建的东西的性能。