摘自官方介绍，没有翻译（没必要，已经比较简单了，重要的就是进行每条的诠释了，后续。。。）
Entire Project on a CDN
Because JAMstack projects don’t rely on server-side code, they can be distributed
instead of living on a single server. Serving directly from a CDN unlocks speeds
and performance that can't be beat. The more of your app you can push to the edge,
the better the user experience
Everything Lives in Git
With a JAMstack project, anyone should be able to do a `git clone` , install any
needed dependencies with a standard procedure (like `npm install`), and be ready
to run the full project locally. No databases to clone, no complex installs. This
reduces contributor friction, and also simplifies staging and testing workflows.
Modern Build Tools
Take advantage of the world of modern build tools. It can be a jungle to get oriented
in and it's a fast moving space, but you'll want to be able to use tomorrow's web
standards today without waiting for tomorrow's browsers. And that currently means,
Babel, PostCSS, Webpack, and friends.
Automated Builds
Because JAMstack markup is prebuilt, content changes won’t go live until you run
another build. Automating this process will save you lots of headache. You can do
this yourself with webhooks, or use a publishing platform that includes the service
automatically.
Atomic Deploys
As JAMstack projects grow really large, new changes might require re-deploying hundreds
of files. Uploading these one at a time can cause inconsistent state while the process
completes. You can avoid this with a system that lets you do "atomic deploys," where no
changes go live until all changed files have been uploaded.
Instant Cache Invalidation
When the build-to-deploy cycle becomes a regular occurrence, you need to know that when
a deploy goes live, it really goes live. Eliminate any doubt by making sure your CDN can
handle instant cache purges.