前言
一周很快，又到周末了。今日前端早讀課文章由 @Marthers 翻譯分享，由公號：奇舞精選授權。
正文從這開始～～
1、簡介
前端是否厭倦了新趨勢，並尋求穩定？
過去兩年挺不容易的，在全球範圍內引發了許多變化。自從我們的生活逐漸 "搬到了線上"，IT 行業也順勢參與了數字轉型。前端開發也在從技術探索再到落地實踐等各個方面發生了很多變化。因此，我們儘可能的將前端 2020 年和 2022 年的數據並排呈現，以便更好地進行比較。
最著名的前端開發笑話 「新的一天，新的框架」 似乎已經過時了。當然，新的框架和庫確實出現了，但在某些領域，朝着潮流創新的競賽慢慢讓位於成熟和穩定。
1.1 本文數據來源
3703 份有效填寫的調查問卷
125 個國家的數據
19 位前端領域的專家
1.2 調查問卷分布
共計 3703 份問卷，其他: 84 份，其中問卷分布如下:
北美: 807 份
南美: 252 份
歐洲: 1918 份
非洲: 98 份
亞洲: 465 份
澳洲: 79 份
除此之外，我們還邀請了 19 位當代前沿專家分享他們對調查結果的看法和評論。他們的見解不僅是知識的事實來源，還將為您提供不同前端開發主題的思考素材。再次向我們的每一位評論員致謝 —— 沒有你的知識和經驗，這份報告就不會如此精彩。向他們表達一些感激之情！
我們也鼓勵您積極參與結果分析！如果我們對前端人員有所了解的話，那就是每個人都有自己的意見，很少把它們留給自己 —— 這很好，因為它推動了整個行業的發展。每個圖表和表格都有一個 「共享」 按鈕，以防您想與朋友開始討論或只共享報告的一個特定數據點。
最後，向所有 3703 名填寫該調查的前端人員表示衷心的感謝 —— 沒有你，就沒有報告！
二、 開發者和工作條件2.1 對於軟件工程來說，過去幾年最大的變化是遠程辦公
" 高達 56% 的受訪者表示遠程工作，其中只有 5% 在辦公室工作。大規模遠程工作的概念如此新穎，以至於 2020 年的調查甚至沒有測量這個數據點。
今年的一個大問題是，完整的遠程工作將繼續存在，還是我們將看到混合工作更受歡迎。大多數工程師顯然更喜歡遠程工作 —— 不需要通勤，很少有人在肩膀上敲打分散注意力。然而，分享信息和複製辦公室內已經存在的自發討論仍然是一個挑戰。" --- Gergely Orosz
2.2 你現在工作的形式是什麼？
遠程辦公: 59.7%
公司辦公: 5%
混合辦公: 35.3%
2.3 做前端開發的不僅僅是前端工程師
今年，一些從事前端開發的人在 「其他」 選項中共享的職位包括：
一個訓練營的學生剛剛開始學習前端
一位自學成才的開發者在一所非技術大學學習，他愛上了 frontend
有時將代碼推向生產的產品經理
技術大牛，不時幫助前端團隊
前端開發架構師
設計系統總監
一個也會編碼的設計師
平面設計師和開發者
全乾工程師：一個人開發一切，包括前端開發
這應該不足為奇：但它總是很好地提醒我們，前端是一個非常容易上手的技術領域，即使在沒有太多前端背景的情況下，這種情況很常見。
2.4 你從事前端工作的時間有多久？
超過 5 年: 28.4%
超過 10 年: 24.1%
超過 3 年: 22.9%
超過 1 年: 18.9%
不足 1 年: 5.7%
2.5 開發者技術水平
中級: 28.9%
高級: 28.6%
技術經理: 19.6%
初級: 13.1%
技術負責人: 4.6%
首席技術官: 2.9%
其他: 2.3%
2.6 在更大的前端團隊中工作變得越來越普遍
27% 的受訪者表示在擁有 50 多名前端工程師的公司工作。同時，30% 的開發者分享了 5 個或更少的前端開發者在他們公司的工作方式。50% 的受訪者在擁有 10 名或以上前端工程師的公司工作。
這個統計數據顯示了一個有趣的二元性。在擁有大量前端團隊的公司工作的前端工程師幾乎與在少數人團隊或單獨工作的公司一樣多。
這些公司的開發經驗和期望相差很大。大公司在前端平台團隊的同時，還將更重視開發人員體驗。輔導也更常見。在較小的地方，每個開發人員的責任更大，獲得反饋的選項更少。
作為一名前端工程師，我建議隨着時間的推移，在這兩種環境中工作，以最大限度地學習。
50% 的前端工程師在擁有 10 名或以上前端開發人員的公司工作，27% 的工程師在擁有 50 名或以上前端開發人員的公司工作，這一統計數據也可能是團隊為大型前端團隊構建工具的有趣提示。這些地方似乎越來越多。
2.7 公司規模
大於 501 人: 30.1%
51~200 人: 20.4%
11~50 人: 19.9%
2~10 人: 10.5%
201~500 人: 10.2%
僅此 1 人 (個人公司 / 自由職業者): 8.8%
2.8 公司前端人數
少於 5 人: 29.2%
10~50 人: 23.7%
5~10 人: 19.9%
多於 100 人: 18.2%
50~100 人: 9%
2.9 本次調查問卷很少有非技術占主導地位的公司的人員參與填寫
只有 18% 的填寫調查的人說他們在非技術占主導地位的公司工作。82% 的人認為自己在軟件開發公司、開發機構或者技術占據主導地位的公司工作。很難說這項調查是否涉及到在更傳統的公司工作的人，或者是否真的有更多的工程師在軟件作為業務核心的地方工作。
無論如何，值得記住的是，調查結果絕大多數來自技術型公司。
2.10 以下哪項最能描述貴公司？
軟件開發公司 / 開發機構: 41.6%
技術占主導地位: 41.2%
非技術占主導地位: 12.3%
其他: 2.9%
政府部門: 1.9%
三、 框架
#####3.1 開發人員在選擇框架時都會考慮到如何做到良好的實踐和落地
"對我來說，2022 年結果的故事是框架的興起。開發人員似乎越來越希望元框架能夠更快、更有信心地工作。調查顯示，受訪者越來越可能關注以下最佳實踐（例如性能和最終用戶體驗），這完全解釋了這種向元框架發展的趨勢。"-- Sébastien Chopin (NuxtLabs 首席執行官兼 Nuxt 作者)
3.2 在過去的一年裡，您使用並喜歡以下哪些框架？
React: 76.2%
Next.js: 43.1%
Vue: 28.9%
Angular: 22%
Svelte: 16.9%
Gatsby: 11.6%
Nuxt.js 9.4%
Remix: 8.8%
Ember.js: 4.5%
其他: 4.3%
Backbone.js: 1.9%
3.3 在過去的一年裡，您使用過的框架中，哪些是您不喜歡的？
Angular: 51%
React: 25%
Gatsby: 17.7%
Vue: 17%
Backbone.js: 11.3%
Ember.js: 9.4%
Next.js: 8.3%
Svelte: 4.6%
Nuxt.js 4.1%
其他: 2.8%
Remix: 2.5%
3.4 無障礙性
無障礙性是今年受訪者的一個主要關注點，63% 的人預測在未來幾年內它將越來越受歡迎。框架往往提供不同的方法來解決這個問題，其中有一些值得注意的例子，包括 Next/Nuxt Image、HTML validator 和 WebHint。Chrome Aurora 團隊正在與 Angular、Next 和 Nuxt 等元框架合作，以確保實現這些最佳實踐。我預測，在未來幾年，我們可能會看到所有這些主要框架的持續改進。
組件驅動開發也受到大多數開發人員的歡迎，考慮到 React、Vue、Svelte 甚至 Web 組件的流行，這一點很有意義（如今年的獨立成功案例 ——Wordle）。
漸進式 Web 應用程序 (PWA) 也越來越流行，開發人員熱衷於使用相同的核心代碼庫充分利用跨平台開發。我們還看到像開放網絡倡導組織 (Open Web Advocacy, 簡稱 OWA) 這樣的組織推動蘋果擁抱開放網絡。這絕對是一個值得效仿的空間。
無頭 CMS (headless CMS) 也在進步，採用率更高，並更多地集成到框架中。對於我來說，Nuxt 3 已經發布了新的 Prismic、Strapi、Sanity、Storyblock 和 Directus 模塊，可以零配置或者極少需要額外的配置即可使用。
3.5 您希望在未來學習以下哪些框架？
Svelte: 49.2%
Remix: 36.2%
Next.js: 33.5%
Vue: 28.1%
React: 16.2%
Nuxt.js 13%
Gatsby: 10.5%
Angular: 8%
Ember.js: 3.2%
其他: 2.7%
Backbone.js: 1.3%
我還注意到另一個趨勢，這是沒有明確提到這項調查。邊緣渲染最初由 CloudFlare 及其 worker 平台驅動。調查中的大多數部署目標都發布或實現了自己的 serverless 或 edge functions，這並不是偶然的，用戶很快就會採用這些功能。Nuxt 3、Remix 或 Sveltekit 等框架正朝着這個方向發展，直接在 CDN 級別實現按需渲染。隨着服務器呈現的應用程序在減少延遲和降低成本方面的相應收益，我預測這將成為 2023 年的一個重點。
四、庫4.1 Redux&Lodash–廣泛使用，喜歡還是… 不喜歡？
"無論您如何看待 Redux 和 Lodash，前端開發人員（自願或不自願）肯定會使用它們。在喜歡和不喜歡的解決方案中，他們都名列前三，這讓我想知道，為什麼人們會使用他們不喜歡的解決方案。我有幾個理論。"-- Andrzej Wysoczański (Software House 前端負責人)
4.2 在過去的一年裡，您使用的並喜歡的庫有哪些？
Axios: 61.5%
Lodash: 46.6%
Redux: 37.3%
Date-FNS: 34.6%
Moment: 31.9%
Apollo: 26%
RxJS: 23.5%
其他: 8%
Ramda: 7.3%
Relay: 2.1%
根據我的經驗，Redux 被軟件公司及其客戶廣泛使用，因為它適用於需要複雜狀態管理的大型項目。然而，Redux 的入門門檻相當高。如果開發人員從頭開始學習 Redux，並且這對他們來說是全新的，那麼他們最初可能並不喜歡它。但是，他們必須學習，也要學習，因為近 20% 的受訪者希望在未來掌握 Redux，儘管這很難。或者，人們可能意識到，為了在前端開發中獲得一份好工作，有 Redux 經驗對他們的簡歷很有好處。
就 Lodash 而言，我唯一合乎邏輯的解釋是，我們的受訪者必須在進入項目時就有這些解決方案，他們使用這些解決方案是出於必要，而不是出於樂趣。
4.3 在過去的一年裡，您使用過的庫中有哪些您最不喜歡？
Redux: 47.7%
Moment: 41%
Lodash: 19.8%
RxJS: 18.7%
Axios: 10.9%
Apollo: 10.4%
Ramda: 5.3%
Date-FNS: 3.9%
Relay: 3.7%
其他: 2.2%
似乎前端用戶從 Moment 走向 Date-FNS，這是一個好跡象。我感到震驚的是，超過 40% 的人仍然在他們的項目中使用 Moment，無論他們的情緒如何。這個庫已經失去了支持，甚至它的官方網站上也有創作者的留言說，如果你正在考慮使用 Moment，你可能應該尋找替代品。幸運的是，只有 5% 的受訪者渴望了解未來的 Moment，所以這個庫很可能走向衰落。
我們的 「志趣相投」 獎獲得者 Axios 以超過 60% 的得票率肯定進入了穩定階段。它在前端市場已經有很長一段時間了，人們對此很清楚，它更像是一種 「標準」 而不是一種 「趨勢」。難怪，它提供了體面的數據下載、通信以及與後端的一般合作。問題仍然是，Axios 的反對者寧願使用 GraphQL，還是他們真的不喜歡使用它？
4.4 你將來想學習以下哪一個庫？
Apollo: 41.3%
RxJS: 34.8%
Relay: 25.5%
Redux: 19.3%
Ramda: 13.9%
Date-FNS: 10.5%
Lodash: 8.9%
Axios: 8.8%
Moment: 5.2%
其他: 2.8%
在提到 GraphQL 之後，我需要在這裡對另外兩個解決方案進行評論。由於 Apollo 用於與 GraphQL 的無縫連接，我認為它在 「使用過的和喜歡過的」 類別中會高得多。當我注意到 40% 的開發者希望在未來學習 Apollo 時，我的希望又復活了（這使它保住了第一的位置）。這意味着 Apollo 的社區正在穩步增長，我預計在下一份報告中會有更多用戶使用這個庫。
Apollo，其小菜一碟般簡單的配置是最著名的一個在這裡，但也許不遠的將來，Relay 可能就是其最大的競爭。Relay 更複雜，僅適用於 React 和 React 本機應用程序，但 26% 的前端開發人員希望學習該庫。如果更多的人使用 Relay，更多的項目將實施它，這可能會導致更多的參與。我將繼續關注 GraphQL，因為我有一種感覺，這將是未來前端世界可以驚訝的地方。
4.5 設計系統 (沒有角逐出明顯的勝出者)
"設計系統空間非常零散。沒有一個單一的設計系統超過市場的 24%。這是 React 的一大不同之處，React 占據了大部分前端市場。我認為這可以簡單地解釋為，因為一家公司對設計系統的選擇大多是 「藝術」 的，沒有兩個人有完全相同的設計品味。"-- Olivier Tassinari (MUI 首席執行官兼 Material UI 聯合創始人)
4.6 在過去的一年裡，您最喜歡以下哪種設計系統？
個人自定義: 29.5%
Material UI/MUI: 23.5%
Tailwind UI: 22.5%
Bootstrap: 12.6%
其他: 5.1%
AntDesign: 4.4%
Vuetify: 2.3%
作為一個側面觀察，結果中可能存在偏差。調查提出 「Material UI/MUI」 作為一個預定義的答案，我很高興看到我們是領先的選擇，然而，對於大多數人來說，Material UI 是 Material 設計的同義詞。因此，不清楚受訪者是否從設計（設計系統）或代碼角度（Material 設計 React UI 庫 / 框架）選擇了這個答案。
4.7 樣式工具，SCSS 占據了半壁江山
」 哇哦，看看 SCSS，加油！如果一個孩子是在 SASS 被釋放的那天出生的，他們今天就已經到了可以學習開車的年紀了。這對於任何軟件工具來說都是難以置信的長壽，尤其是在前端開發工具快速發展的世界中。"
"近一半的受訪者表示，他們不僅使用 SASS，而且它是我的最愛，這讓我難以置信，我碰巧也同意，因為它也是我的最愛。"
"我認為它的語法相當不錯，儘管我傾向於只使用一些特性，比如嵌套和輕混合用法。從某種意義上說，Sass 現在面臨的是 CSS 本身。我想變量是開發人員使用 Sass 的主要原因之一，但是自定義屬性已經出現在 CSS 中，它們的支持無處不在，幾乎不需要 Sass 變量。即使嵌套在 CSS 標準機構中也有發展勢頭，因此我們將拭目以待，看看隨着時間的推移，它是否會削弱 Sass 的使用。" " 不過，Sass 是一個棘手的問題，它並不意味着你只會用到它。例如，PostCSS（僅在此處的 「其他」 部分中表示）在某種程度上設計為與 SASS 結合使用，至少是可選的。與 CSS 模塊類似。雖然您可以單獨使用 CSS 模塊，但您幾乎可以輕鬆地將其與 Sass 一起使用。這恰巧是我最喜歡的組合，它並不像下一個廣受歡迎的組合那樣特別深奧。js 提供了現成的支持此組合的功能。「-- Chris Coyier (CSS-Tricks 和 CodePen 的創始人)
4.8 在過去的一年裡，以下哪種樣式工具是您最喜歡的解決方案？
SCSS: 49.5%
Tailwind: 35%
Styled Components: 33.5%
CSS Modules: 24.9%
Emotion: 8.5%
Chakra: 7.3%
其他: 5%
Vanilla Extract: 3.5%
哇哦，沒想到 Styled Components 占據了這麼高的比例 ！這讓我印象深刻的是，問題只是關於樣式化工具的使用，但是 Styled Components 幾乎也意味着 React 的使用。因此，看到這一大占比，尤其是結合了 Emotion、Chakra 以及 Vanilla Extract，我想這一切主要是在 React 環境中看到的，這表明了 React 對於本次調查的參與者來說是多麼的占主導地位。這讓我想起了其他大型 JavaScript 框架。Vue 的人在哪裡？我沒有看到其他文件中特別提到的任何內容。他們可能只是… 沒想過？樣式是 Vue 單文件組件領域的內置功能。在 Vue 中，你不會做出很多樣式工具的決定，因為它只是為你準備的。這讓我又回到了 Sass。正如在 Next.js 中使用 Sass 很簡單一樣。所以你也可以在 Vue、Svelte 或 Astro 等更新的元框架中輕鬆使用 Sass。
如果知道 JavaScript 框架在這裡的使用情況有多嚴重，那麼看到常規的 ol 元素的 CSS 僅僅是一個小插曲就不足為奇了。一旦您處於組件驅動的架構中，擁有適用於這些組件的 CSS，並通過 JavaScript 的可用性提供額外的實用程序，人們利用這一點是有意義的，儘管性能不高。
Tailwind 的受歡迎程度在這裡也不足為奇。如果五年前你問我是否認為像 「Tailwind」 這樣的東西會流行起來，我會說 「不」，但我錯了。我從無數的開發人員那裡聽說，使用 HTML 類來設計樣式的想法只需要點擊一下就可以了。我有自己的懷疑。如果做得好，Tailwind 生成的 CSS 很可能會更小（對於像 CSS 這樣的阻塞資源來說尤為重要），人們似乎無論如何都喜歡將工具的選擇帶來一個很好的性能優勢。
很高興看到像 Vanilla Extract 這樣的工具試圖在樣式中提供各種現代開發人員人機工程學，並且非常專注於確保良好的性能是默認行為。這通常意味着 「提取 (extracting)」「vanilla」 CSS，如果你遵循他們的命名雙關語。
所有這些都讓我想到，如果我們能看到數據，比如說，流量排名前 5000 的網站的風格選擇，結果會是什麼。或者在互聯網上發布的最後 5000 個網站上做出的選擇。或者 GitHub 上開發最活躍的 5000 個網站。這會相似嗎？很難說他們是否會完全不同。但我想到了 WordPress 發布的令人震驚的數據：43% 的互聯網用戶。這並不是說你不能建立一個基於 JavaScript 框架的 WordPress 網站，有些人是這樣做的，但我相信這些 WordPress 網站中有一小部分是這樣的。那麼他們在做什麼？他們是 Sass 的大用戶嗎？難道你不認為它們中有相當一部分是普通的 CSS，僅僅因為 WordPress 本身不提供任何內置的樣式工具嗎？或者，這些站點中的大多數並不是真正由開發人員構建的，而只是自助部署？
看着樣式工具的選擇隨着時間的推移而改變，這當然很有趣。我唯一可以肯定的是，幾年後，這項調查會有驚喜，這在今天是不可能的。
4.9 開發工具
"很高興看到前端調查涵蓋了這個主題。您可以看到，越來越多的人開始對使用在線代碼編輯器進行一些工作感興趣，這非常令人興奮。雲開發只會繼續增長，我希望看到更多的程序員和公司將他們的開發環境從本地轉移到 Cloud。"-- Ives van Hoorne (CodeSandbox 聯合創始人)
4.10 在過去的一年裡，您使用了以下哪些開發工具？
Eslint: 83.4%
Prettier: 79.8%
Webpack: 76.8%
TSLint: 38.5%
Vite: 25%
Esbuild: 24.3%
Rollup: 22.1%
Parcel: 14%
個人自定義的工具: 7.9%
Bun: 0.7%
這項調查證實了我們在 CodeSandbox 上已經注意到的情況。我們看到越來越多的人將他們的開發轉移到網上，這也表明人們對雲開發的普遍興趣有所提高。僅在過去一年裡，人們就創建了超過 1200 萬個沙盒，占我們創建的沙盒總數的一半！
我對未來感到非常興奮，因為我相信 Cloud 將使軟件開發更容易訪問和協作。我很高興看到前端開發人員的回答反映了這種興趣。至於我在這裡對未來的期望，轉向雲開發可能比我們所有人想象的要快得多......
五、 Typescript5.1 Typescript 繼續使 Web 開發不再那麼令人沮喪
"TypeScript 並不打算停止每年獲得越來越多的公眾關注。如果你將 2022 年的答案與兩年前的答案進行比較，你會發現這一點。使用 TypeScript 的人數增加了 7 個百分點，已經達到了 84% ！"-- Marcin Gajda (Software House 的前端團隊經理)
5.2 去年，你用過 Typescript 嗎？
用過: 84.1%
沒用過: 15.9%
我們都可能同意，TypeScript 受到了開發人員的普遍歡迎，業界在未來幾年不會放棄這項技術。這是怎麼發生的？在網上討論中，人們經常稱讚 TypeScript 在錯誤發生之前就阻止了整個類別的錯誤。這反過來又使開發更快，應用程序更可靠。
我不想在這裡爭論，但既然你們問我是什麼讓這麼多開發人員喜歡 TypeScript，我想說的是，TS 讓 Web 開發方式比以前少了很多令人沮喪的地方。在經歷了太多年的 Web 開發之後，前端開發人員不想重複多次在代碼編輯器和瀏覽器之間來回切換的經歷，以猜測為什麼 「undefined is not a function」。畢竟，「雪是白的 (陳述一般事實)」 類型的錯誤通常是由諸如變量拼寫錯誤或參數放置錯誤之類的小錯誤引起的。
然後 TypeScript 拯救了我們，由微軟推出，並在所有主要 IDE 中得到支持。現在，在前端編寫代碼感覺更加受控和簡單。就我個人而言，我還喜歡在編寫使用數據結構的代碼之前設計數據結構，這為整個開發過程增添了額外的樂趣。
TypeScript 不僅試圖贏得開發者的心，而且還努力成為前端行業標準，不僅僅是針對 Angular 項目。可以肯定的是，完全不使用 TypeScript 的新商業項目已經很少了，在未來幾年裡，找到它們只會更加困難。如果你比較一下關於使用 TypeScript 和公司類型的問題，很明顯，科技行業在他們的軟件項目中自信地朝着 TypeScript 邁進。
以下為本次調查問卷中，各主要公司類型中對於 TS 的使用情況:
為了進一步支持我的說法，過去一年裡不接觸打字的人更多地在非科技公司或政府組織工作...... 這反過來又常常激怒前端開發人員，他們不喜歡使用過時的技術。結果表明：與技術相關的競爭和動態競爭分別約為 13% 和 20%。
5.3 展望 TS 的未來
就 TypeScript 的未來而言，預測發生了很大的變化。2020 年，前三大選擇之間勢均力敵。受訪者沒有給出 TypeScript 和 JavaScript 之間會發生什麼的明確答案。我敢打賭，兩年前，我們仍然不確定 TypeScript 只是一種暫時的時尚，還是會在我們心中停留更長時間。考慮到前端世界中不斷發生的事情，以及新解決方案出現的頻率，謹慎一點是完全可以理解的。
5.4 在您看來，以下哪種 TS 的場景最有可能發生？
本篇文章帶來了更明確的答案。大多數人認為 TypeScript 將成為 Web 開發的主要解決方案，占 43%。我知道，結果還沒有超過 50%，但如果你在玩 「誰想成為百萬富翁？」 這就是你在 「向觀眾提問」 這條生命線中的結果，你不會打賭嗎？我認為，當我們看到新出現的解決方案時，這種轉變背後的主要原因就變得很清楚了。用 TypeScript 本機編寫的庫顯著增加，大多數新的開發工具都支持現成的 TypeScript。
最後但並非最不重要的一點是，在 2022 年 3 月，當微軟宣布在 JavaScript 中引入 TypeScript 的類型語法時，我們可以實時觀察到 「JavaScript 將變成類似 TypeScript 的東西」 的答案變得比以往任何時候都更為現實。這意味着瀏覽器可以理解 TS，但不支持類型檢查。然而，目前，前端社區對該提案表示冷遇，我認為它沒有機會以當前形式被納入 ECMA 標準。這也意味着 JS 不會很快變形為 TS 的克隆體，但肯定有什麼東西在傳播。
六、 靜態站點生成器 (Static-site generators, 後面簡稱為 SSG)6.1 SSG 解決方案正在蓬勃發展
"越來越多的大公司不怕用 SSG 切換到無頭 CMS。Jamstack 解決方案不再是一種新的尖端技術，對他們來說似乎不再是實驗性的。"-- Samuel Snopko (Storyblock 的 DevRel 負責人)
6.2 在過去一年中，您使用了以下哪種 SSG？
我認為這項新的比賽將在接下來的幾個月裡帶來一些令人興奮的驚喜，而領先的三位是 Next.js，Gatsby，和 Nuxt.js 將需要發展得更快 ！
6.3 您最喜歡使用以下哪種 SSG？
最重要的功能將是增量生成，這將很快成為每個框架的必備功能。這使得小的更改更快、更容易–無需重新生成整個網站，只需更新需要更新的部分。此外，我預計本地化和個性化策略將大幅提升，這將成為框架的內部部分。
七、 宿主7.1 部署相關，大規模遷移到雲端是否意味着傳統託管的終結？
" 我注意到的第一件事是，越來越多的人正在從他們自己的服務器上的傳統主機轉移，結果與 2020 年相比下降了 8 個百分點。
就我個人而言，我認為這是註定要發生的，我不認為 "我們正在從傳統的託管" 是一件壞事。開發人員正在尋求優化他們的時間和生產力，如果他們能夠找到一種方法來完成初始設置所需的大部分工作，他們將採用這些服務。這就是我在這裡看到的情況，我認為從長遠來看，更多的人會離開它，但它會停止存在嗎？不，我不這麼認為，一些系統仍然需要非常定製的託管，他們可能無法從提供商那裡獲得，所以他們選擇自己製作。隨着雲託管的發展，遷移將繼續發生。"-- Gift Egwuenu (Cloudflare 開發者)
7.2 您最常將應用程序部署到哪裡？
另一種選擇是將前端託管轉移到雲提供商，綜合結果為 64% ！Amazon Web Services 仍然以 45% 的回覆率位居榜首，考慮到 AWS 是市場上最大的雲服務提供商之一，這並不奇怪。
GCP (Google Cloud Platform) 和 Azure 在今年的結果中處於次要地位，均落後於 AWS，各獲得約 13% 的選票。亞馬遜肯定在做一些不同的事情，我真的很想知道，如果 Azure 進一步推動 Azure 靜態 Web 應用，結果會有所不同嗎？
對於我來說，看到像 Vercel 和 Netlify 這樣的服務越來越多地被採用，這也很有趣。多年來，這些公司通過提供前沿的服務，包括為開發者提供免費服務，證明了他們在遊戲中處於領先地位。反過來，這為任何願意學習和使用其服務來主持其項目的人創造了一個較低的進入壁壘。
我還認為 Cloudflare Pages 應該為自己感到自豪。該解決方案對調查來說相對較新，但近 4% 的受訪者選擇 CP 作為他們的首選託管選項。此外，甚至 Cloudflare 的工作人員也經常出現在 「其他」 部分。這隻意味着前端開發人員願意嘗試並採用新的服務來部署 serverless 應用。
7.3 CI/CD。前端連接軟件開發生命周期的所有階段
大多數前端人員（80% 的受訪者回答 「是」）將 CI 添加到他們的工作流程中。我相信這是個好消息，它表明人們將軟件開發生命周期的所有階段都結合到了他們的工作流中。
7.4 您是否使用 CI？
使用: 79.7%
不使用: 20.3%
就個別解決方案而言，GitHub Actions 在本次調查中占據首位，2022 年超過 56%，而 2020 年為 35%。這表明，更多的前端用戶在日常生活中轉向 GitHub Actions。也許是因為 GitHub 在你想到 CI 的時候，極力主張將動作作為首選。加入微軟的影響可能是多年來微軟受到更多愛的原因之一。
從我個人的經驗來看，這些結果似乎確實是真的。我過去使用 Circle CI 和 Travis CI，但現在當我需要設置 CI 時，我默認使用 GitHub 操作。
7.5 在過去一年中，您使用了哪些 CI 解決方案？
我們還可以在 「其他」 選項中看到更多的解決方案（不包括在調查的集合答案中）。我說的是 Teamcity、Click Deploy、Envoyer 等服務是 CI 的首選選項。對我來說，這意味着有一些小眾提供商，你可能沒有聽說過，但他們仍然必須是穩定和可靠的，因為開發者確實選擇他們作為 CI 的首選。
八、 微前端8.1 微前端正在走向成熟
"如今，微前端受到了各種公司的歡迎。除其他外，Netflix、PayPal 和美國運通已在其一些系統中實施了這種架構方法。我相信這是微前端成熟的正確途徑。採用這種架構的大公司只會為社區提供更快的反饋循環，突出最佳實踐和反模式。"
"此外，業界對微前端的討論也越來越多。我所見過的幾乎每一次前端會議都至少有一位發言者、一個小組或一個案例研究報告。"-- Luca Mezzalira (AWS 首席解決方案架構師)
8.2 您是否在過去一年中使用過微前端相關的技術？
是: 24.6%
否: 75.4%
該社區開始擁有更成熟的工具，如用於客戶端渲染應用程序的 Single-SPA 或模塊聯邦 (Module Federation)，但我們仍在尋找服務端渲染的 「方法」。
8.3 您經常採用的微前端方案有哪些？
這裡仍有很長的路要走。例如，如何使用 "蠟燭版本"(canary release) 或藍綠部署在生產中部署微前端？或者，在使用 Preact 或 React 18 等服務端渲染框架時，如何利用部分混合？
儘管如此，與兩年前相比，微前端確實取得了進步，上述結果清楚地證明了這一點。我認為在未來幾年，更多的組織將採用這種方法，新的工具和模式將與前端社區共享並由其創建。我很高興看到微前端的未來。
九、 瀏覽器技術9.1 42% 的 WebSocket 是怎麼回事？我本以為會低於 5%
"從歷史上看，我（和我周圍的其他人）只需要這些 API 來獲得更高級、更像本地應用程序的體驗。因此，結果相當令人驚訝，尤其是 42% 的使用過 WebSocket 的受訪者，而我估計只有不到 5% 的人會真正有需求。我想知道選擇 WebAssembly 背後的主要動機是什麼：性能、使用 JavaScript 以外的其他語言的可能性、缺乏更好的選擇？"-- Jay Phelps (Netflix Web 平台，WebAssembly 社區小組成員和 RxJS 核心團隊成員)
9.2 在過去的一年裡，您使用了以下哪些瀏覽器技術？
我有一些理論。最簡單的解釋是，仍然存在某種抽樣錯誤，或者我和受訪者對問題的解釋不一定是內聯的。開發人員是否在生產網站上以商業層面使用了給定的技術，或者他們只是在 「無法工作」 的情況下對其進行了私人編碼實驗。這將有助於彌補我的期望和結果之間的差異。
然而，我認為真正的原因是多方面的，包括瀏覽器技術實際上比以往任何時候都更頻繁地使用。即使在不一定需要實時性的情況下也可以使用 WebSocket，像 Firebase 這樣的平台一如既往地流行。各種技術的相對使用順序似乎也是合理的。
File System Access API 仍然很新（例如 Firefox 尚不支持），因此我想知道有多少使用它的網站仍在倒退到舊版本。
我個人很欣賞 WebAssembly。它還很年輕，需要一些改進（尤其是瀏覽器中的客戶端），但 WebAssembly 是第一個真正標準化的字節碼。這對於許多用例來說都是一個吸引人的特性，不僅在瀏覽器中，而且在服務器端或離線應用程序中。由於 WebAssembly 是一個編譯目標，即虛擬化機器代碼，因此它不打算以與 x64 或 ARM 相同的方式手動編寫。這意味着大多數開發人員都是從其他高級語言編譯到 WebAssembly 的。
我很想知道這種語言的流行程度。我希望前三個是 C/C++、Rust 和 AssemblyScript，Golang 在 WebAssembly 社區中的流行程度也很高，因此值得一提。
從長遠來看，工具應該使 WebAssembly 成為大多數開發人員實際上不需要關心的實現細節。就像 iOS 開發人員通常不關心編譯到 ARM 一樣。但標準化和社區發展是一個緩慢的過程，所以我認為我們離這一現實還有十多年的距離。
十、 代碼管理10.1 瀏覽器編輯器正在興起。這只是遠程工作的結果嗎？10.2 桌面代碼編輯器
"Visual Studio Code 一直是桌面代碼編輯器的領導者。在前端開發方面，該團隊一直在做很多改進，以加快開發速度並跨平台工作。在 GitHub 上使用 VS 代碼的能力也擾亂了在線編輯器之戰，如果你不知道，可以在 GitHub 中按 「.」，它會為你在線啟動 VS 代碼。沒有人想到它也會進入這個市場，在發布 codespaces 之後。"--Santosh Yadav (谷歌開發者專家，Auth0 大使。)
10.3 你最喜歡的桌面代碼編輯器是什麼？
當涉及到桌面編輯器時，要想從 VS 代碼中奪走桂冠，需要付出一些認真的努力。開發人員一直在為 VS 代碼創建一些令人驚嘆的擴展，與其他代碼編輯器（如 WebStorm）相比，這些擴展具有明顯的優勢。
10.4 在線代碼編輯器
對於在線代碼編輯器，我對 StackBlitz 所做的事情感到非常驚訝。特別是引入 Web 容器，這樣就可以在瀏覽器中運行 NodeJs，這真是太棒了！CodeSandbox 多年來一直是領導者之一，但我可以看到 Stackblitz 的激烈競爭。你可以在 Web 容器之後使用 Stackblitz 做很多事情，尤其是在線運行 npm 腳本。我喜歡 CodeSandbox 上提供的部署選項–您只需點擊按鈕即可在 Netlify 或 Vercel 上部署，這很酷。
10.5 你最喜歡的在線代碼編輯器是什麼？
我認為在線代碼編輯器的使用只會從這裡增加。現在，許多公司正在走向完全遠程化，在線編輯是降低成本的一個很好的選擇。你不需要投資高端筆記本電腦 ——CodeSandbox 或 StackBlitz 可以幫你。每個開發人員都知道設置本地開發環境是多麼的痛苦，在線代碼編輯器可以在幾分鐘內完成。
10.6 版本控制提供程序
對於版本控制，GitHub 是許多開發人員的明確選擇，難怪 GitHub 多年來推出的各種功能令人驚訝：GitHub Action、CodeSpaces、VS Code Online、新的 GitHub 代碼搜索、人工智能副駕駛…… 我可以繼續講述所有這些功能如何使開發人員的日常生活更輕鬆。GitHub 操作消除了開源開發者對外部提供者的依賴，他們獲得了免費的開源構建。
10.7 你最喜歡的版本控制提供商是什麼？
Gitlab 和 Bitbucket 提供了許多企業迫切需要的自託管選項的優勢。但儘管如此，GitHub 是開源開發者的家園，它只會增長，The State of Octoverse [1] 就是一個明確的指標。
十一、 測試11.1 測試狀態中的驚喜：前端開發人員從未進行過更多的測試！
"我從事軟件測試工作已經近十年了，測試前端應用程序一直是質量保證人員最常用的活動之一。但是開發者呢？這份報告給我講了一個令人驚訝的故事。"--Dawid Dylowicz 公司（Onfido QA 負責人）
11.2 誰負責您的軟件開發團隊中的測試？
對我來說，最令人震驚的結果是測試責任從測試人員轉移到開發人員。事實證明，在 88% 的情況下，開發人員至少和 QAs 一樣參與測試。
11.3 在過去的一年裡，你自己進行過軟件測試嗎？
是: 80.5%
否: 19.5%
11.4 你會寫哪些類型的測試？
作為測試工程負責人，我的核心職責之一是鼓勵我們的質量保證人員成為教練，幫助開發人員參與測試。因此，我很高興看到我自己的經驗反映在調查中，顯示其他團隊在這方面也取得了巨大進展。
11.5 在過去一年中，您是否使用了以下測試工具？
作為《軟件測試周刊》的策展人，我注意到很多測試人員和開發人員選擇 JavaScript 進行測試。如今，更多的人寫像 Cypress 和 Playwright 這樣的工具，而不是 Selenium。因此，我並不驚訝地看到，近一半的受訪者已經試用過 Cypress。除了 Jest，它是最流行的測試工具。這表明人們對更健壯的測試越來越感興趣，並青睞具有良好 DX（開發人員體驗）和使用與開發相同語言的工具。
十二、 實踐12.1 您多久處理一次應用程序？
12.2 良好的實踐並非一刀切 —— 它們取決於您的團隊
"對於項目管理，69% 的受訪者使用 Scrum 或 Kanban。52% 的 Scrum 比 33% 的 Kanban 更常見，17% 的受訪者同時使用兩者。三分之二的前端開發人員在完成項目時使用這兩種方法之一。"
"受訪者沒有報告使用這兩種方法的公司大多是技術占據主導地位的公司，這與我在文章《大技術如何運作技術項目》中的發現以及令人好奇的 Scrum 的缺失不謀而合。"
"單元測試在前端工程師中很普遍，近 75% 的受訪者編寫了此類測試。整合測試和端到端測試也很常見，大約一半的受訪者編寫了這些測試。"--Gergely Orosz (The Pragmatic Engineer 創始人)
12.3 您在前端項目中使用了哪些方法 / 良好做法？
Code Review 在行業內很常見，80% 的受訪者表示他們遵循這種做法。有趣的是，Code Review 在哪裡不太可能成為一種實踐？對於那些不進行 Code Review 的人來說，前端工程團隊的規模與工程師是否進行 Code Review 之間有着密切的聯繫：
在大公司工作的工程師不進行 Code Review 的可能性最小。
在員工人數不超過 50 人的公司工作的工程師不進行 Code Review 的可能性是在大公司工作的工程師的兩倍或更多。
可以理解的是，一人公司更有可能進行 Code Review。
以上大部分內容都不足為奇：工程師越多，Code Review 不僅在發現問題方面，而且在更好地傳播知識方面帶來的價值就越大。
CI/CD 在行業內廣泛存在。令人好奇的是，大約有四分之一的工程師不使用 CI/CD。
"沒有編寫單元測試、沒有 CI/CD 和沒有進行 Code Review 是相互關聯的。"
這是本次調查中更有趣的發現之一。不做兩個編寫單元測試、CI/CD 和 Code Review 的工程師可能不會同時做這三個。
這一發現並不令人驚訝，因為這三種工具是相互關聯的。當沒有自動測試運行時，CI/CD 就沒有什麼意義了。大多數 Code Review 工具無縫集成到 CI/CD 工具中。
儘管如此，這一發現表明，通過引入單元測試和設置 CI/CD，Code Review 可能會隨之而來。或者，也許是另一種方式：希望進行 Code Review 的工程師傾向於編寫測試，並將建立 CI/CD。
以下是本次調查調查問卷參與者提出的工程實踐。如果您還沒有嘗試其他方法，不妨參考以下建議：
基於主幹分支開發
Feature 標誌和 Feature 切換
結對編程 (敏捷開發)
Lint
代碼規範
代碼文檔注釋
Stakeholder Map
設計衝刺 (Design sprints)
原型設計
語義化發布
「把任務快速完成」
視覺回歸測試
高效編程
12.4 搜索引擎優化仍然做的不好 - 還要多久才能重視並解決這個問題？
只有 10.4% 的前端開發者總是關注搜索引擎優化，16% 的開發者經常這樣做。然而，俗話說，細節決定成敗。這可能是因為許多受訪者創建了相對封閉的應用（儀錶板、管理或用戶面板、某種管理系統），其中搜索引擎優化不是最關鍵的部分。
12.5 你多久做一次應用程序的搜索引擎優化 (SEO)?
這就是我們最初的想法！然而，當我們看到剩下的選項並注意到以下幾點時，我們鬆了一口氣：
80.5% 的受訪者總是或經常關注應用程序的響應性。
73.5% 的應用程序（始終或經常）牢記其性能。
高達 88.1% 的人總是或經常關注用戶體驗。
這讓我們非常高興，因為所有這些元素（響應性、性能和用戶體驗）對搜索引擎優化也很重要。
隨着谷歌（和其他搜索引擎）在讓互聯網成為一個偉大的地方方面施加了很大的壓力，用戶處於其中心位置。因此，到 2022 年，搜索引擎優化的發展將遠遠超過一堆 HTML 標籤和內容。重要的是，它不僅適用於網站，也適用於 PWA 和移動應用程序！
12.6 對於前端的搜索引擎優化，什麼是重要的？
對於初學者來說，就是響應式。對於大多數在不同設備上工作的項目來說，這是必須的。最近，一些平台（推特）開始暗示 AMP（另一種搜索引擎優化友好的網絡應用移動版本）的退役。這使得 RWD 更加重要。
說到性能，這顯然包括很多方面。從搜索引擎優化的角度來看，這一切都是關於頁面速度的，不僅是速度，而且是頁面體驗。2020 年 11 月，谷歌增加了三個新的頁面體驗信號，構成了他們所說的 Core Web Vitals [2]。這些在 2021 6 月左右成為谷歌排名算法：最大內容繪製（LCP）、第一輸入延遲（FID）和累積布局偏移（CLS）。以上三項是每一個前端最應該重視的指標。
接下來是用戶體驗，這是一個非常廣泛的主題。然而，有一件事是肯定的：許多 SEO 已經使用 SXO 這個詞來表示典型的搜索引擎優化必須包括用戶體驗。
那麼，搜索體驗優化就是將谷歌（和其他搜索引擎）的技術優化與為用戶打造最佳網站相結合。在我們的應用程序生態系統中，有什麼能更好地以用戶期望、行為和成功的方式為用戶服務？
但這也有另一個非常顯著的優點。滿意的用戶 = 保留（或返回）用戶。
好的用戶體驗會影響轉化率，有助於留住用戶，或者讓他們想要獲得更多體驗。所有這些通常意味着更好的盈利，這是大多數商業應用程序的重心。
12.7 可訪問性
"首先，我將從一個非常重要的概念開始，即在收集產品需求的早期階段就應該考慮可訪問性，即您是否以 WCAG 2.1 AA 標準為目標，以及您的客戶是否期望這種實現。回到結果！"-- 迪利普・馬韋 (技術 Leader、教育家和技術文章寫作者)
12.8 您多長時間關注應用程序的可訪問性
令我震驚的是，「總是」 的答案竟然低至 17% ！這讓我認為，前端開發人員仍然是被動的，而不是積極主動地實現可訪問性。我在過去幾年中看到的是，工程師們現在正在積極地運行自動化可訪問性工具，作為其 CI/CD 的一部分，這無疑有助於提高工程師和軟件團隊其他關鍵成員的技能。
令我驚訝的是，可訪問性沒有用戶響應性、性能或用戶體驗那麼重要。我有一種感覺，由於公司產品的可訪問性差，現在可能會對公司產生法律影響，我預計這一情況在未來會改變。
與 2020 年開始關注可訪問性的問題相比，考慮到這些類別在某種程度上是 「是」 或 「否」，我覺得大多數前端程序員都覺得他們關心可訪問性，儘管在大多數情況下，這只是一個特別的審查或審計。
我希望在接下來的幾年裡，我們能看到像安全性一樣的可訪問性，我們將在設計軟件產品時考慮到可訪問性。與過去幾年中安全至關重要的情況類似。
12.9 用戶體驗、響應式和性能
"用戶體驗往往是出現問題後的最後考慮。因為功能是第一位的，所以適應這些功能的用戶界面是第二位的。因此，用戶體驗是一項昂貴而及時的工作，只有在大型專業公司才能做到。"
"雖然大多數受訪者仍然傾向於使用自己的設計系統和樣式，如 SCSS，但用戶體驗需求仍然往往落在程序員身上，他們只需要獲得一個功能來實現，而沒有任何故事板或用戶流示例。"-- 阿德里安・特瓦羅格 (「Development & Design」 創作者)
12.10 您多久關注應用程序響應式
12.11 您多久關注應用程序的性能
12.12 您關注用戶體驗的頻率如何？
測試在編碼中是如此重要的一項任務，以至於沒有人能夠再想象不經過適當測試就可以發布某些內容。這同樣適用於用戶體驗測試，在我的選擇中，它應該是寫入 CI/CD 工作流的另一個元素。
有時，由於 CTR 失敗，用戶無法完成任務。但是，由於沒有涉及用戶體驗測試，任務本身經常充滿了未被發現的錯誤。
代碼評審和設計評審也是如此。設計審查應始終考慮用戶對迭代的體驗，以提高編譯速度和代碼任務的性能，以及用戶任務（例如用戶通過 UI 完成操作的時間）。
我得出的結論是，現如今前端開發普遍給予了測試和審查更多的考慮，尤其是在代碼方面，這些同樣的考慮應該應用於用戶界面和用戶體驗，因為它們對任何系統的成功都至關重要。
12.13 開發人員體驗。到底是用戶的體驗最重要還是開發者的體驗最重要？
"事實上，我對其中的一些結果感到驚喜。有時，開發者的主要關注點似乎是他們自己的開發體驗，甚至以犧牲用戶體驗為代價。這些結果證明並非如此。開發者體驗是用戶體驗的前提，這就是它應該被優先考慮的方式。如果我們不為用戶體驗構建軟件，那麼我們到底在做什麼？"-- 肯特・C・多德 (Remix 聯合創始人)
12.14 你大概多久關注應用程序開發人員的體驗？
不幸的是，我對可訪問性的結果並不感到驚訝。至少我們對自己誠實。承認我們的缺點是改善缺點的第一步！希望這些結果能給我們敲響警鐘，提醒我們自己，對於大量用戶（包括使用輔助技術的用戶和未使用輔助技術的用戶）來說，可訪問性是用戶體驗的重要前提。事實上，對於一些用戶來說，他們對你開發的應用程序有任何 「體驗」 的唯一方式就是考慮可訪問性，因此我們最好採取相應的行動。
十三、 前端的未來
"前端可能正在進入穩定階段"-- 馬雷克・加伊達 (Software House CTO)
13.1 在你看來，這些趨勢 / 解決方案中，哪一種會越來越受歡迎，哪一種會在兩年後逐漸消失？
我注意到數字背後的第一件事是我最喜歡的 sin (x)/x 函數以及它與一般編程的關係。軟件開發仍處於早期階段，是一個行業中的幼兒。有一些布道者宣稱，所有的東西都已經在主題 X 中說過了，因此目前的方法應該被視為標準。一分鐘後，激烈的討論開始了，人們對這個話題有 180° 的看法，所以技術轉向了 Y。然後看，第一種方法又捲土重來，稍作調整，防止它過於極端，更接近 "中心"。之後，Y 的粉絲們調整他們的解決方案，使之更接近 "中心意見"。最終，兩個極端成為一個 "妥協"，變成了某種標準。這被稱為函數的退火（是的，我以前想當數學老師）。看看下面的圖表就知道了。
sin（x）/x 函數圖
看起來，前端開發正在進入一個更加 "穩定" 的階段。一些問題，如可訪問性或服務端渲染，已經不再需要討論了。然而，幾年前，前端還處於這條道路的起點，方法反映了完全不同的願景、想法和方法。IT 界的每個人都知道 "每天都有新的前端框架" 的笑話。但現在這種情況少了，我們正處於罪孽功能放緩和扁平化的階段，穩定的過程開始了。
讓我們來分析一下我從調查問卷的回覆中可以挑出的一些趨勢穩定的例子。
早在 2020 年，20% 的受訪者預測了微前端的死亡，而現在看來，它們並沒有消失。微前端仍然有邊界的意見，我想知道未來的妥協會是什麼樣子。Luca Mezzalira 在他的 "Micro-frontend" 一書中提出了 12 種不同的微前端概念，這意味着解決方案本身仍在內部結晶。我懷疑投票支持微前端的人與投票反對的人所支持的概念是不同的。
服務端渲染已經嚴重扁平化了（60% VS 5%），但我很驚訝這就是穩定軸的落腳點。歷史課：頁面最初是在後端渲染的。然後人們說："這有點傻，在互聯網上轉來轉去，慢得令人難以置信，應該由前端的瀏覽器來做"。然後反對派說。"好吧，但它還是有點慢，也許我們應該回到後端去？" 對方的回應是："嘿，在服務器上做一點，在客戶端做一點，怎麼樣？" 所以我們基本上又回到了原點，這正是 20 年前的工作方式。但是這一次，我們在多年的新經驗、實驗和內部改變後，能夠修改這個方法。
我的猜測是，領域驅動的設計是下一個目標。9 年前的想法是將業務邏輯與技術問題（路由、數據庫、性能、優化等）分開。有描述應用程序的代碼，也有工程和技術的代碼。每個人都為這個想法而瘋狂，但幾乎沒有人能夠做到這一點。概念是正確的，只是時機不對 -- 矛盾的是，我們沒有足夠成熟的技術來執行這項任務。目前，這種技術正在發生轉變，如果有人大聲支持 DDD，他們可能是對的。我們終於有了將理論轉化為實踐的工具，並將業務邏輯與技術部分真正分開。上面列表中的一些解決方案，如無頭 CMS，正是這樣做的。
13.2 開發者的權力和責任
早在史前時代，曾經有一個巨大的、統一的應用程序。當新的人進入項目時，他們被告知做什麼和怎麼做，沒有討論和選擇。
現在，如果你想在你的前端團隊中建立責任感和所有權，確保開發人員對技術和工程問題有很多發言權。這不是關於應用程序的功能，而是關於它將如何被構建。公司終於開始在事情的決策上給予開發者更多的自主權，而不是在他們頭上做重要的決定。不僅僅是因為前端程序員賺了很多錢。人們對自己的工作越有發言權，就越有主人翁意識。
在問題中包括的趨勢中，我們已經有了組件驅動開發，GraphQL，微前端和網絡組件 -- 所有的應用程序都以這樣的方式劃分，軟件團隊中的每個人都可以在自己的部分工作，而這些部分以後將被納入一個更大的整體。但每個開發人員都對自己的領域負責，並決定如何完成。這 100% 符合更廣泛的開發者自主權的概念，有無數的問題解決選項。
13.3 一個應用程序可以管理所有應用程序。移動端的下一步是什麼？
有人能夠想象一個沒有移動應用的企業，即使他們根本不需要它們。甚至我曾經和一個 "移動應用生成器" 的客戶合作，他們提供簡單的移動應用，包括商店的名稱、聯繫人、促銷活動、用戶粘性積分、營業時間和地址。做一個原生應用程序的唯一好處是，你可以點擊地址，谷歌地圖就會打開，並提供路線。這的確是突破性的。
然後，每個人都注意到，創建和維護移動 APP 實際上花費了一大筆錢。很多公司放棄了他們專門的移動團隊，因為人們發現，你所需要做的只是打開一個網站，為智能手機擴展。而不是從頭開始建立一個完整的應用程序！然後，根據趨勢穩定階段，我們經歷了："嗯，混合型怎麼樣？" - "不，回到原生"--"那麼，你畢竟是為了一個新的、混合化的混合體回來的？"......
我真的很感興趣，PWA 的趨勢是否會在這裡穩定下來，或者我們是否會有另一個鐘擺式的擺動。我有一種感覺，"一個應用程序政策" 將與我們保持更長的時間，但我不太確定 PWA 是否是我們能想出的解決這個問題的最佳方案。
只是提醒一下，谷歌提出了可信網絡活動（TWA），他們試圖將其作為一個標準。這仍然是一個新鮮的話題，但我感覺它很快就會枯萎，我沒有看到前端開發者、經理或公司對它有任何興趣。蘋果不太可能提出他們自己的 "標準"，因為他們有一個原始的 iOS，而且他們不得不承認原生應用已經成為過去。
13.4 未來可能出現的性能問題
我把最令人驚訝的留到最後，你看到 WebAssembly 的結果了嗎？在我看來，WebAssembly 確實是少數公司用來做優化的解決方案之一，像 Facebook 或 Gmail 這樣的巨頭。事實證明我完全錯了。46% 的受訪者預測 WebAssembly 會越來越受歡迎，老實說，我很震驚！我不知道該怎麼辦。也許我生活在這樣一個世界裡，當你使用了前端功能而碰壁時，WA 是最後的選擇，因為它很難寫，而且很難維護。當所有的方法都用過了，但解決方案還是太慢，那時候你才會去用 WebAssembly。
我們都知道，應用程序的性能需要不斷提高，壓力越來越大。現在的 Web 應用是否已經複雜到由於性能問題導致其他什麼都做不了嗎？這種對 WebAssembly 興趣的增加是否應該是普遍性能問題的第一個預兆嗎？我會在 2022 年持續關注這個話題。
參考資料
The State of Octoverse:https://octoverse.github.com/
Core Web Vitals:https://web.dev/vitals/
關於本文譯者：@Marthers譯文：https://mp.weixin.qq.com/s/WIPUiKo4HRRozB--XBZGpA作者：@Aleksandra Dąbrowska原文：https://tsh.io/state-of-frontend/
留言列表