Every so often, web development takes a dramatic turn for the better. In this article, we introduce the Jamstack, explaining what it is and why it’s great.
Web开发常常每况愈下。 在本文中，我们介绍了Jamstack，解释了它是什么以及为什么它很棒。
Back in the day, dynamic sites exploded with the LAMP stack. Then the MEAN stack provided a foundation for the next generation of web apps. Now that APIs and reusable components are on the rise, static sites are fashionable again. It’s a “back to basics” of sorts — but not quite.
过去，动态站点随LAMP堆栈爆炸。 然后，MEAN堆栈为下一代Web应用程序奠定了基础。 现在，API和可重用组件正在兴起，静态站点再次流行。 这是某种“回归基础”的方法，但还不完全是。
什么是Jamstack？ (What Is the Jamstack?)
Provided: Netlify
提供：Netlify
The Jamstack is a redefinition of the modern web for faster and more secure websites. These sites scale better and, with the proper toolset, are a lot easier (and more fun) to develop and maintain.
Jamstack是对现代Web的重新定义，可以实现更快，更安全的网站 。 这些站点可以更好地扩展，并且使用适当的工具集，可以更轻松(也更有趣)地开发和维护。
Let’s break up the term:
让我们分解一下这个术语：
-
J stands for JavaScript. JS has come a long way since it was introduced by Netscape in 1995. With reactive and progressive libraries, you can design web apps that behave pretty much like mobile ones.
J代表JavaScript 。 自从Netscape在1995年推出JS以来，它已经走了很长一段路 。有了React式和渐进式库，您可以设计行为类似于移动应用程序的Web应用程序。
-
A stands for APIs. You don’t need to program every single functionality yourself, but can rely on third-party processing for a huge number of tasks.
A代表API 。 您不需要自己编写所有功能，而可以依靠第三方处理大量任务。
-
M stands for Markup. You can reuse components that have already been developed, or create new ones that are a lot easier to maintain.
M代表Markup 。 您可以重用已经开发的组件，也可以创建易于维护的新组件。
这不只是嗡嗡声吗？ (Isn’t that just buzz?)
In a way, yes. The term Jamstack, originally stylized as JAMstack, was coined by the company Netlify as a way of promoting their “all-in-one platform for automating modern web projects.” The principles behind the Jamstack aren’t really new, as web components and APIs have existed for quite some time.
在某种程度上，是的。 术语Jamstack ，原本程式化的JAMstack，是由该公司创造Netlify作为促进他们的一种方式“的所有功能于一身的平台，为现代自动化网络工程”。 Jamstack背后的原理并不是真正新颖的，因为Web组件和API已经存在了很长时间。
But in very much the same way the term Ajax (asynchronous JavaScript and XML) was coined by another company back in the day — Adaptive Path — and even though the XMLHttpRequest (XHR) API that made Ajax possible also existed for some time, both Ajax and JAMstack were a refreshing revamp of ideas with legitimate uses that were quickly adopted by the community. The hype is well-deserved: this way of working has been a revelation for many developers around the world.
但是，术语Ajax (异步JavaScript和XML)是由另一家公司在当初创造的，即Adaptive Path ，并且几乎一样，尽管使Ajax成为可能的XMLHttpRequest (XHR)API也存在了一段时间，但两个Ajax都存在JAMstack和JAMstack是对合法使用的想法的全新更新 ，并很快被社区采用。 炒作是当之无愧的：这种工作方式已为世界各地的许多开发人员所启示。
静态网站？ (Static sites?)
“Static sites” are the antithesis of “dynamic websites”, right? So how to provide rich and dynamic interaction with just plain HTML files? Well, JavaScript.
“静态网站”是“动态网站”的对立，对吗？ 那么，如何仅使用纯HTML文件提供丰富而动态的交互呢？ 好吧，JavaScript。
JavaScript has evolved a lot since the first browser wars, having consolidated itself as a general-purpose programming language with the advent of Node.js, and with libraries like React, Angular and Vue.js. The possibilities for designing high-grade user interfaces (UI) are endless.
自从第一次浏览器大战以来， JavaScript已经有了长足的发展 ，随着Node.js的到来以及React ， Angular和Vue.js之类的库的加入，JavaScript自身已成为通用编程语言。 设计高级用户界面(UI)的可能性是无限的。
Of course, JavaScript isn’t a silver bullet. You most probably won’t be doing data analysis or AI with it. But for web development, there’s hardly anything that you can’t do with an API that you can consume with JavaScript methods, as chances are that somebody already created a microservice for it.
当然，JavaScript并非灵丹妙药。 您很可能不会使用它进行数据分析或AI。 但是对于Web开发而言，使用JavaScript方法可以使用的API几乎没有什么可以做的，因为有人已经为此创建了微服务。
And if, on top of that, you could “encapsulate” all of that process with markup into a reusable component — which you could pretty much drop-in whenever you need that specific functionality — you could potentially save hours of work every time.
而且，如果最重要的是，您可以将所有带有标记的过程“ 封装 ”到一个可重用的组件中(每当您需要特定功能时就可以直接使用该组件)，则可以每次节省大量的工作时间。
That’s the J·A·M stack right there: JavaScript, APIs, markup.
那就是J·A·M堆栈：JavaScript，API，标记。
解耦，无头，微服务，无服务器…对不起，什么？ (Decoupled, Headless, Microservices, Serverless… Sorry, What?)
All of these are hot topics in web development, and they’re all closely related but not quite the same. You’ll hear these terms a lot, so let’s clarify some terminology right form the start.
所有这些都是Web开发中的热门话题，它们都是密切相关的，但并不完全相同。 您会经常听到这些术语，因此让我们从一开始就阐明一些术语。
耦合vs.解耦vs.无头 (Coupled vs. Decoupled vs. Headless)
COUPLED is when the content of a website is created, managed, and stored on the site’s back end, where the database lies (such as the WordPress admin). This content is then pulled from the back end and represented in the browser through a front-end interface (such as a WordPress template). In a way, a “coupled” application is the traditional “full-stack” with the back-end and front-end being different sides of the same app.
COUPLED是在网站的后端(数据库位于其中)创建，管理和存储网站内容时(例如WordPress管理员)。 然后从后端提取此内容，并通过前端界面(例如WordPress模板)在浏览器中表示该内容。 在某种程度上， “耦合”应用程序是传统的“全堆栈”，后端和前端是同一应用程序的不同侧。
In contrast, DECOUPLED is when the back end and the front end are managed separately — meaning that the database and management tools will be on one server, and the front-end somewhere else. Naturally, there needs to be a medium by which both are connected, which is normally an API. What’s more, since the back-end now is effectively separated from the front end, there could be, in fact, several front ends in different locations! (Think of different storefronts using the same engine, such as Shopify.)
相比之下， DECOUPLED则是分别管理后端和前端的时间-意味着数据库和管理工具将位于一台服务器上，而前端将位于其他服务器上 。 自然地，需要一种将两者都连接起来的媒介，通常是一种API。 更重要的是，由于现在后端已与前端有效分离，因此实际上可能在不同位置有多个前端！ (请考虑使用同一引擎的不同店面，例如Shopify。)
In a nutshell, HEADLESS software simply doesn’t have a front-end or a presentation layer. A headless CMS, for example, is one that could generate static content and push it anywhere: a mobile app, an Internet of Things device, a static website. Admittedly, this is also a “decoupled” situation, but here you might not even need an API. Think of a WordPress engine that exported its posts to be served as static HTML files: that’s headless. In fact, you’re on a page that was generated in exactly this way right now.
简而言之， HEADLESS软件根本没有前端或表示层 。 例如， 无头CMS是一种可以生成静态内容并将其推送到任何地方的CMS ：移动应用程序，物联网设备，静态网站。 诚然，这也是一种“分离”的情况，但是在这里您甚至可能不需要API。 考虑一下一个WordPress引擎，该引擎将其帖子导出为静态HTML文件：这是没有头的。 实际上，您现在所处的页面正是以这种方式生成的 。
整体式(紧密耦合)与微服务(松散耦合) (Monolithic (Tightly Coupled) vs. Microservices (Loosely Coupled))
Put simply, MONOLITHIC could be defined as software that’s built in one piece. Examples might include a mobile app, most applications that you can install on your computer, and web apps such as WordPress. These apps can still have internal “modules” or “components”, but we say these are tightly coupled because they’re an indispensable part of the application, without which the application wouldn’t work.
简而言之，可以将MONOLITHIC定义为一件内置的软件 。 示例可能包括移动应用程序，可以在计算机上安装的大多数应用程序以及WordPress等网络应用程序。 这些应用程序仍可以具有内部“模块”或“组件”，但是我们说它们紧密相连，因为它们是应用程序必不可少的一部分，没有它们，该应用程序将无法工作。
On the other hand, LOOSELY COUPLED software components work more like plugins that can be removed or replaced, and maybe the functionality will change but the core of the application will still work. This principle enables the “outsource” of functionality through third-party APIs — often called “microservices” — as they provide secondary features (image resizing, login, storing) that aren’t in and of themselves an indispensable part of the application.
另一方面， 松散耦合的软件组件的工作方式更像可以删除或替换的插件，也许功能会发生变化，但应用程序的核心仍将起作用。 该原则通过第三方API(通常称为“微服务”)实现了功能的“外包”，因为它们提供了辅助功能(图像大小调整，登录，存储)，这些功能本身并不是应用程序必不可少的部分。
无服务器与传统计算 (Serverless vs. Traditional Computing)
Admittedly, “serverless” is something of a misnomer. Whichever computing venture you’re in, there are going to be servers involved. But the way in which you access and manage the severs can be radically different.
不可否认，“ 无服务器 ”是一个误称。 无论您从事哪种计算业务，都将涉及服务器。 但是，访问和管理服务器的方式可能完全不同。
In the TRADITIONAL MODEL, you may have an actual physical server (sometimes referred as a bare metal), or a virtual private server where resources are allocated for you — among other users — on a physical server. The resources are limited and, whether you use the 100% of them or not, you’re paying for them as if you do.
在TRADITIONAL MODEL中 ，您可能在物理服务器上拥有一台实际的物理服务器(有时称为裸机 )或一台虚拟专用服务器 ，在其中为其他用户分配了资源。 资源是有限的，无论您是否使用其中的100％，您都在为它们付费。
In the SERVERLESS MODEL there’s a huge pool of resources offered by many servers all connected between each other. You can just pull what you need when you need it, and scale (up and down) on demand. You can’t really pinpoint any physical server as yours — all you know is that the resources are there regardless of where they come from.
在无服务器模型中 ，许多服务器之间相互连接，提供了巨大的资源池。 您可以在需要时拉出所需的东西，然后按需缩放(放大和缩小)。 您无法真正确定任何物理服务器作为您的物理服务器-您所知道的就是资源在那里，无论它们来自何处。
| Traditional model | Serverless model |
|---|---|
| Physical servers with limited resources | A pool of unlimited resources |
| Prone to malfunctions (i.e. hard disk failure) | More reliable architecture* |
| Limited scalability | Unlimited scalability |
| Pay for all, including idle services | Pay for what you use (pay as–you–go) |
| Straightforward use | Need to learn implementation |
| 传统模式 | 无服务器模式 |
|---|---|
| 资源有限的物理服务器 | 无限资源池 |
| 容易出现故障(即硬盘故障) | 更可靠的架构* |
| 扩展性有限 | 无限的可扩展性 |
| 支付所有费用，包括闲置服务 | 按使用量付费(即付即用) |
| 直接使用 | 需要学习实施 |
-
*Notice that hard disks, CPUs and memory chip failures will still happen. But since resources are assigned transparently, you won’t even notice when hardware breaks and gets replaced.
-
*请注意，硬盘，CPU和内存芯片故障仍然会发生。 但是由于资源是透明分配的，因此您甚至在硬件发生故障并被更换时都不会注意到。
Jamstack的实际示例 (Practical Examples of the Jamstack)
That was a lot to take in, especially if you’re new to these ideas. So, let’s take a theory break and see some practical real-life Jamstack uses.
这要花很多钱，特别是如果您不熟悉这些想法。 因此，让我们进行理论上的突破，看看在现实生活中Jamstack的实际用途。
案例研究1：将WordPress转换为静态网站以使速度提高10倍 (Case Study 1: Turning WordPress into a static site for a 10x gain in speed)
If static is the way to go, then what better than taking a dynamic WordPress (WP) blog and making it into a static one? By doing so, we’ll reduce page load speed and latency by at least one factor, highly enhance security, and improve our SEO while at it.
如果要采用静态方法，那么与动态WordPress(WP)博客变成静态博客相比，还有什么更好的选择呢？ 这样，我们将网页加载速度和延迟降低至少一个因素，高度增强安全性，并同时改善我们的SEO。
简而言之，该过程 (The process, in a nutshell)
- Use a static site generator (SSG) to create posts and pages out of WP but in static format (text, Markdown, HTML). 使用静态网站生成器(SSG)从WP中创建帖子和页面，但使用静态格式(文本，Markdown，HTML)。
- Synchronize the static content with a repository on GitHub, GitLab or Bitbucket. 将静态内容与GitHub，GitLab或Bitbucket上的存储库同步。
- Automate a deployment pipeline so that every time there’s a change in the repository, changes go live instantly to a global CDN. 使部署管道自动化，以便每次存储库发生更改时，更改都会立即生效到全局CDN。
- Relax and enjoy free hosting for secure and fast websites with automated deployments. ???? 放松并享受免费托管，可通过自动部署安全快速地访问网站。 ????
但是关于… (But what about…)
Of course, this generates a lot of questions:
当然，这会产生很多问题：
- What about the admin? 管理员呢？
- What about the categories and the RSS feed? 类别和RSS提要如何？
- How do I manage content now? 我现在如何管理内容？
- How about the comments sections, and the newsletter? 评论部分和新闻通讯如何？
At this point, you could kiss WP Admin goodbye, as from now on you’ll be generating content with a SSG. In fact, SSGs such as Jekyll are specifically designed for building blogs, and SSGs like Gatsby.js already come with all batteries included.
此时，您可以与WP Admin告别，因为从现在开始，您将使用SSG生成内容。 实际上，诸如Jekyll之类的SSG都是专门为构建博客而设计的，而诸如Gatsby.js之类的 SSG已经包含了所有电池。
Managing content (such as modifying existing posts) is where a headless CMS comes to the rescue. For comments and newsletters, aren’t you already using an external API for those, such as Disqus and Mailchimp?
管理内容(例如修改现有帖子)是无忧的CMS抢救的地方。 对于评论和新闻通讯，您是否已经使用外部API(例如，Disqus和Mailchimp)？
您实际上是如何做到的？ (How do you actually do it?)
We can’t cover the ins and outs of SSGs and headless CMSs here, but stay tuned for a future instalment of this series. We’ll present a step-by-step guide to migrating a WordPress site.
我们无法在此介绍SSG和无头CMS的来龙去脉，但请继续关注本系列的后续文章。 我们将提供有关迁移WordPress网站的分步指南。
案例研究2：使用自动管道免费托管静态网站 (Case Study 2: Hosting static sites for free with an automated pipeline)
“Free” is something you’ll hear a lot in the Jamstack community — and thankfully, it’s not free as in you still have to tell us your credit card number free.
“免费”是您在Jamstack社区中经常听到的东西-幸运的是，它不是免费的，因为您仍然必须告诉我们您的信用卡号是免费的。
简而言之，该过程 (The process, in a nutshell)
In this case, we’ll take our static site (for example, the blog we migrated in Case Study 1) and put it online:
在这种情况下，我们将使用我们的静态站点(例如，在案例研究1中迁移的博客)并使其在线：
- Set a GitHub, GitLab or Bitbucket repository. 设置GitHub，GitLab或Bitbucket存储库。
-
Deploy to Netlify, GitLab Pages, or GitHub Pages.
At that point, every change on the repository will automatically trigger a new deployment (via webhooks), which could very elegantly be rolled back, should a problem occur.
届时，存储库上的所有更改都会自动触发一个新的部署(通过webhooks )，如果发生问题，可以很轻松地将其回滚。
公司为什么免费这样做？ (Why do companies do this for free?)
The overhead of dropping HTML files onto an already-deployed CDN is minimal. Remember, there’s no actual computing involved, no PHP rendering. Unless you host a massively popular site that eats up a lot of bandwidth, companies don’t mind giving out some hosting. And doing so can be good publicity for them.
将HTML文件拖放到已部署的CDN上的开销很小。 记住，没有涉及任何实际的计算，也没有PHP渲染。 除非您托管一个占用大量带宽的受欢迎网站，否则公司不会介意提供一些托管服务。 这样做可以很好地宣传他们。
By giving away lots of freebies, companies also lock you in. By the time you need a premium service (and if your business grows, you will), you’re already with them. That’s only fair — and besides, at that point you were already going to need to either develop an ad-hoc solution to your problem or pay for a service anyway.
通过赠送大量免费赠品，公司也将您锁定。当您需要优质服务时(如果您的业务不断增长，您将会)，您已经在他们那里了。 这仅是公平的，而且，到那时，您已经需要开发针对您的问题的临时解决方案或为服务付费。
您实际上是如何做到的？ (How do you actually do it?)
Both cases, Netlify or GitHub/GitLab, are very straightforward and require minimal effort. (Nevertheless, we’ll cover the process in detail in a coming article.)
两种情况，Netlify或GitHub / GitLab，都非常简单明了，并且需要最少的精力。 (尽管如此，我们将在下一篇文章中详细介绍该过程。)
Jamstack与全栈开发相比如何 (How the Jamstack Compares to Full-stack Development)
Let’s see how this novel approach compares to a LAMP or MEAN stack:
让我们看看如何将这种新颖的方法与LAMP或MEAN堆栈进行比较：
| LAMP/MEAN stack | Jamstack |
|---|---|
| Web servers running sites | Global deployments to CDNs |
| FTP/SSH uploads, server restarts | Automated pipelines |
| Pages rendered at runtime | Pages pre-rendered for speed |
| Monolithic apps (e.g. WordPress) | APIs and microservices (front/back end decoupled) |
| Full-stack (front- and back-end languages) | A single stack (“JavaScript everywhere”) |
| LAMP / MEAN堆栈 | 果酱堆 |
|---|---|
| 运行站点的Web服务器 | CDN的全球部署 |
| FTP / SSH上传，服务器重新启动 | 自动化管道 |
| 在运行时呈现的页面 | 预渲染页面以提高速度 |
| 单片应用程序(例如WordPress) | API和微服务(前端/后端分离) |
| 全栈(前端和后端语言) | 一个堆栈(“ JavaScript无处不在”) |
Jamstack还可以做什么？ (What Else Can You Do with the Jamstack?)
Hopefully at this point you understand the benefits of making your site. But perhaps you’re still skeptical about how to do the most basic things without back-end processing, such as user login and managing or storing dynamic content without a relational database (RDBMS).
希望在这一点上，您了解制作站点的好处。 但是，也许您仍然对如何在没有后端处理的情况下执行最基本的事情持怀疑态度，例如用户登录以及在没有关系数据库(RDBMS)的情况下管理或存储动态内容。
Here are a few more examples of things you can do with the Jamstack:
这里是您可以使用Jamstack进行操作的更多示例：
- implementing a serverless database with a static site 用静态站点实现无服务器数据库
- identity as a service (IDaaS): stateless authentication 身份即服务(IDaaS)：无状态身份验证
- headless content management systems 无头内容管理系统
- using serverless functions in static sites 在静态站点中使用无服务器功能
- management of multi-purpose forms 多用途表格管理
- handle multi-platform notifications 处理多平台通知
- headless shopping carts 无头购物车
- reactive search React搜索
结论 (Conclusion)
It’s inevitable that things evolve, especially in IT. Before it was the LAMP stack and then it was the MEAN stack. Now it’s the Jamstack, and in five to ten years it’s going to be something else. It’s best to embrace these changes and make them ours!
事情发展是不可避免的，尤其是在IT领域。 在它之前是LAMP堆栈，然后是MEAN堆栈。 现在是Jamstack，在五到十年内还会有其他事情。 最好接受这些变化并使它们成为我们的变化！
Learning new ways of doing things can sound like a hassle, but it can also reinvigorate your excitement for development. You may discover you spend less time maintaining servers and worrying about security issues. You may find that development takes less effort, and your clients are happier. And you may even become more competitive (and able to ask for a raise) as result. ????
学习新的做事方式听起来很麻烦，但也可以激发您对发展的热情。 您可能会发现花费在维护服务器上的时间减少了，并减少了安全性问题。 您可能会发现开发所需的精力更少，并且您的客户更快乐。 结果，您甚至可能变得更具竞争力(并能够要求加薪)。 ????
Jamstack基金会 (Jamstack Foundations)
Keep an eye out for more articles on this topic. While we’ve covered Jamstack over the years, it has become a discipline and practice of its own. We’ll bring you the tutorials you need to become a Jamstack pro, and update our index here on this page. You can also stay up-to-date with our RSS feed or on social media.
请关注有关此主题的更多文章。 尽管多年来我们已经介绍了Jamstack，但它已成为一门学科和实践。 我们将为您提供成为Jamstack专业人士所需的教程，并在此页面上更新索引。 您还可以通过我们的RSS feed或在社交 媒体上保持最新 。
Jamstack基础知识 (Jamstack Fundamentals)
-
Introduction to the Jamstack: Build Secure, High-Performance Sites
-
How to Host Static Sites for Free with an Automated Pipeline
And a whole lot more in the works.
还有更多工作要做。