2022年國內外前端發展態勢

語言: CN / TW / HK

本文翻譯者系奇舞團前端工程師

原文標題:State of Frontend 2022

原文作者:Aleksandra Dąbrowska

原文地址:https://tsh.io/state-of-frontend/

前端是否厭倦了新趨勢,並尋求穩定?

一、簡介

過去兩年挺不容易的,在全球範圍內引發了許多變化。自從我們的生活逐漸"搬到了線上",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將使軟體開發更容易訪問和協作。我很高興看到前端開發人員的回答反映了這種興趣。至於我在這裡對未來的期望,轉向雲開發可能比我們所有人想象的要快得多......

五、 Typescript

5.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的使用情況:

| 公司型別 | 未使用 | 採用TS | | ------------ | ------ | ------ | | 未提供型別 | 32.67% | 67.33% | | 政府組織 | 19.35% | 80.65% | | 非技術佔據主導地位的公司 | 19.21% | 80.79% | | 軟體公司 | 12.73% | 87.07% | | 技術佔據主導地位的公司 | 12.16% | 87.84% |

為了進一步支援我的說法,過去一年裡不接觸打字的人更多地在非科技公司或政府組織工作......這反過來又常常激怒前端開發人員,他們不喜歡使用過時的技術。結果表明:與技術相關的競爭和動態競爭分別約為13%和20%。

5.3 展望TS的未來

就TypeScript的未來而言,預測發生了很大的變化。2020年,前三大選擇之間勢均力敵。受訪者沒有給出TypeScript和JavaScript之間會發生什麼的明確答案。我敢打賭,兩年前,我們仍然不確定TypeScript只是一種暫時的時尚,還是會在我們心中停留更長時間。考慮到前端世界中不斷髮生的事情,以及新解決方案出現的頻率,謹慎一點是完全可以理解的。

5.4 在您看來,以下哪種TS的場景最有可能發生?

| 場景 | 投票率 | | -------------------------------- | ----- | | TypeScript將超越Javascript,成為新的前端標準 | 43% | | Javascript和TypeScript同樣受歡迎 | 27.6% | | JavaScript將變成類似Typescript的東西 | 16.6% | | JavaScript仍將是前端標準 | 11.8% | | 大家會將TS遺忘 | 1% |

本篇文章帶來了更明確的答案。大多數人認為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?

| SSG | 使用率 | | --------- | ----- | | Next.js | 43.6% | | 沒用到任何框架或庫 | 35% | | Gatsby | 22.7% | | Nuxt.js | 9.8% | | 其他 | 7.3% | | Hugo | 5.6% | | Vuepress | 3.6% |

我認為這項新的比賽將在接下來的幾個月裡帶來一些令人興奮的驚喜,而領先的三位是Next.js,Gatsby,和Nuxt.js將需要發展得更快

6.3 您最喜歡使用以下哪種SSG?

| SSG型別 | 得票率 | | --------- | ----- | | 沒用到任何框架或庫 | 37.7% | | Next.js | 36.9% | | Gatsby | 8.4% | | 其他 | 6% | | Nuxt.js | 5.8% | | Hugo | 2.4% | | Vuepress | 1.2% |

最重要的功能將是增量生成,這將很快成為每個框架的必備功能。這使得小的更改更快、更容易–無需重新生成整個網站,只需更新需要更新的部分。此外,我預計本地化和個性化策略將大幅提升,這將成為框架的內部部分。

七、 宿主

7.1 部署相關,大規模遷移到雲端是否意味著傳統託管的終結?

"我注意到的第一件事是,越來越多的人正在從他們自己的伺服器上的傳統主機轉移,結果與2020年相比下降了8個百分點。

就我個人而言,我認為這是註定要發生的,我不認為"我們正在從傳統的託管"是一件壞事。開發人員正在尋求優化他們的時間和生產力,如果他們能夠找到一種方法來完成初始設定所需的大部分工作,他們將採用這些服務。這就是我在這裡看到的情況,我認為從長遠來看,更多的人會離開它,但它會停止存在嗎?不,我不這麼認為,一些系統仍然需要非常定製的託管,他們可能無法從提供商那裡獲得,所以他們選擇自己製作。隨著雲託管的發展,遷移將繼續發生。"-- Gift Egwuenu(Cloudflare開發者)

7.2 您最常將應用程式部署到哪裡?

| 雲端選擇 | 得票率 | | ------------------- | ----- | | Amazon Web Services | 45% | | 個人機器 | 36.2% | | Vercel | 25.4% | | Netlify | 25.2% | | Google 雲平臺 | 13.6% | | Azure | 13.1% | | 其他 | 7% | | Cloudflare Pages | 3.6% |

另一種選擇是將前端託管轉移到雲提供商,綜合結果為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解決方案?

| 方案選擇 | 得票率 | | ---------------------- | ----- | | Github Actions | 56.5% | | Jenkins | 31.6% | | Gitlab CI | 30.7% | | Circle CI | 17% | | Azure DevOps/Pipelines | 16.5% | | Bitbucket Pipelines | 13.4% | | Travis CI | 8.3% | | 其他 | 7.9% |

我們還可以在“其他”選項中看到更多的解決方案(不包括在調查的集合答案中)。我說的是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 您經常採用的微前端方案有哪些?

| 方案選擇 | 得票率 | | -------------- | ----- | | Single-SPA | 35.9% | | Web Components | 24.3% | | 模組聯邦 | 22.5% | | 其他 | 12.4% | | Bit | 3.2% | | Systemjs | 1.8% |

這裡仍有很長的路要走。例如,如何使用"蠟燭版本"(canary release)或藍綠部署在生產中部署微前端?或者,在使用Preact或React 18等服務端渲染框架時,如何利用部分混合?

儘管如此,與兩年前相比,微前端確實取得了進步,上述結果清楚地證明了這一點。我認為在未來幾年,更多的組織將採用這種方法,新的工具和模式將與前端社群共享並由其建立。我很高興看到微前端的未來。

九、 瀏覽器技術

9.1 42%的WebSocket是怎麼回事?我本以為會低於5%

"從歷史上看,我(和我周圍的其他人)只需要這些API來獲得更高階、更像本地應用程式的體驗。因此,結果相當令人驚訝,尤其是42%的使用過WebSocket的受訪者,而我估計只有不到5%的人會真正有需求。我想知道選擇WebAssembly背後的主要動機是什麼:效能、使用JavaScript以外的其他語言的可能性、缺乏更好的選擇?"-- Jay Phelps(Netflix Web平臺,WebAssembly社群小組成員和RxJS核心團隊成員)

9.2 在過去的一年裡,您使用了以下哪些瀏覽器技術?

| Technology | 得票率 | | ---------------------- | ----- | | Websockets API | 42.1% | | Clipboard API | 35.6% | | Geolocation API | 31.1% | | 沒用任何 | 24.8% | | File System Access API | 21.5% | | Fullscreen API | 14.5% | | WebGL | 14% | | WebRTC API | 11.4% | | WebAssembly | 10.4% | | 其他 | 1.7% | | WebHID API | 0.4% |

我有一些理論。最簡單的解釋是,仍然存在某種抽樣錯誤,或者我和受訪者對問題的解釋不一定是內聯的。開發人員是否在生產網站上以商業層面使用了給定的技術,或者他們只是在“無法工作”的情況下對其進行了私人編碼實驗。這將有助於彌補我的期望和結果之間的差異。

然而,我認為真正的原因是多方面的,包括瀏覽器技術實際上比以往任何時候都更頻繁地使用。即使在不一定需要實時性的情況下也可以使用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 你最喜歡的桌面程式碼編輯器是什麼?

| IDE | 得票率 | | ------------------------ | ----- | | VS Code | 74.4% | | JetBrains IDE (WebStorm) | 18.8% | | Vim | 3.3% | | Sublime | 1.4% | | 其他 | 1.1% | | Atom | 1% | | Brackets | 0.1% |

當涉及到桌面編輯器時,要想從VS程式碼中奪走桂冠,需要付出一些認真的努力。開發人員一直在為VS程式碼建立一些令人驚歎的擴充套件,與其他程式碼編輯器(如WebStorm)相比,這些擴充套件具有明顯的優勢。

10.4 線上程式碼編輯器

對於線上程式碼編輯器,我對StackBlitz所做的事情感到非常驚訝。特別是引入Web容器,這樣就可以在瀏覽器中執行NodeJs,這真是太棒了!CodeSandbox多年來一直是領導者之一,但我可以看到Stackblitz的激烈競爭。你可以在Web容器之後使用Stackblitz做很多事情,尤其是線上執行npm指令碼。我喜歡CodeSandbox上提供的部署選項–您只需點選按鈕即可在Netlify或Vercel上部署,這很酷。

10.5 你最喜歡的線上程式碼編輯器是什麼?

| online IDE | 得票率 | | ----------- | ----- | | 沒有任何喜歡的 | 41.5% | | CodeSandbox | 34.8% | | StackBlitz | 15.1% | | Replit | 4.3% | | 其他 | 4.3% |

我認為線上程式碼編輯器的使用只會從這裡增加。現在,許多公司正在走向完全遠端化,線上編輯是降低成本的一個很好的選擇。你不需要投資高階膝上型電腦——CodeSandbox或StackBlitz可以幫你。每個開發人員都知道設定本地開發環境是多麼的痛苦,線上程式碼編輯器可以在幾分鐘內完成。

10.6 版本控制提供程式

對於版本控制,GitHub是許多開發人員的明確選擇,難怪GitHub多年來推出的各種功能令人驚訝:GitHub Action、CodeSpaces、VS Code Online、新的GitHub程式碼搜尋、人工智慧副駕駛……我可以繼續講述所有這些功能如何使開發人員的日常生活更輕鬆。GitHub操作消除了開源開發者對外部提供者的依賴,他們獲得了免費的開源構建。

10.7 你最喜歡的版本控制提供商是什麼?

| vcs | 得票率 | | --------- | ----- | | GitHub | 75.8% | | Gitlab | 14.6% | | BitBucket | 6.3% | | 沒有 | 2.1% | | 其他 | 1% | | Perforce | 0.2% |

Gitlab和Bitbucket提供了許多企業迫切需要的自託管選項的優勢。但儘管如此,GitHub是開源開發者的家園,它只會增長,The State of Octoverse[1]就是一個明確的指標。

十一、 測試

11.1 測試狀態中的驚喜:前端開發人員從未進行過更多的測試!

"我從事軟體測試工作已經近十年了,測試前端應用程式一直是質量保證人員最常用的活動之一。但是開發者呢?這份報告給我講了一個令人驚訝的故事。"--Dawid Dylowicz公司(Onfido QA負責人)

11.2 誰負責您的軟體開發團隊中的測試?

| 測試人員 | 得票率 | | ---------- | ----- | | 開發者和QA | 43.4% | | 只有開發者自己 | 24.5% | | 大多時候依靠開發者 | 20.3% | | 大多時候依靠QA同學 | 9.5% | | 只有QA | 2.3% |

對我來說,最令人震驚的結果是測試責任從測試人員轉移到開發人員。事實證明,在88%的情況下,開發人員至少和QAs一樣參與測試。

11.3 在過去的一年裡,你自己進行過軟體測試嗎?

  • 是: 80.5%
  • 否: 19.5%

11.4 你會寫哪些型別的測試?

| 型別 | 佔比 | | ------------------------ | ----- | | UT(單元測試) | 91.1% | | 整合測試 | 61.5% | | e2e(End-to-end UI tests) | 55.9% | | 其他 | 2.1% |

作為測試工程負責人,我的核心職責之一是鼓勵我們的質量保證人員成為教練,幫助開發人員參與測試。因此,我很高興看到我自己的經驗反映在調查中,顯示其他團隊在這方面也取得了巨大進展。

11.5 在過去一年中,您是否使用了以下測試工具?

| 測試工具 | 佔比 | | --------------- | ----- | | Jest | 80.1% | | Testing Library | 49% | | Cypress | 47.9% | | Mocha | 21.4% | | 其他 | 11.1% | | Super Test | 5.4% |

作為《軟體測試周刊》的策展人,我注意到很多測試人員和開發人員選擇JavaScript進行測試。如今,更多的人寫像Cypress和Playwright這樣的工具,而不是Selenium。因此,我並不驚訝地看到,近一半的受訪者已經試用過Cypress。除了Jest,它是最流行的測試工具。這表明人們對更健壯的測試越來越感興趣,並青睞具有良好DX(開發人員體驗)和使用與開發相同語言的工具。

十二、 實踐

12.1 您多久處理一次應用程式?

| 型別 | 從不 | 很少 | 偶爾 | 頻率較高 | 經常 | | ----- | ---- | ----- | ----- | ----- | ----- | | SEO優化 | 28% | 23% | 22.5% | 16.1% | 10.4% | | 可訪問性 | 9.2% | 20.1% | 26.5% | 27.1% | 17.1% | | 響應式 | 1.5% | 4.7% | 13.2% | 30.2% | 50.3% | | 效能 | 1.2% | 4.7% | 20.7% | 37.9% | 35.7% | | 使用者體驗 | 0.7% | 1.9% | 9.4% | 32.4% | 55.7% | | 開發體驗 | 2.5% | 5.8% | 18.4% | 37.2% | 36.1% |

12.2 良好的實踐並非一刀切——它們取決於您的團隊

"對於專案管理,69%的受訪者使用Scrum或Kanban。52%的Scrum比33%的Kanban更常見,17%的受訪者同時使用兩者。三分之二的前端開發人員在完成專案時使用這兩種方法之一。"

"受訪者沒有報告使用這兩種方法的公司大多是技術佔據主導地位的公司,這與我在文章《大技術如何運作技術專案》中的發現以及令人好奇的Scrum的缺失不謀而合。"

"單元測試在前端工程師中很普遍,近75%的受訪者編寫了此類測試。整合測試和端到端測試也很常見,大約一半的受訪者編寫了這些測試。"--Gergely Orosz(The Pragmatic Engineer創始人)

12.3 您在前端專案中使用了哪些方法/良好做法?

| 方法 | 佔比 | | ---------------- | ----- | | Code Review | 79.8% | | CI & CD | 73.9% | | Versioning | 62.9% | | Scrum | 52.9% | | Git Flow | 41.8% | | kanban | 33.8% | | Containerization | 32.6% | | 其他 | 1.4% |

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)?

| 頻率 | 佔比 | | ---- | ----- | | 從不 | 28% | | 極少 | 23% | | 偶爾 | 22.5% | | 經常 | 16.1% | | 持續在做 | 10.4% |

這就是我們最初的想法!然而,當我們看到剩下的選項並注意到以下幾點時,我們鬆了一口氣:

  • 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 您多長時間關注應用程式的可訪問性

| 頻率 | 佔比 | | ---- | ----- | | 從不 | 9.2% | | 極少 | 20.1% | | 偶爾 | 26.5% | | 經常 | 27.1% | | 持續在做 | 17.1% |

令我震驚的是, “總是”的答案竟然低至17% !這讓我認為,前端開發人員仍然是被動的,而不是積極主動地實現可訪問性。我在過去幾年中看到的是,工程師們現在正在積極地執行自動化可訪問性工具,作為其CI/CD的一部分,這無疑有助於提高工程師和軟體團隊其他關鍵成員的技能。

令我驚訝的是,可訪問性沒有使用者響應性、效能或使用者體驗那麼重要。我有一種感覺,由於公司產品的可訪問性差,現在可能會對公司產生法律影響,我預計這一情況在未來會改變。

與2020年開始關注可訪問性的問題相比,考慮到這些類別在某種程度上是“是”或“否”,我覺得大多數前端程式設計師都覺得他們關心可訪問性,儘管在大多數情況下,這只是一個特別的審查或審計。

我希望在接下來的幾年裡,我們能看到像安全性一樣的可訪問性,我們將在設計軟體產品時考慮到可訪問性。與過去幾年中安全至關重要的情況類似。

12.9 使用者體驗、響應式和效能

"使用者體驗往往是出現問題後的最後考慮。因為功能是第一位的,所以適應這些功能的使用者介面是第二位的。因此,使用者體驗是一項昂貴而及時的工作,只有在大型專業公司才能做到。"

"雖然大多數受訪者仍然傾向於使用自己的設計系統和樣式,如SCSS,但使用者體驗需求仍然往往落在程式設計師身上,他們只需要獲得一個功能來實現,而沒有任何故事板或使用者流示例。"--阿德里安·特瓦羅格(“Development & Design”創作者)

12.10 您多久關注應用程式響應式

| 頻率 | 佔比 | | ---- | ----- | | 從不 | 1.5% | | 極少 | 4.7% | | 偶爾 | 13.2% | | 經常 | 30.2% | | 持續在做 | 50.3% |

12.11 您多久關注應用程式的效能

| 頻率 | 佔比 | | ---- | ----- | | 從不 | 1.2% | | 極少 | 4.7% | | 偶爾 | 20.7% | | 經常 | 37.9% | | 持續在做 | 35.7% |

12.11 您關注使用者體驗的頻率如何?

| 頻率 | 佔比 | | ---- | ----- | | 從不 | 0.7% | | 極少 | 1.9% | | 偶爾 | 9.4% | | 經常 | 32.4% | | 持續在做 | 55.7% |

測試在編碼中是如此重要的一項任務,以至於沒有人能夠再想象不經過適當測試就可以釋出某些內容。這同樣適用於使用者體驗測試,在我的選擇中,它應該是寫入CI/CD工作流的另一個元素

有時,由於CTR失敗,使用者無法完成任務。但是,由於沒有涉及使用者體驗測試,任務本身經常充滿了未被發現的錯誤。

程式碼評審和設計評審也是如此。設計審查應始終考慮使用者對迭代的體驗,以提高編譯速度和程式碼任務的效能,以及使用者任務(例如使用者通過UI完成操作的時間)

我得出的結論是,現如今前端開發普遍給予了測試和審查更多的考慮,尤其是在程式碼方面,這些同樣的考慮應該應用於使用者介面和使用者體驗,因為它們對任何系統的成功都至關重要。

12.12 開發人員體驗。到底是使用者的體驗最重要還是開發者的體驗最重要?

"事實上,我對其中的一些結果感到驚喜。有時,開發者的主要關注點似乎是他們自己的開發體驗,甚至以犧牲使用者體驗為代價。這些結果證明並非如此。開發者體驗是使用者體驗的前提,這就是它應該被優先考慮的方式。如果我們不為使用者體驗構建軟體,那麼我們到底在做什麼? "--肯特·C·多德(Remix聯合創始人)

12.13 你大概多久關注應用程式開發人員的體驗?

| 頻率 | 佔比 | | ---- | ----- | | 從不 | 2.5% | | 極少 | 5.8% | | 偶爾 | 18.4% | | 經常 | 37.2% | | 持續在做 | 36.1% |

不幸的是,我對可訪問性的結果並不感到驚訝。至少我們對自己誠實。承認我們的缺點是改善缺點的第一步!希望這些結果能給我們敲響警鐘,提醒我們自己,對於大量使用者(包括使用輔助技術的使用者和未使用輔助技術的使用者)來說,可訪問性是使用者體驗的重要前提。事實上,對於一些使用者來說,他們對你開發的應用程式有任何“體驗”的唯一方式就是考慮可訪問性,因此我們最好採取相應的行動。

十三、 前端的未來

"前端可能正在進入穩定階段"--馬雷克·加伊達(Software House CTO)

13.1 在你看來,這些趨勢/解決方案中,哪一種會越來越受歡迎,哪一種會在兩年後逐漸消失?

| 型別 | 更加流行 | 沒有變化 | 消亡 | 沒有觀點 | | ------------------ | ----- | ----- | ----- | ----- | | 可訪問性(A11y) | 63.1% | 30.5% | 0.4% | 6% | | 原子設計 | 23.9% | 37.1% | 8.6% | 30.5% | | 元件驅動開發 | 58.4% | 27.9% | 1.5% | 12.1% | | 跨平臺應用 | 60.6% | 24.8% | 3.3% | 11.3% | | GraphQL | 42.4% | 34.7% | 9.1% | 13.8% | | 無頭CMS | 39.4% | 30.8% | 4.8% | 25.1% | | JAMStack | 26.5% | 29.8% | 10.8% | 32.9% | | 微前端 | 37.2% | 23.5% | 13.3% | 26.1% | | 線上頁面生成器 | 29.8% | 35.8% | 11.8% | 22.6% | | 漸進式 Web 應用程式 (PWA) | 42.6% | 34.4% | 11.8% | 11.2% | | 服務端渲染 | 60.5% | 27% | 4.8% | 7.6% | | Web Components | 45.2% | 27.1% | 11% | 16.7% | | WebAssembly(WASM) | 45.5% | 25.4% | 5.6% | 23.6% |

我注意到數字背後的第一件事是我最喜歡的sin(x)/x函式以及它與一般程式設計的關係。軟體開發仍處於早期階段,是一個行業中的幼兒。有一些佈道者宣稱,所有的東西都已經在主題X中說過了,因此目前的方法應該被視為標準。一分鐘後,激烈的討論開始了,人們對這個話題有180°的看法,所以技術轉向了Y。然後看,第一種方法又捲土重來,稍作調整,防止它過於極端,更接近 "中心"。之後,Y的粉絲們調整他們的解決方案,使之更接近 "中心意見"。最終,兩個極端成為一個 "妥協",變成了某種標準。這被稱為函式的退火(是的,我以前想當數學老師)。看看下面的圖表就知道了。

sin(x)/x函式圖

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年持續關注這個話題。

參考資料

[1] The State of Octoverse: https://octoverse.github.com/

[2] Core Web Vitals: https://web.dev/vitals/