JAMstack 基礎知識：什麼、什麼以及如何

我們喜歡在網絡上突破界限，所以我們決定嘗試一些新的東西。 您可能聽說過 JAMstack — 基於 JavaScript、API 和標記的新 Web 堆棧 — 但它對您的工作流程意味著什麼？它什麼時候對您的項目有意義？

作為 Smashing Membership 的一部分，我們每週都會舉辦一系列現場網絡研討會Smashing TV 。 不虛張聲勢——只是實用的、可操作的網絡研討會，由業內備受尊敬的從業者主持，並提供現場問答。 事實上，Smashing 的電視節目表看起來已經很密集了，而且它對 Smashing 會員以及錄音都是免費的——顯然。

我們懇請 Phil Hawksworth 舉辦一次網絡研討會，解釋 JAMStack 的實際含義和意義，以及它如何影響工具和前端架構。 時長一小時的網絡研討會現在也可用。 我們非常高興地歡迎 Phil 共同主持我們即將舉行的 SmashingConf Toronto（6 月 25 日至 26 日）並運行 JAMStack_conf London，我們也在今年 7 月 9 日至 10 日共同組織。 所以，讓我們開始吧！

Phil Hawksworth：太好了，好吧，那麼讓我們開始吧。 順便打個招呼，我的意思是我已經打過招呼了，斯科特給了我一個很好的介紹。 但是，是的，我目前在 Netlify 工作，我在那裡的開發人員體驗團隊工作。 我們希望有足夠的時間進行問答，但是，正如斯科特所說，如果你沒有機會在那裡提問，或者你寧願，你可以直接在 Twitter 上向我發送消息，所以我的 Twitter 句柄是我的名字，我是 Phil Hawksworth，所以任何時候你都可以在 Twitter 上向我提問有關 JAMstack 或任何內容的問題。

菲爾霍克斯沃斯：但我想從今天開始，稍微回顧一下這句話，這確實引起了我非常非常強烈的共鳴。 這是出色的 Aaron Schwartz 的一句話，他當然為知識共享和開放網絡做出了巨大貢獻，他早在 2002 年就在博客上寫了這篇文章，他說：“我關心不必保持暴躁AOL 服務器、Postgres 和 Oracle 安裝。” AOL 服務器，我不得不抬頭提醒自己當時是一個開源的 Web 服務器。

菲爾霍克斯沃斯：但這對我來說真的很強烈。 我也不想維護基礎設施來保持博客的活力，這就是他所說的。 這是在他自己的博客上的這篇博客文章，標題為“烘烤，不要油炸”。 他選擇了一個最近建立 CMS 的人開始使用的術語，並且他將這個關於烘焙的術語（烘焙，不要油炸）普及了； 他所說的是預渲染而不是按需渲染，因此提前烘焙內容，而不是在人們來請求時按需煎炸 - 將事情從請求時間轉移到構建時間。

Phil Hawksworth：當我們談論預渲染和渲染時，我們的意思是我們正在談論生成標記。 有時談論服務器渲染或同構渲染或許多此類流行術語時，我會感到有點不自在； 幾年前，我在阿姆斯特丹的 Frontiers Conference 會議上被叫到，當時我正在談論在服務器上渲染，有人對我說，“你的意思是生成 HTML？ 只是輸出 HTML 的東西？” 當然，這就是我的意思。

Phil Hawksworth：但所有這些都對簡化堆棧大有幫助。 當我們考慮我們為網站提供服務的堆棧時； 我一直在嘗試簡化事情，我非常熱衷於嘗試簡化堆棧。 這就是所謂的“JAMstack”的核心，我想試著解釋一下。 JAMstack 中的“JAM”代表 JavaScript、API 和標記。 但這還不足以真正幫助我們理解它的含義——這到底是什麼意思？

Phil Hawksworth：嗯，我想在接下來的半小時左右嘗試做的是，我想擴展這個定義，並更多地描述 JAMstack 是什麼。 我想談談 JAMstack 的影響和影響，並且，你知道，想想它能給我們帶來什麼，為什麼我們會選擇它。 在此過程中，我將嘗試提及一些有用的工具和服務，希望我會總結一些您可能想要深入研究的資源，並可能會提及一些讓您了解的第一步進行中。

Phil Hawksworth：所以，這就是接下來半小時的計劃。 但是，我想回到簡化堆棧的概念，因為希望以後加入或觀看此視頻的人，也許您對 JAMstack 有一個概念，或者也許這是一個全新的術語，你只是好奇。 但是，最終，已經有很多堆棧了。 您可以通過多種方式交付網站。 感覺就像我們已經構建不同類型的基礎架構已經很長時間了，無論是 LAMP 堆棧還是 MAMP 堆棧，還是——我不知道——MEAN 堆棧。 這裡的屏幕上漂浮著一堆。 它們有很多很多。

Phil Hawksworth：那麼，我們到底為什麼需要另一個呢？ 好吧，正如我所提到的，JAMstack 是 JavaScript/API/Markup，但如果我們嘗試更具描述性，JAMstack 旨在成為一種現代架構，以幫助使用 JavaScript/ 創建快速、安全的網站和動態應用程序/ API 和預渲染標記，在沒有 Web 服務器的情況下提供服務，最後一點是讓它與眾不同的東西，也許，讓它變得更有趣和不尋常。

Phil Hawksworth：這種在沒有 Web 服務器的情況下提供服務的概念，聽起來既神奇又荒謬，希望我們能弄清楚到底是什麼。 但是為了嘗試對此有所了解並更詳細地描述它，有時將其與我們可能認為的傳統堆棧或在網絡上提供服務的傳統方式進行比較是有用的。 所以，讓我們做一秒鐘。 也許，讓我們來看看一個請求在傳統堆棧中得到服務時的樣子。

Phil Hawksworth：因此，在這種情況下，我們讓某人打開 Web 瀏覽器並請求查看頁面。 也許該請求會命中 CDN，但更可能的是，它會命中我們託管的其他一些基礎設施——作為擁有該站點的人。 也許我們試圖確保它能夠在大量負載下擴展，因為我們顯然想要一個非常受歡迎和成功的場景。 因此，也許我們有一個負載均衡器，其中包含一些邏輯，它將為我們提供、配置和部署到的多個 Web 服務器之一提供該請求。 可能有許多這樣的服務器。

Phil Hawksworth：這些服務器會執行一些邏輯，說：“好的，這是我們的模板，我們需要用一些數據填充它。” 我們可能會從許多數據庫服務器中的一個獲取數據，這些服務器將執行一些邏輯來查找一些數據，將其返回到 Web 服務器，創建一個視圖，然後我們通過負載平衡器傳回該視圖。 也許，在此過程中，調用 CDN，在 CDN 中存儲一些資產，我應該澄清一下，CDN 是一個內容交付網絡，因此分佈在 Internet 周圍的機器網絡試圖盡可能接近地獲取請求服務給用戶並添加一些東西，比如緩存。

Phil Hawksworth：因此，我們可能會在其中存儲一些資產，並最終將視圖返回到瀏覽器中，返回到用戶的眼球中，然後用戶可以體驗我們構建的網站。 因此，顯然，這要么是對我們如何在傳統堆棧中服務請求的過度簡化，要么是非常籠統的看法。 如果我們將其與 JAMstack 進行比較，後者以稍微不同的方式為事物提供服務，這就是它的外觀。

Phil Hawksworth：所以，同樣的情況，我們從網絡瀏覽器開始。 我們正在請求查看該頁面，並且該頁面已經在 CDN 中。 它從那裡靜態地服務，所以它被返回給用戶，進入瀏覽器，我們就完成了。 因此，顯然，這是一個非常簡化的視圖，但您可以立即開始看到這裡在復雜性方面的差異。 就我們需要管理代碼的地方而言，深度編碼，所有這些不同的事情。 所以，對我來說，JAMstack 的核心屬性之一是它意味著您正在構建一個能夠直接從 CDN 甚至是靜態文件服務器提供服務的站點。 CDN 是我們可能想要用來處理負載的東西，但最終，這可以直接從任何類型的靜態文件服務器、靜態託管基礎設施中提供服務。

Phil Hawksworth： JAMstack 提供了一個降低複雜性的機會。 在接下來的半小時內，只需比較我們將多次返回的圖表的這兩個部分，您就會發現這是降低複雜性和降低風險的機會。 因此，這意味著我們可以開始享受為靜態資產提供服務的一些好處，稍後我將討論這些好處。 但是您可能會看著這個並想，“嗯，很好，但這不只是靜態網站的新名稱嗎？” 當我說“我們將靜態地為事物服務”時，這對我來說是合理的。

菲爾霍克斯沃斯：但我想回到那個。 我想多談一點，但首先，我想談談堆棧的概念，到底什麼是堆棧？ 我認為堆棧是技術層，它提供您的網站或應用程序。 而且我們不是在談論構建管道或開發過程，而是我們為站點提供服務的方式肯定會對我們的開發方式和部署方式等產生重大影響。

Phil Hawksworth：但是在這裡，我們談論的是技術堆棧，技術層，它們實際上將您的網站和應用程序交付給用戶。 所以，讓我們再做一個小比較。 讓我們先談談 LAMP 堆棧。

Phil Hawksworth：您可能還記得，LAMP 堆棧是由一個 apache Web 服務器組成的，用於執行 HCP 路由和靜態資產服務等工作。 PHP，用於一些預處理，非常漂亮的超文本處理； 應用邏輯，也許為模板構建視圖以及你有什麼。 並且可以通過我的 NISQL 訪問您的數據，然後 LINUX 是位於所有這些之下的操作系統，讓所有這些都保持呼吸。 我們可以在概念上將它包裝在一起作為這個 Web 服務器。 我們可能有很多這樣的服務器，有點像，坐在一起為網站提供服務。

Phil Hawksworth：這是對 LAMP 堆棧的一種傳統看法，如果我們將其與 JAMstack 進行比較，那麼，這裡有一個關鍵的變化。 在這裡，我們實際上是在向上移動，而不是考慮操作系統並考慮我們如何運行邏輯來交付網站。 在這裡，我們假設我們將靜態地為這些東西服務。 因此，我們正在執行 ACP 路由，並從靜態服務器提供資產。 這可以合理地做到。 多年來，我們在這方面做得非常好，構建了交付靜態網站或靜態資產的方法。

Phil Hawksworth：這可能是一個 CDN，我們稍後再談。 但我們感興趣的領域更多地發生在瀏覽器中。 所以，在這裡，這是我們的標記被傳遞和解析的地方。 這是 JavaScript 可以執行的地方，這發生在瀏覽器中。 在許多方面，瀏覽器已成為現代 Web 的運行時。 現在我們沒有在服務器基礎設施本身中擁有運行時，而是將它提升到一個級別，更接近用戶，並進入瀏覽器。

Phil Hawksworth：在訪問數據時，可能是通過外部 API 進行的，通過 JavaScript 調用這些外部 API 以獲取服務器訪問權限，或者我們可以將 API 視為瀏覽器 API，能夠與 JavaScript 交互在您的瀏覽器中提供功能。

Phil Hawksworth：無論哪種方式，這里關於 JAMstack 的關鍵在於，我們談論的是預渲染的東西：它們是靜態服務的，然後，它們可能會在瀏覽器中逐步增強以利用瀏覽器 API、JavaScript ，你有什麼。

Phil Hawksworth：所以，讓我們在這裡做一個小的並排比較。 再次，我只想重申 JAMstack 已經提升到瀏覽器的級別。 如果我們看到這張圖的兩側，左邊是 LAMP 堆棧，右邊是有效的 JAMstack，你甚至可能會認為，好吧，即使我們使用 LAMP 堆棧構建東西，我們仍然輸出標記。 我們仍在輸出 JavaScript。 我們可能仍在訪問 API。 因此，在許多方面，JAMstack 幾乎就像我們之前構建的一個子集。

Phil Hawksworth：我曾經有時將 JAMstack 稱為可靠堆棧，因為它保證了我們交付站點所需的一組工具和技術。 但是，無論哪種方式，它都是一種非常簡化的網站交付方式，在某種程度上，它消除了在請求時在服務器上執行和執行邏輯的需求。

Phil Hawksworth：所以，這可以做很多事情。 這可以，有點，簡化部署，我會不時回電到這個圖。 如果我們考慮如何部署我們的代碼和我們的網站，對於每一次部署，從第一次部署，到整個開發生命週期，一直到網站的生命週期。 在傳統堆棧上，我們可能不得不更改該圖表上每個框的邏輯和內容。

Phil Hawksworth：然而，在 JAMstack 中，當我們談論部署時，我們談論的是把東西送到 CDN，把東西送到靜態服務器，這就是部署所需要的。 構建，運行構建的邏輯類型——可以在任何地方運行。 這不需要在託管 Web 服務器的同一環境中運行。 事實上，它沒有！ 它啟動了 JAMstack 的密鑰。 我們將在請求時發生的事情（為這些靜態資產提供服務）與構建時發生的事情分開，這可以是您運行構建然後運行到部署的邏輯。

Phil Hawksworth：所以，這種脫鉤是一件關鍵的事情，我稍後會談到這一點。 我們非常擅長提供靜態文件，將內容髮送到 CDN 或將內容髮送到文件系統（文件服務器）是我們在過去幾年中看到巨大進步的地方。 現在有很多工具和流程可以幫助我們很好地做到這一點。 僅僅舉出一些可以很好地為靜態資產提供服務並提供工作流以使您的構建適應該環境的服務，它們通常是您可能想像的大型雲基礎設施提供商，如 Azure、AWS 和谷歌云。

菲爾霍克斯沃斯：但是，還有其他人。 所以，右邊最上面的是一項名為 Surge 的服務，它已經存在了幾年。 它允許您在構建環境中運行命令並將資產部署到其託管環境。 Netlify，下一個，是我工作的地方，我們做同樣的事情，但我們也有不同的自動化。 我可以再去一次。 底部是另一個靜態託管環境站點，稱為 Now。

Phil Hawksworth：所以，有很多不同的選項可以做到這一點，所有這些空間都提供了不同的工具來盡快訪問 CDN。 盡可能以最無縫的方式部署您的網站。 他們都有一些共同點，他們都建立在本地運行的原則之上。 我經常將靜態站點生成器視為我們可能在構建中運行的東西，當我們運行它時，它會獲取內容和模板之類的東西，也許還有來自不同服務的數據，它會輸出可以靜態服務的東西。

Phil Hawksworth：我們可以在靜態服務器中本地預覽。 在任何本地開發環境中都可以簡單地執行一些操作，然後將其部署到託管環境，理想情況下，部署到 CDN 以便獲得某種程度的擴展。 所以，有了這樣的基礎，我想解決一個關於 JAMstack 站點的常見誤解。 並且我將其公開為將 JAMstack 站點描述為 JavaScript、API 和標記，這對我沒有任何好處。 因為普遍的誤解是每個 JAMstack 站點都必須是 JavaScript 和 API 以及標記，但是我們忽略了這種事情是我們不必使用所有這三個 - 其中每一個都是， 可選的。 我們可以根據需要使用盡可能多或盡可能少的這些。 就像 LAMP 堆棧站點不一定需要訪問數據庫一樣。 現在，我過去在 Linux 機器上構建了由 apache 服務器提供服務的東西，並且我一直在使用 PHP，但我沒有訪問過數據庫，也不會開始重命名堆棧必然為此。

Phil Hawksworth：所以，如果我們考慮一下什麼是 JAMstack 站點，那麼它可能是一堆不同的東西。 它可能是用靜態站點生成器構建的，比如 Jekyll，從 YAML 文件中提取內容來構建一個沒有 JavaScript、根本不使用 API 的站點，我們在 GitHub Pages 之類的東西上提供它。 或者，那將是一個 JAMstack 站點。 或者，也許我們正在使用靜態站點生成器，例如 Gatsby，它是在 Jekyll 的 Ruby 環境中，現在這是構建在 React 生態系統中的 JavaScript 靜態站點生成器。

Phil Hawksworth：這可能會再次提取內容，它正在組織 Markdown 文件。 它可能會通過調用 API、GraphQL 的 API 來豐富這一點。 它可能在瀏覽器中做一些事情，比如在瀏覽器中對填充模板進行 JavaScript 水合。 它可能會在 Amazon S3 上提供服務。 那是一個 JAMStack 網站嗎？ 是的，絕對！

Phil Hawksworth：轉到另一個靜態站點生成器 Hugo，它是用 Go 構建的！ 同樣，我們可能會在 Markdown 文件中組織內容，使用 JavaScript 在瀏覽器中添加交互。 也許不調用任何外部 API，也許將其託管在 Google Cloud 上。 是 JAMstack 嗎？ 絕對地！ 你看，我在這裡建立一個主題。 使用像 Nuxt 這樣的東西，另一個靜態站點生成器，現在內置在 View 生態系統中。 也許這是從不同的相鄰文件中提取內容？ 同樣，我們可能在瀏覽器中使用 JavaScript 交互，可能調用 API 來做電子商務之類的事情，為它提供另一個靜態站點。 另一個像 Netlify 這樣的託管基礎設施，是 JAMstack 嗎？ 是的！

菲爾霍克斯沃斯：但我們甚至可能會去，你知道，去到規模的這一端，也。 想想我們自己構建的手工製作的、漸進式的 Web 應用程序、手工滾動的 JavaScript。 我們正在使用 webpack 打包它。 我們可能正在使用 JavaScript Web 令牌並調用 API 進行身份驗證，與不同的瀏覽器 API 交互，將其託管在 Azure 上。 是的，這也是 JAMstack！

Phil Hawksworth：而且，你知道，所有這些以及更多的東西都可以被認為是 JAMstack，因為它們都有一個共同的屬性，那就是它們都沒有由源服務器提供服務。 他們都不必在請求時訪問執行邏輯的服務器。 這些被用作靜態資產，然後通過 JavaScript 和對 API 的調用進行豐富。

Phil Hawksworth：所以，我再次重申，JAMstack 意味著它能夠直接從 CDN 提供服務。 所以，我只想指出一些影響和影響，因為我們為什麼要這樣做？ 嗯，第一個概念是關於安全性的，我們已經大大減少了攻擊的表面積，在這裡。 如果我們考慮（再次回到這個舊圖），我們可能不得不處理攻擊的地方，我們必須保護負載平衡器、網絡服務器、數據庫服務器等東西。 所有這些東西，我們必須確保不會被任何類型的攻擊，甚至是 CDN 所滲透。

Phil Hawksworth：如果我們能從這個謎題中取出越多的碎片，那麼可以攻擊的地方就越少，我們需要保護的地方就越少。 幾乎沒有可攻擊的活動部件確實非常有價值。 在 Netlify，我們運營著自己的 CDN，因此我們有幸能夠監控通過它的流量，即使在 Netlify 上託管的所有站點，您可能想像的所有 JAMstack 站點，它們都沒有在它們上面有一個 WordPress 管理頁面，因為它是完全解耦的。 沒有 WordPress 管理員，但我們看到了大量的流量，正在探索諸如 WP Admin 之類的東西，尋找進入的方法，尋找攻擊媒介。

Phil Hawksworth：我真的很喜歡 Kent C. Dodds 所做的一些事情。 不知道你是否熟悉 React 社區，你可能在過去遇到過 Kent C. Dodds。 他不使用 WordPress，但他仍然路由這個 URL，即 WPAdmin。 我認為他曾經將其路由到 YouTube 上的 Rick Roll 視頻。 他肯定一直在拖釣那些已經為此進行調查的人。 但是，關鍵是，通過以這種方式解耦事物，並且移動發生的事情，從請求時間發生的事情中構建時間，我們可以大大減少我們的曝光。 我們在請求時沒有活動部件。 移動部件在構建時都完全解耦。 可能，完全，好吧，必然在完全不同的基礎設施上。

Phil Hawksworth：當然，這也會對性能產生影響。 回到我們的老朋友這裡，當需要在這些不同的地方執行邏輯時，我們可能想要嘗試在堆棧中提高性能的地方。 這在傳統堆棧中經常發生的方式是，他們開始添加層，添加靜態層，以提高性能。 所以，換句話說，試著找到我們可以開始表現得好像它是靜態的方法。 不必在堆棧的每一層都執行該邏輯以加快速度。 因此，我們開始在整個基礎架構中引入諸如緩存之類的東西，以及我們可能會在 Web 服務器中發現這樣做的明顯地方，而不是執行該邏輯，我們希望在不執行該邏輯的情況下立即提供某些東西。

Phil Hawksworth：所以，這有點像邁向偽靜態的一步。 同樣在數據庫服務器中，我們希望將緩存層添加到 cache-com 查詢中。 即使在低餘額，整個CDN，你也可以認為是一個緩存。 但是在傳統堆棧上，我們需要弄清楚如何管理緩存，因為並非所有內容都會被緩存。 所以，這裡有一些邏輯。 需要動態填充的內容與可以緩存的內容。 而 JAMstack 模型，一切都被緩存了。 從部署完成的那一刻起，一切都被緩存了，因此我們可以完全不同地考慮它。

Phil Hawksworth：那麼，這也開始暗示擴展。 從規模上講，我說的是，我們如何處理大量流量？ 傳統堆棧將開始添加基礎設施以進行擴展。 所以，是的，緩存。 我們開始在我們的傳統堆棧中到位。 這會有所幫助——在一定程度上。 通常發生的情況是，為了處理大量流量，我們將開始擴展基礎設施並開始添加更多服務器、更多部件來處理這些請求，將這些東西計算在內並估計負載是一個很大的開銷，它可以對於任何從事技術架構的人來說都是一個令人頭疼的問題。 這當然是為了我，這就是為什麼我開始更傾向於使用 JAMstack 方法，我只知道一切都來自 CDN，默認情況下設計用於處理規模，以立即處理性能.

Phil Hawksworth：所以，我也想對開發人員的體驗表示讚賞，以及這可能產生的影響。 現在，開發人員體驗永遠不應被視為勝過用戶體驗的東西，但我相信良好的開發人員體驗可以減少摩擦，可以讓開發人員更好地建立良好的用戶體驗！

Phil Hawksworth：所以，當我們考慮開發人員的體驗生活在哪裡時，以及開發人員關注的領域在哪裡：嗯，在傳統堆棧中，我們可能需要考慮如何將代碼用於所有這些不同的基礎設施的一部分，以及它們如何一起發揮作用。 實際上，在 JAMstack 世界中，我們談論的是底部的這個框。 你知道，我們如何運行構建和它們，我們如何自動化部署以首先獲得服務？ 好消息是，在 JAMstack 模型中，您在該構建中做什麼完全取決於您。

Phil Hawksworth：這是一個定義明確的問題空間，因為最終，您正在嘗試構建可以直接從 CDN 提供服務的東西。 您想使用任何您喜歡的工具預渲染某些內容：無論是用 Ruby、Python、JavaScript、Go 或 PHP 構建的靜態站點生成器，您都可以自由選擇。 因此，這可以為您創造一個更好的工作環境。而且，它創造了一個讓開發人員真正信任的機會，因為 JAMstack 站點的一個真正屬性是它們可以更容易地作為不可變和原子部署服務。

Phil Hawksworth：我想暫時離開幻燈片，描述一下這意味著什麼，因為不可變部署和原子部署可以……（聽起來有點像營銷說話）但是我要做的是，我要跳進我的瀏覽器。 現在……實際上，我要回去一秒鐘。 讓我……就這樣吧。

菲爾霍克斯沃斯：我們來了。 這會更容易。 直接跳入頁面。 現在，斯科特，你會告訴我，斯科特，如果你看不到我的瀏覽器，我希望。 現在，假設每個人都可以看到我的瀏覽器。

斯科特：一切看起來都很好。

菲爾霍克斯沃斯：太好了！ 非常感謝！

Phil Hawksworth：所以，我在這裡做的是使用 Netlify 作為示例，作為服務的示例。 但是，這是一個可以靜態託管的站點共有的屬性。 因此，當我們談論不可變部署時，我們的意思是，每次部署代碼都必須觸及基礎設施的許多不同部分，並改變很多事情，這裡我們並沒有改變網站的狀態服務器。 我們正在為發生的每個部署創建一個全新的站點實例。 我們可以這樣做，因為該站點是靜態資產的集合。

Phil Hawksworth：在這裡，我正在查看我自己的網站上發生的部署。 我給你款待。 你來了，這就是它的樣子。 它只是一個博客，看起來並沒有什麼特別了不起或令人興奮的東西。 這是一個靜態生成的博客，但我在這裡所擁有的是曾經發生過的每一次部署，都會永久存在，因為它是從 CDN 提供的靜態資產的集合。 現在，我可以回到我的歷史可以帶我去的地方，去看看那個網站，因為它回到了……這是什麼時候？ 這是 2016 年 8 月。由於它是一組靜態資產，我們能夠在其自己的永久存在的 URL 上託管它，如果我什至願意，我可以決定進入並發布它部署。

Phil Hawksworth：所以，現在，任何正在查看我網站的人，如果我回到我的網站，如果我刷新該頁面，現在將直接從 CDN 提供之前存在的資產。 現在，我可以再次導航。 在這裡，你可以看到。 看，我一直在討論這個問題，我在 2016 年使用了這些可怕的術語，比如同構渲染和談論 JAMstack。所以，這就是現在在我的網站上提供的內容。 同樣，因為存在永遠存在的相互部署。 我要放上我自己的，有點，安心，我要——這是第一頁嗎？ 是的。 我將回到我的最新部署。 我將不得不再次關閉，讓我回到現實世界。 讓我確保這沒問題。

菲爾霍克斯沃斯：好的！ 偉大的！ 所以，那麼現在，這又回到了為我以前的版本或我的最新版本的網站提供服務。 我會跳回主題演講。 所以，這是可能的，因為事物是不可變的和原子的。 原子部分再次意味著部署是完全包含的。 因此，您永遠不會知道某些資產在 Web 服務器上可用，但其中一些不會。 只有當一切都在上下文中並且一切都在那裡完成時，我們才會將網站的服務切換到新版本。 同樣，如果您將事物構建為一個 JAMstack 站點，該站點直接從 CDN 作為一堆資產提供服務，那麼您可以更輕鬆地完成這種事情。

Phil Hawksworth：我注意到我的計時器在從主題演講來回後重置了，所以我想我還剩下六到七分鐘。 告訴我，斯科特，如果——

斯科特：所以，是的，我們還有十分鐘左右的時間。

菲爾霍克斯沃斯：十分鐘？ 好，精彩！

斯科特：不急。

菲爾霍克斯沃斯：謝謝，那應該很好！

Phil Hawksworth：所以，稍微換個角度談談 API 和服務（因為 API 是 JAMstack 的一部分），我們可能能夠使用的服務類型主要是 JAMstack。 你知道，我們可能正在使用我們內部構建的服務，或者我們可能正在使用購買的服務。 有許多不同的供應商可以為我們做事，那是因為那是他們的專長。 通過 API，我們可能會將內容管理系統中的內容作為服務提取出來，為此有很多不同的提供商，他們專門提供出色的內容管理體驗，然後通過 API 公開內容，所以你以前是能夠把他們拉進來。

Phil Hawksworth：同樣，您可以通過不同的方式為資產提供服務。 像 Cloudary 這樣的人在這方面做得很好，可以進行圖像優化，再次通過 API 將資產直接提供給您的站點。 或者電子商務呢？ 你知道，像 Stripe 或 Snipcart 這樣的地方可以為我們提供 API，這樣我們就不必自己構建這些服務，也不必陷入嘗試構建電子商務引擎所帶來的非常複雜的問題。 同樣，身份，來自使用 Oauth 的 Auth0 之類的人。 有很多可用的服務，我們可以通過 API 使用這些東西，無論是在瀏覽器中還是在構建時，或者有時是兩者的組合。

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. 謝謝，斯科特。

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. 大家好。 Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. 正確的？ It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth：我真的很喜歡，因為 JAMstack 這個詞可能真的會產生誤導，因為它試圖涵蓋很多不同的東西，而我試圖在這張幻燈片中多次敲擊它的重點是它可以是各種各樣的東西的。 它是如此廣泛，但關鍵是靜態預渲染和託管網站的核心。 我們很容易陷入關於它需要成為 React 站點的宗教戰爭。 它必須是一個 React 應用程序，才能成為一個 JAMstack 站點，或者它是一個 React 應用程序，所以它不能是 JAMstack。 但是，實際上，關鍵在於，無論您是否使用 JavaScript，無論您是否調用 API，如果您預渲染並將內容放入一個性能非常出色的靜態主機中，這就是 JAMstack 的核心。

維塔利：是的，絕對的。

Phil Hawksworth：我們很幸運，瀏覽器的功能越來越強大，瀏覽器本身的 API 也可以讓我們做更多的事情。 因此，這種方式進一步打開了大門，但這並不意味著我們作為 JAMstack 站點構建的所有內容都必須使用所有內容。 根據我們要交付的內容，我們應該開始選擇我們正在使用的工具來部署這些東西。

維塔利：當然。 我們這裡有多蘭。 多蘭，我想我知道，多蘭。 我有一種感覺，我認識多蘭。 他在問，“您是否希望無服務器從 [音頻不清晰 00:44:36] 開始傾向於與 JAMstack 無縫集成？ 在 JAM 中稱為 A。

Phil Hawksworth：這是一個很好的問題，因為我認為，無服務器功能是——它們與 JAMstack 站點配合得非常好，因為在很多方面，事實上，我想有人曾經問我 JAMstack 站點是否是無服務器的，所以我猶豫不決這個問題，因為無服務器是一個如此沉重的術語。 但是，在很多方面，它都很成功，因為我一遍又一遍地談論沒有源服務器。 沒有服務器基礎設施供您管理。 事實上，我曾經寫過一篇名為“Web Serverless”的博文，因為世界需要另一個流行詞，不是嗎？

Phil Hawksworth：真的，那是，是的，我們正在構建沒有服務器的東西。 我們不想管理這些服務器，而無服務器功能或作為服務的功能正好適合這一點。 因此，在您確實需要一個您想要向其發出請求的 API 的情況下，您直接從瀏覽器發出該請求實際上是不明智的。 因此，例如，如果您在該請求中有秘密或密鑰，您可能不希望這些請求（即信息）暴露在客戶端中。 但是我們當然可以代理這些事情，並且通常，傳統上，我們需要做的是啟動服務器，擁有一些有效地做的只是處理請求的基礎設施，為其添加安全身份驗證並將這些請求傳遞給，代理他們回來。

Phil Hawksworth：無服務器功能非常適合這一點。 他們絕對是理想的選擇。 所以，我有時會想到無服務器功能或服務功能，幾乎就像一個逃生艙，你只需要在服務器上進行一些邏輯，但你不想創建整個基礎架構。 你可以用它做越來越多的事情，並為開發工作流提供開發管道，因為作為服務的功能正在成熟。 JavaScript 開發人員能夠更容易地構建這些東西。 所以，是的，我真的認為這兩件事很好地結合在一起。

Vitaly：好的，這是一個非常全面的答案。 實際上，我最近參加了一個演講，一位來自亞馬遜的前端工程師正在談論他們正在使用的無服務器和 Lamda 功能——我幾乎走了。 他總是在談論 Docker、Kubernetes 和所有這些東西，Devox World，我坐在那裡想，“他是怎麼到那裡去的。 我不明白這是怎麼回事！” 我不知道發生了什麼事。

菲爾霍克斯沃斯：沒錯，但問題是，它曾經是……我是……我接受了我不了解那個世界的任何事情，但我沒有任何願望，因為那是一個完全不同的學科. 這種紀律仍然非常重要。 你知道，設計基礎設施的人——這仍然很關鍵。 但是，現在，我只是覺得我很受誘惑。 作為一個有前端開發背景的人，作為一名 JavaScript 開發人員，我更想在那個世界裡玩一玩，因為這些工具正在靠近我。

Phil Hawksworth：我更有可能使用其中的一些東西，並安全地交付東西，而不是僅僅作為我自己的實驗，這就是我曾經光彩照人的地方。 所以，感覺就像我們作為 Web 開發人員變得越來越強大，這讓我很興奮。

Vitaly：就像電力別動隊一樣，是吧？

Vitaly：不過，我確實想問你一件事，這實際上是我們已經討論過的事情，也許是一周前，但我還是想提出來，因為你在會議中提到的一件事是概念擁有每個部署的獨立實例，這真的很酷。 但是，問題是，如果您有一個大型任務，有數万頁，您真的不想每次都重新部署所有內容。 所以，基本上，如果你有，比如，如果你主要使用事物的靜態方面。 所以，我們有這個想法有一段時間了，我知道這實際上是你上次提出的。 原子部署的想法。

Vitaly：實際上，從字面上看，您在兩個不同版本的設置快照之間獲得了某種 div。 所以，如果你說，到處更改標題，那麼，當然，每個頁面都必須重新部署。 但是，如果您更改可能僅影響 1000 頁的組件（例如輪播），那麼重新部署 15000 頁將是有意義的。 但只有這 1000 個。那麼，我們能到達那裡嗎？ 在這一點上，這是一個神奇的想法，還是非常有形的東西？

Phil Hawksworth：我認為這可能是靜態站點生成器和這種模型的聖杯，因為當然，您已經確定了可能需要克服的最大障礙。 或者你碰到的最大的天花板。 那是具有許多、數万或數十萬或數百萬個 URL 的網站——構建可能會變得非常長的概念。 能夠根據代碼更改檢測哪些 URL 將發生更改是一項挑戰。 這不是不可克服的，但這是一個巨大的挑戰。 了解整個站點的依賴關係圖，然後智能地部署它——這真的很難做到。

Phil Hawksworth：因為正如您所提到的，組件更改可能會產生非常深遠的影響，但是您——總是很難知道它是如何工作的。 因此，有許多靜態站點生成器，這些項目為這一挑戰付出了一些努力，並試圖弄清楚它們如何進行部分重新生成和增量構建。 我很高興有一天可能會解決這個問題，但目前，這絕對是一個巨大的挑戰。 您可以開始做一些事情，例如嘗試在邏輯上共享您的站點，然後再次考慮類似於遷移問題。 好吧，我知道的這一部分在它的種類、它使用的一些資產或那裡存在的內容類型方面是獨立的，所以我可以單獨部署它們。

Phil Hawksworth：但這對我來說並不理想。 這並不是一個完美的場景。 作為概念驗證，我已經探索過的一種方法是思考你如何做事，比如智能地使用 404。 因此，例如，非常大的標誌（可能是新聞網站）的一個大用例是，當突發新聞故事發生時他們需要一個 URL 時，他們需要首先將其部署到那裡。 他們需要在那裡獲取一個 URL。 像 BBC 新聞這樣的東西，你會看到新聞報導會到達網站，然後隨著時間的推移，他們會逐漸添加到網站上，但首先到達那裡是關鍵。 因此，構建需要 10 分鐘、20 分鐘，無論它是什麼，這都可能是個問題。

Phil Hawksworth：但是，如果它們的內容是抽象的，並且可能曾經是從 API 調用的。 我提到了抽象的內容管理系統，比如 Contentful 或 Sanity 或其中的一堆。 任何具有內容 API 的內容都會更改將觸發構建的內容結構，我們將完成運行，但可能發生的另一件事是，如果您為此發布 URL，然後公開該 URL ，即使構建沒有運行，如果有人劫持了那個 URL，如果它的 404 上的第一站不是說“我們還沒有得到它”，而是直接點擊那個 API，那麼，你可以說, “嗯，構建尚未完成以填充它，但我可以在客戶端中完成。” 我可以直接訪問 API，獲取它，然後在客戶端中填充它。

維塔利：嗯，有趣。

Phil Hawksworth：所以，即使構建仍在進行中，您也可以開始填充這些東西。 然後，一旦構建完成，它當然不會遇到 404。你會點擊那個靜態運行的頁面。 所以，有技術和策略來解決它，但仍然是一個很長、漫無邊際的答案，我很抱歉，但我的結論是，是的，這是一個挑戰。 祈禱我們會得到更好的策略。

維塔利：是的，那太好了。 所以，我想知道，所以，在這一點上，我們真的不考慮內容交付方面的性能，而是構建速度方面的性能。 就像構建部署一樣。 所以，這也是我們一直在尋找的東西，現在也有相當長的時間。

維塔利：我還想問你一件事。 所以，這很有趣，就像你提到的這種技術。 你是怎麼知道這件事的？ 這只是人們傾向於在自己的博客上發布的內容，或者，它是某種媒體，還是有一個中央存儲庫，您可以在其中獲得某種案例工作室，JAMstack 如何 - 公司在卸載時如何移動，或未能遷移到果醬堆棧。

菲爾霍克斯沃斯：所以，目前這片景觀有點成熟。 我的意思是，其中一些例子，我認為，我處於一個非常幸運的位置，我在某個地方工作，我扮演的角色是我正在玩玩具，想出有趣的方式來使用它並開始嘗試跟他們。 所以，這些概念證明是我可以嘗試並嘗試解決這些挑戰的東西。 但是，我之前提到過，在紐約 JAMstack 會議上展示的一個案例研究，當然，像這樣的事件，我們開始看到最佳實踐或行業實踐和行業方法正在討論中的事件。 當然，我希望看到更多並進行更多案例研究，以進入 Smashing Magazines 等地方，以便我們可以更輕鬆地分享這些信息。

Phil Hawksworth：我認為，大公司和企業空間，正在逐漸採用 JAMstack，在不同的地方，以不同的方式，但世界仍然傾斜到那裡，所以我認為，每次公司採用它並分享他們的經驗，我們都可以從中學習。 但我真的很想看到越來越多的案例研究發表，這樣我們就可以特別了解如何克服這些挑戰。

Vitaly：好吧，那麼，也許只是我的最後一個問題，因為我總是喜歡閱讀問題。 所以，在 JAMstack 領域，如果你可以改變一些東西，也許除了部署之外，還有一些你非常想看到的東西。 還有什麼能讓你真正開心的事情嗎？ 那會讓你開心嗎？ 那會是什麼？ JAMstack 的願望清單上有什麼？

菲爾霍克斯沃斯：真是個問題。 我的意思是，如果我們不討論增量構建，那將是——

維塔利：我們做到了。 現在太晚了這張卡已經通過了。 我們需要別的東西。

菲爾霍克斯沃斯：所以——

Vitaly：我的意思是，就像在一個平台上，如果你看看後面的平台，就會發生很多令人興奮的事情。 我們有 Houdini，我們有 Web 組件，等等，因為你可以改變所有正確組件的整個格局。 另一方面，我們擁有 SS NGS 的所有神奇、奇特的世界，當然，顯然，我們也有單頁應用程序等等。 你最興奮的是什麼？

Phil Hawksworth：在這裡我會變得遲鈍，因為有很多東西正在發生，令人興奮，並且有很多新功能可以在瀏覽器中使用。 我真正感到興奮的是人們表現出克制（笑），正如我所說，回答很枯燥，但我喜歡看到在克制下完成的偉大處決，在深思熟慮的情況下——關於更廣泛的觀眾。 用最閃亮的新 JavaScript 庫或新的瀏覽器 API 構建真的很有趣，也很令人滿意，我不知道，瀏覽器中的划痕和嗅探功能是我們現在任何一天都迫切需要的。

Phil Hawksworth：但我真的很喜歡看到我知道會在很多很多地方發揮作用的東西。 它們將非常高效，將同情現有的瀏覽器——不僅僅是在那些擁有時髦玩具的 CEO 和 CTO 的辦公桌上，還有那些擁有低功率設備的人，或者他們我遇到了具有挑戰性的網絡條件和諸如此類的事情。 我喜歡看到有趣的體驗和豐富的體驗，以一種同情平台的方式提供，並且對更廣泛的受眾有同情心，因為我認為網絡比我們這些為它構建東西的開發人員更進一步. 看到以吸引更多人的方式完成有趣的事情，我感到很興奮。

Phil Hawksworth：這可能不是你必須的答案——

Vitaly：哦，這是一個不錯的結局。 太感謝了。 不，這很完美，確實如此。 好吧，我感覺一切都很順利！ 非常感謝您與我們在一起！ 我要分發給斯科特！

菲爾霍克斯沃斯：太好了！

Vitaly：我只是來玩問答的。 所以，非常感謝你，菲爾！ 我還在這裡，但斯科特，舞台是你的，現在！ 也許您可以與我們分享 Smashing TV 上接下來會發生什麼？

Scott：我會的，但首先，Phil，我迫不及待地想看看 Scratch-and-sniff API 的實現是如何工作的。 聽起來很有趣。 而且，Vitaly，JAMstackify 已經被佔用了。

Vitaly：（垂頭喪氣）上當了？！ 我們可以買嗎？

斯科特：不，它存在！

維塔利：嗯，為時已晚。 我總是遲到。

Phil Hawksworth：這本身就很令人興奮。

維塔利：這就是我一生的故事。 我總是遲到。

斯科特：接下來的成員，我相信，13 號星期四，我們有我的老爸，扎克·萊瑟曼，談論他最擅長談論的話題，那就是字體。 所以，他說的是字體實現的五個 Y。 然後，我也對我們在 19 日即將推出的一項非常感興趣，那就是使用 JavaScript 和 CSS 編輯視頻，與 Eva Faria 合作。 所以，請繼續關注這兩個。

斯科特：所以，下週四又是 Zach Leatherman，然後是 19 日，Eva 將討論用 JavaScript 和 CSS 編輯視頻。 所以，在那張紙條上，菲爾，我再也見不到你了，你還在嗎？

菲爾霍克斯沃斯：我來了！

斯科特：關於這一點，非常感謝大家！ 另外，多倫多附近有人嗎？ 或者任何曾經想訪問多倫多的人？ 我們將在 6 月底召開會議，但還有幾張票。 所以，也許我們會在那裡見到你們中的一些人。

維塔利：非常感謝你們，其他所有人！

Vitaly：哦，順便說一句，還有一件事！ 也許 Phil 提到了它，但我們還在 7 月在倫敦舉行了 JAMstack 會議。 所以，這也是需要注意的事情。 但我要退出並去拿我的沙拉！ 不確定你——

斯科特：好的，再見，大家！

Vitaly：好的，再見，大家。

這是一個包裝！

我們衷心感謝 Smashing 會員的持續和善意支持——我們迫不及待地想在未來舉辦更多網絡研討會。

此外，Phil 將在下週的 SmashingConf Toronto 2019 和 JAMstack_conf 上擔任主持人——我們也很樂意在那裡見到你！

如果您覺得這一系列採訪有用，請告訴我們，您希望我們採訪誰，或者您希望我們涵蓋哪些主題，我們會盡快處理。