大家好,我是若川。持續組織了6個月源碼共讀活動,感興趣的可以點此加我微信 ruochuan12?參與,每周大家一起學習200行左右的源碼,共同進步。同時極力推薦訂閱我寫的《學習源碼整體架構系列》?包含20余篇源碼文章。
來自上帝視角的總覽
這是一份來自未來的文檔,感謝你對前端技術領域持續關注。
編程語言趨勢大觀:Python 反超 JavaScript
數據來源?Github
根據 Github 的相關數據我們可以發現 JavaScript 常年保持榜首位置,但是在 2021 年 Q4 被 Python 反超(很可能是因為分流了一部分人去使用 TypeScript),而 TypeScript 持續保持上漲態勢,受到更多前端開發者的青睞,可以想象在未來 TypeScript 將大有可為。
2021 年的前端人偏愛什么?
數據來源?bestofjs
出乎大家的意料,2021 年 Google 的命令行工具 zx 一舉獲得前端項目新增的 Star 數量頭籌,你可以使用它自由的在命令行書寫 JS 語法,甚至可以使用我們熟悉的 await 和 promise,可見前端工程師自由的靈魂也來到了 bash 表達式中
2021 年未來可期的前端人伴侶 vite,“快”是它的核心,它主要解決的痛點就是項目啟動緩慢, 還沒有嘗試過 vite 的小伙伴何不試試這款不需要做任何編譯的神器,說不定它幫你省下的時間可以讓你在午后悠閑的喝一杯咖啡
SSR 早就不是什么新鮮的內容,但是 Next.js 或許能幫你帶來更好的開發和用戶體驗
React ,我們的老朋友了,2021 年前端生態圈的豐富度依舊保持 React > Vue > Angular
如果你要試試跨端技術,Tauri 可能會助你一臂之力,任何可以用 JavaScript 來寫的應用,最終都將用 JavaScript 來寫
2022 年的前端人更可能想要?
如果給你一個站在巨人的肩膀上、使用上帝視角來看 2022 年前端趨勢的機會,你會看到什么?
奮進道路上的前端人,踏著新的前端標準,不斷攀上新高峰
堅實的前端基礎框架、工程化與體驗,是他們賴以生存的行囊
智能化前端搭建技術,讓初入江湖的小白也能快速追趕前輩的腳步
懷揣一門絕技跨平臺技術的大俠,在前端武林也能受人尊崇
精通泛前端的大神是六邊形戰士,上可摘月,下可撈星,可謂全才
5G 場景,更是給前端武林俠士們建起新的擂臺,給予更多人實現夢想的機會
往下看,好戲還在后面
如果你對上面所敘述的各項技術感興趣的話,請一定要讀完本文!相信我們精心制作的一定會給你帶來豐富的收獲,一起走入跌宕起伏風云變幻的前端世界吧!
“很多人在撿六便士,也有人在抬頭望月亮”
腳踏實地,踐行前端標準
HTML6.0
2014 年 10 月 28 日,W3C 正式發布 HTML5.0 推薦標準讓前端技術蓬勃發展。雖然 HTML6.0 目前處于提案階段,但是社區已經開始有了一些零星的討論,所以可能它離我們并不太遠。
HTML6.0 中,可能會新增“增強身份驗證”和“集成攝像頭” 2 個能力,大家可以持續關注相關進展。
一直以來,瀏覽器由于身份驗證問題導致 Web 應用在很多場景乏力,特別是目前大部分 APP 是十分“重”的,功能繁多,如果這 2 個能力得以普及,那么可能會有更多的 WEB 應用代替以前 APP 的極速版本。
由于新冠疫情影響,越來越多人的工作方式變成了 WFH。可以預見,疫情徹底清除以后,遠程辦公也許會成為不少人的選擇。所以“集成攝像頭”能力,很有可能在人與人線上交流場景中,發揮更大的作用。
2022 年,可能 HTML6 并不會推出,但是可能會有更多利于用戶體驗的提案出現。
Web3.0
Facebook 改名 Meta 后,元宇宙話題很火熱,但突然一夜之間,討論似乎又從元宇宙過渡到了 Web3.0。
Google Trends 對 “metaverse” 關鍵詞搜索趨勢
Google Trends 對 “Web 3.0” 關鍵詞搜索趨勢
從上面的 Google Trends 可以看出,兩者的趨勢在近幾個月都有明顯上升。所以很多人在想, Web3.0 是什么?它能給我們帶來什么?它會是下一個爆點嗎?可能每個人心中的答案都不一樣, 2022 年,關于 Web3.0 的討論將會更多,討論也會更加激烈。
目前很多人說 Web3.0 可能是去中心化,可能是物聯網,可能是人工智能。我們認為,目前都處于在混沌中尋找出路,針對 Web3.0 的形式、構成和應用,在每個人各抒己見、暢所欲言發表看法之后,經過一系列的沉淀,出來的結果會讓 Web3.0 輪廓更加清晰。比如 User Own Content 具體的含義是什么,討論之后才會有一些比較清晰的結論。至于討論背后可能存在的引導方向的人為推手,肯定會被淘汰出去,所以 2022 年真很有可能是 Web3.0 的元年,也值得每個前端開發去關注。
回首再看框架、工程與體驗
前端框架
在 StackOverflow 的“最受歡迎的 Web 框架”調查中,除去 SSR 渲染框架和 jQuery,上榜的前端框架共有 5 個:
而從 NPM 下載量來分析,觀察到的現象是:
React 一家獨大,獨自吃掉 70% 的市場份額
Vue 和 Angular 平分秋色打的難舍難分
Preact 作為“輕量版 React”在小眾中最受歡迎
Svelte 作為無 vdom 的 MVVM 框架,艱難爬升中,甚至還沒超過已經停止更新的 AngularJS
npm 下載趨勢
注 1:圖上 @angular/core 為 Angular(2.0+),而 angular 為 AngularJS(1.0)。
注 2:RN 占 React 下載量 10%左右,不算大,而且考慮到其他前端框架也有混合開發構建的流量,因此不做額外區分。
但是分析 Github Star 數增長趨勢,會發現與 NPM 下載量呈現相反的趨勢:
Vue 的 Star 數其實已經超過 React 了,但是實際上 NPM 下載量還不及 React 的四分之一
Svelte 的 Star 數已經甩開 Preact 近一倍了,但是 NPM 下載量完全相反
推測 Vue 和 Svelte 的作者都是前端界業界知名度較大的工程師,可能大家都會來膜拜膜拜點個 Star ,但在生產環境用不用另說。
盡管在 Stack Overflow 2021 年五月的調查中,Svelte 獲得了最好的“喜歡 vs 討厭”比例 ,但是實際上在生產環境中(NPM 下載量), Svelte 今年依舊表現平平,目前沒有要崛起的趨勢。
總的來說,React,Vue,Angular 依然是強勢鐵三角向前發展。在 2022 年 Vue3 會成為 Vue 的默認版本,React 18 也會發布正式版本,從目前社區關注度來看, Vue3 源碼 Github star 27k+, React 18 WG Github star 3.9k+,且在 npm 的下載量上,新版本下載數目都比較可觀,所以很有可能今年嘗試和使用的人會變得更多。
打包器
打包器大概可以分為兩類:
傳統編譯:Webpack, Rollup, Parcel, Esbuild
ESM 混合編譯:Snowpack, Vite
ESM 混合編譯:在開發環境編譯時,使用 Server 動態編譯 + 瀏覽器的 ESM,基本上實現了“開發環境 0 編譯”的功能。而生產環境編譯時,則會調用其他編譯工具來完成(如 Vite 使用 Rollup)。
npm 下載量
目前是 Webpack、Rollup、Esbuild 三分天下:
Webpack:我們的老熟人,生態最豐富,功能最多。獨自吃掉 70% 的市場份額
Rollup:ESM 版的 Webpack,甩掉了很多歷史包袱
Esbuild:Go 寫的 Webpack,性能有數十倍提升
而由于 ESM 混合編譯類打包器依賴于其他打包器,所以理論上 NPM 下載量永遠不可能超過其依賴。同時 ESM 混合編譯今年整體表現平平。
<script?type="module">import?lodash?from?'https://cdn.skypack.dev/lodash';</script>
早期打包工具白嫖瀏覽器 ESM 珍貴代碼片段
UI 框架
npm 下載量
由于模塊化 CSS、搖樹、MVVM 的流行,UI 框架的選擇其實沒有那么舉足輕重了,針對自己選用的框架選擇一個符合項目風格的 UI 即可。預計今年也不會有黑馬闖入和變動。
E2E 測試
單測框架的選型大多是跟著前端框架/腳手架模板/平臺支持等一起的,其實沒有提供給開發者太多的選擇,所以這里只看看 E2E 測試
在 2021 下半年,全新的 E2E 測試時代來臨了!
cypress 超越 puppeteer 成為最受歡迎的 E2E 測試框架
桌面端
各個用 HTML + CSS + JS 來寫桌面應用的庫的趨勢:
Github Star 數趨勢
值得關注的只有兩個:
Electron: 我們的老熟人,Chromium + Nodejs,深受大家喜愛
Tauri: 異軍突起的新星,Webview + Rust。對比 Electron 因為不用打包 Chromium 和 Nodejs 運行時,產物體積小,運行性能好
其他:只是把后端替換了下,如換成 .Net, Go 等
一些其他流行的小玩意兒
pnpm
可以說是 npm 的超級加強版,或者 yarn PnP 的加強版。其獨特的軟連接和硬鏈接的設計,使得裝依賴很快,一些設計模式也解決了目前很多 npm 的詬病。
但是這類 npm 代替工具,其實地位并不是很穩固。比如早期 npm 不支持 package-lock.json
的時候,大家都說 “Yarn 簡直太有用了!”,但是后來 npm 支持了 package-lock.json
文件后,二者的差距就很小了,也沒有非用不可的場景,而它自帶支持 Monorepo 的功能也很難說比 lerna 更好用。
swc
一個使用 Rust 寫的 Babel。swc 和 babel 的區別,就是 esbuild 和 webpack 的區別。非常快但是功能對比原版有缺失,swc 的生態建設也值得我們去關注。
智能搭建恰逢其時
低代碼的崛起
低代碼開發平臺(英語:Low-Code Development Platform,簡稱 LCDP),是一種方便產生應用程序的平臺軟件,軟件會開發環境讓用戶以圖形化接口以及配置編寫程序,而不是用傳統的程序設計作法。此平臺是針對某些種類的應用而設計開發的,例如數據庫、業務過程、以及用戶界面(例如網頁應用程序)。這類平臺一般可以產生完整且可運作的應用程序,在一些特殊的情形下仍需要編寫程序。
低代碼概念最早出現在 1982 年《無程序員的應用程序開發》一書中,美國低代碼產品的研究和實踐過程較長,積累了較豐富的經驗。中國最早出現低代碼平臺大概是在 2014 年,產品的形態從最初的數據庫交付,到數據集結構搭建逐漸演變抽象出各種流程引擎、可視化界面等產品能力,應用能力也從 BPM 延伸到 ERP、CRM 等大型復雜應用,低代碼平臺的門檻在逐步降低,低代碼平臺的用戶也逐漸從專業的技術人員向業務人員進行轉變,但相對全球市場,中國的低代碼行業仍然相對分散。
低代碼發展歷程
國際知名咨詢研究機構 Gartner 發布了《2021 年企業低代碼應用平臺魔力象限》。此研究通過產品操作、服務、市場反饋、用戶影響力、客戶體驗、營銷執行等多個維度對全球知名廠商進行了嚴格評選。(國內低代碼廠商不包含在內)
其中,OutSystems、Mendix、微軟、Salesforce、ServiceNow 被評為行業領導者
Appian、Oracle 和 Pega 被評為挑戰者
Creatio、Kintone、Newgen 和 Quickbase 被評為利基市場參與者
今年沒有廠商被評為遠見者
2021 年開年以來,低代碼行業被不斷關注,也引發了眾多企業的熱議與調研。
Gartner 預測:“到 2023 年,超過 70% 的企業將采用低代碼(LCAP)作為他們發展戰略的關鍵目標之一"。
同時,Gartner 還預測:到 2025 年,整體 LCAP(低代碼開發平臺)市場規模將達到 290 億美元,年復合增長率超過 20%;其中,LCAP 的細分市場預計將在 2020——2025 年之間,從 44.5 億美元增長至 143.8 億美元,復合年增長率為 26.4%。
低代碼發展初期,廠商的類型多樣化,傳統軟件廠商、互聯網大廠均涉及低代碼領域,通用型廠商相對垂直型廠商應用場景更加廣泛,因此廠商數量更多。但隨著市場成熟,通用類型廠商競爭加劇,垂直型廠商在細分的領域將會呈現優勢明顯趨勢,可以進一步挖掘用戶場景,提升產品能力和用戶滿意度。及早布局低代碼產業生態,多維度拓展廠商優勢,才能在未來占據高地。
AI 與圖形化的探索
人工智能作為跨時代技術在各個領域大放異彩,近些年 AI 能力在前端領域的嘗試與應用帶來新一輪的技術革命。
前端可以依賴 D3.js
,ECharts
,WebGL
等進行數據可視化的顯示
也可以用可視化的手段去解釋模型,輔助算法同學調參。最簡單的一個應用前端同學肯定非常熟悉,我們來看下圖:
目前提到人工智能,和前端密切相關的幾個 JS
類庫有:
tensorflow.js:基于
tensorflow.js Node
的tvnet
算法,可以提取視頻中的稠密光流deeplearning.js
kera.js
高性能計算:
asm.js
WebAssembly
GPU
Opencv,前端做 CV 算法,物體跟蹤、圖像處理、特征檢測等等
大家可能發現一個問題,一般的 tensorflow
模型動輒幾百兆,在前端怎么跑呢?這就不得不提到 MobileNet
,這是針對于移動端模型提出的神經網絡架構,能極大地減少模型參數量,同理也能用到瀏覽器端上。
在較早的 2017 年,一篇關于圖像轉代碼的 Pix2Code 論文掀起了業內激烈討論的波瀾,講述如何從設計原型直接生成源代碼。隨后社區也不斷涌現出基于此思想的類似 Screenshot2Code 的作品,2018 年微軟 AI Lab 開源了草圖轉代碼 工具 Sketch2Code,同年年底,設計稿智能生成前端代碼的新秀 Yotako 也初露鋒芒, 機器學習首次以不可小覷的姿態正式進入了前端開發者的視野。
Sketch2Code 架構
阿里的 imgcook 可以通過識別設計稿(Sketch / PSD /圖片)智能生成 React、Vue、Flutter、小程序等不同種類的代碼,并在同年雙 11 大促中自動生成了 79.34% 的前端代碼,智能生成代碼不再只是一個線下實驗產品,而是真正產生了價值。
imgcook 代碼生成過程
目前 Imgcook 官網已有 31,913 位用戶上傳了 92,333 個頁面,累計生成了 67,787,814 行代碼,阿里雙 11 代碼可用率達 79%,數據比較可觀,根據目前現狀分析,imgcook 能力在營銷活動頁面生產方面表現更好。
2022 年隨著低代碼和圖形化技術的逐步完善,2 者會相互完善和成就彼此。使用者通過 AI 實現頁面的還原然后再通過低代碼平臺對頁面進行調整,整個過程基本上不寫什么代碼就可以完成整個頁面的搭建,搭建頁面真的會變得特別簡單。
跨平臺技術撬開多「端」世界的大門
隨著從 PC 時代向移動互聯網時代演進,原生客戶端因為自身天花板的原因也在逐漸向跨平臺方案傾斜,當然這得益于跨平臺方案的明顯優勢。對于開發者而言,可以做到一次開發多端復用,這在很大程度上能夠降低研發成本,提高產品效能。但是,移動端的跨平臺技術并不是僅僅考慮一套代碼能夠運行在不同場景即可,還需要解決性能、動態性、研發效率以及一致性的問題。那下面我們一起看一下主流的 WebView
、React Native
、Flutter
多端跨平臺解決方案的優劣。
React Native VS Flutter
React Native 是以 Web 技術開發原生應用的典型框架。但是與眾多基于 html 的跨平臺框架相比,Flutter 絕對是體驗最好,性能與構建思路幾乎最接近原生開發的框架。
根據 StackOverflow 統計數據,Flutter 得分 68.8%、React Native 得分 57.9%。
根據權威機構 Statista 的跨平臺開發框架統計表明,2021 年 Flutter 已經和 React Native 持平。2020-2021 年間,有 42% 的開發者用過 React Native 進行開發,這一年內沒有增長;而 Flutter 這一數據從 2020 年的 39% 上升到了 42%。
通過對 Github 開源項目的 star 數 進行分析, Flutter 在近幾年增長迅速。
flutter 和 react native 在 Github上star 曲線圖
根據 Google 熱度趨勢 , Flutter 搜索趨勢也是很明顯的高于 React Native。
最后在基于各大社區的統計及上述的分析中可以發現, Flutter 目前雖然有著跨端最好的性能和體驗但是關注人數和 React Native 不相上下。React Native 由于先出優勢加上 React 的影響力導致目前很多 APP 都已經進入存量階段,少有新的 APP 出現,所以在沒有足夠的收益情況下,大部分 APP 是不會進行技術變更的。所以在 2022 年,如果兩者都無重大的技術變更,除了對 Flutter 關注的人會逐漸變多,兩者大概不會有什么比較大的轉變。
小程序
2017 年初微信率先推出小程序,其他互聯網公司紛紛開發出自己的小程序,經過四年發展目前全網小程序已超過 700 萬,微信小程序 DAU 超過 4.5 億。
上圖截選自:阿拉丁《2021 年度小程序互聯網發展白皮書》
目前主流小程序平臺有 10 多家,包括騰訊的微信小程序、QQ 小程序;阿里的支付寶小程序、淘寶輕店鋪;字節跳動的頭條小程序、抖音小程序;百度小程序等;不同平臺的實現標準各不相同,開發者需要學習不同平臺的開發規范做定制化開發。
所以在 2019 年 9 月 12 日阿里巴巴主導發起并聯合 W3C 中國及國內外廠商起草了 MiniApp 標準化白皮書(MiniApp Standardization White Paper),旨在制定共同標準減少平臺差異,并成立了相關工作組(作為小程序元老的騰訊沒有參加,畢竟如果標準化落地的話意味著現有的微信小程序可以以極低的成本遷移到其他平臺,對于擁有全網近半數小程序的騰訊無疑是一種損失)。截至目前產出了 lifecycle,manifest,packaging 等幾篇文檔,但從目前來看各平臺對這些標準的實現度還很低,并未實現統一,所以這么來看標準化的路看著還很長。
在當下要解決跨平臺開發問題可以采用框架轉換。
在縱觀整個前端的歷史,無論是 CSS 預處理器的大行其道、各種模版的流行,還是 CoffeeScript 乃至 ?TypeScript ?的誕生,都印證了這個說法,微信小程序這里也不例外。因此,各種小程序開發框架如百花齊放,層出不窮。
Github 開源項目的 star 數(一些實現方式相似的庫不進行比較)
百度搜索趨勢
從框架的語法來說大致分為 React、Vue 兩類:
Taro:React 陣營代表,通過實現一套 ?
DOM/BOM
? 的 API(實際會操作 Taro DOM Tree -- Taro 自定義的一顆虛擬 dom 樹)通過 template Taro DOM Tree 在運行時動態生成頁面結構。優勢是框架兼容性更高支持:React、Vue、Preact 等,實現了一套自己的事件機制不依賴特定平臺。同時缺點也比較明顯:深層嵌套的 template 結構導致包體積略大,實際生成頁面冗余節點較多
Uni-app:Vue 陣營代表,提供 IDE 、開發配套流程完整上手容易,有最多的使用者。在編譯階段將 Vue SFC 寫法的代碼編譯成 小程序代碼文件(JS、WXML、WXSS、JSON),在運行階段進行 vue 和 page 實例的綁定,將 patch 階段的 dom 操作替換為 setData。優點是生成的頁面結構與原生接近沒有冗余節點。缺陷主要是可用框架比較局限,基本是 fork 特定版本的 vue 做定制化開發,無法支持其他版本和框架
目前從一些社區反饋及測試結果來看,uniapp 在開發工具鏈、多端一致性體驗上相對領先。Taro 背靠京東在自家多個小程序上使用(京東購物在阿拉丁小程序指數中排入 TOP10 ),近一年更新也很頻繁,最新版本已經在適配鴻蒙應用。框架間并沒有明顯拉開差距,實際在選型時可能主要還是看團隊本身的技術棧偏好。
除了使用框架開發外,在開發過程中也可以使用一些轉換器來幫助將單平臺小程序轉換為其他平臺的版本。目前主流的轉換工具包括以下幾個:
antmove:目前較為流行的多端轉換器,可將支付寶/微信小程序轉換為多端小程序,支持增量編譯。轉換支持度概覽
wx2swan: 微信小程序到百度小程序
@qihoo/wx2qh:微信小程序到 360 小程序
miniprogram-to-uniapp:uniapp 提供的轉換工具,可將原生微信小程序轉成 uniapp 項目來適配多端
@tarojs/cli:tarojs 提供的轉換工具,也只能將原生微信小程序應用轉換為 Taro 項目
npm下載量(由于 @tarojs/cli 包含一些框架初始化命令,沒有可比性故排除)
可以看出上述 npm 包的下載量都不多,說明該方法目前使用場景太小了,很多包已經很久沒有更新,所以預計今年也不會有什么大的改變。
隨著一些跨端框架(Uniapp、Taro)的出現部分跨端轉換器基本已不再維護,這邊僅作補充。我們接下來來了解一些跨端轉換器相關的內容:
wept: 微信小程序實時運行工具,目前支持 Web、iOS 兩端的運行環境
hera-cli: 用小程序方式來寫跨平臺應用的開發框架,可以打包成 Android 、 iOS 應用,以及 H5
weweb-cli: 兼容小程序語法的前端框架,可以用小程序的寫法,來寫 web 應用
npm 下載量
跨端這項技術并非為了完全替代原生開發,針對每個場景我們都可以用原生寫出性能最佳的代碼。但是這樣做工作量太大,實際項目開發中需要掌握效率與優化之間的平衡,跨端的使用場景并不一定是項目級別的,可以是業務級甚至是頁面級的。
跨端的優勢在于能讓我們在書寫更有效率的代碼、擁有更豐富的生態的同時,還帶來了不錯的性能。
打造全能六邊形戰士之泛前端
“前端開發”的發展歷史像是一直在找尋自己的定位;從切圖仔、寫 HTML 模板的“石器時代”,到前后端分離、大前端的“工業時代”,再到現在跨端技術、低代碼的“電氣時代”。前端研發的職責一直在改變,同時前端研發需要掌握的技術也在迭代更新。
以前的 jQuery “專家”、IE 瀏覽器專家都不復存在。當下熱門的 Vue、React 框架也幾乎成為必備技能;前端領域的快速更迭告訴我們順應時代的變化才是核心技能。
Serverless
從語義上來理解, serverless 即無服務架構,但是無服務器的說法僅僅是一種概念上的強調,無服務架構仍然在某處存在有服務器,只是開發者無需再像傳統開發一樣去關注這些基礎設施,而是將精力更聚焦在業務實際的邏輯代碼之上。
在來自于加州大學伯克利分校(UC Berkeley)的論文《Cloud Programming Simplified: A Berkeley View on Serverless Computing》中比較精確的定義了 Severless 的概念:Serverless 是一種用云的簡化方式,基本可以理解為 FaaS BaaS,在 Baas 層進行存儲與計算,在 Faas 層提供云函數。
對比傳統的服務器托管方式,使用 serverless 架構開發,開發者無需多關注可用性、擴縮容、監控告警以及安全漏洞等等問題,只需要負責 Faas 層的代碼來處理業務邏輯即可。
同樣,UC Berkeley 給出了 Severless 需要滿足的三個關鍵特性:
隱藏了服務器的概念。雖然服務器依然存在,但開發者不感知,也無需針對服務器進行繁瑣開發和運維操作
提供了一種按需付費的計費模型,并且在資源空閑時不收費
提供極致的彈性伸縮能力,從而讓資源的提供完美適配業務需求
Serverless 的誕生更多是云計算層面對于資源管理和運維的進一步抽象, 但是通過上面提到的概念我們可以看出,對于技術開發者來說,在 severless 體系之下,收益最大的可謂就是前端開發者了。擴大自己的業務范圍,多觸及業務的核心處理邏輯,對于前端開發者來說是尤其重要的。因此最近幾年,全棧工程師在前端圈子中被提及的特別多。理想是很好的,但是真的要讓前端去完全包攬后端技術細節以及數據存儲等并進行很好的后期維護,確實對絕大部分前端從業者來說難度很高,正所謂術業有專攻。在 serverless 的賦能之下,前端工程師能夠將頁面交互、業務邏輯、數據處理等全部掌控在自己的手中,實現了真正全棧的可能。
全棧
“全棧開發者”是指“同時掌握前端、后端以及其他網站開發相關技能的開發者”。全棧開發者能夠勝任產品開發的全流程,從前端到后端,從架構設計到代碼落地,從自動化測試到運維等。對于公司來說,全棧工程師可以減小公司的用人成本,減少項目溝通成本;對于個人來說,擁有全鏈路技術有益于技術的閉環,擴展全局思維,提升個人能力和價值。
不同行業和方向,對全棧的能力要求會有些許不同。以獨立完成一個 web 應用為目標,一個“全棧開發者”主要會有以下技能點:
前端:JavaScript、H5、CSS3、sass、less、React、Vue、webpack、jest
后端:Nodejs、Go、Java、Spring、Gin、Kafka、Hadoop
數據庫:MySQL、mongoDB、redis、clickhouse
運維:網絡協議、CDN、Nginx、ZooKeeper、Docker、Kubernetes
成為“全棧開發者”是否是一個好的職業規劃,這在業界有較多的爭論。反對“全棧”的觀點認為人的精力是有限的,“全棧”會分散開發者的注意力,大概率只能浮于表面,什么都懂一些,但是什么都不精通。也有不少人、公司支持“全棧”,Google 的招聘職位基本都是 “Software Engineer”。支持“全棧”的觀點認為:全棧開發者更能跳出局部,從整體查看一個應用每個“棧”之間的協同運作,把握全局。
這個爭論很難有個結論,我們不妨跳出代碼、應用層面,從市場角度看一個工程師的分級。工程師實現自我價值的最終評判標準是產品(無論是技術產品還是商業產品),“全棧”或者“專家”僅僅是實現目標的過程狀態。吳軍在《硅谷來信》中,將工程師劃分成五個等級:
從工程師能力模型來看,第一級需要集“天時地利人和”大成,是工程師的最高榮譽。普通人或許可以將目標聚焦在第二、三級。優秀的工程師并不是以“棧”數取勝,更重要的是擁有產品觀、全局思維、溝通能力、學習能力、解決問題能力等。
DevOps
DevOps(Development 和 Operations 的組合詞)是一種重視“軟件開發人員(Dev)”和“IT 運維技術人員(OPS)”之間溝通合作的文化、運動或慣例。透過自動化“軟件交付”和“架構變更”的流程,來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。 可以把 DevOps 理解為一個過程、方法與系統的總稱。
在業務的快速迭代持續交互過程中 DevOps 的作用十分明顯。得益于其誘人的優勢,DevOps 已經成為目前軟件開發中不可缺少的因素。根據 信通院攜手華為云 DevCloud 發布中國 DevOps 現狀調查報告(2021 年)調查結果顯示,企業對研發運營一體化(DevOps)能力成熟度評估的關注程度持續上漲。調查還顯示,63.64%的受訪者對 DevOps 能力成熟度評估感興趣,相比 2020 年增長近一成。所以 2022 年 DevOps 或許還是會從以下幾個方面值得關注。
微服務架構:微服務架構可以將一個應用分成需要更小的服務,這讓整個開發過程具有很高的敏捷性和可拓展性
與 Kubernetes 相結合:Kubernetes 是一種開源容器編排系統,容器技術的日益普及是 DevOps 出現的因素之一。使用 Kubernetes DevOps,軟件開發人員和運維團隊可以快速實時地相互交換大量的應用程序,大大提高了生產力
DevSecOps( DevOps + Security ):安全問題一直都是各個公司最重要的事情,所以肯定會被重視。如果安全能與 CI/CD 工具集成,能在開發階段持續的監控和修復安全漏洞,那么會很大程度的提高交付的速度和質量
5G 場景下的新趨勢
5G 時代到來
5G 的到來對于技術研發工作者的我們而言意味深遠。他的出現是數據傳輸速度、響應速度和連接性的一次巨大飛躍。他像一條嶄新的高速公路,促進大體量數據比以往更快、更暢通地傳輸。伴隨著通信技術的升級,硬件設備的性能也在不斷提高。
網絡和硬件的提升會促使前端領域產生哪些突破呢?
5G 將與超高清視頻、VR、AR、消費級云計算、智能家居、智慧城市、車聯網、物聯網、智能制造等產生深度融合,這些都將為前端技術的發展帶來新的增長和機遇。
WebAR & WebVR
在 2021 年的 10 月,Facebook 宣布將公司名稱改為 Meta,并將元宇宙定義為社交的下一個演變,元宇宙這個概念迅速火爆全球,而在這個元宇宙未來發展可預見的初期階段,前端人的 WebAR 和 WebVR 是否能夠搭上“順風車”改善最近幾年不溫不火的現狀?
目前的 WebAR 和 WebVR 技術距離實現元宇宙的愿景似乎還很遙遠,但借助于以 URL 的格式進行傳播的優勢,通過社交媒體分享形式進行推廣,WebAR 和 WebVR 無疑是用戶接觸到元宇宙門檻的最便捷的方式,不需要購買昂貴的 VR 設備,不需要安裝 APP,通過手機網頁就可以進行體驗。在 5G 技術逐漸普及的當今,現有的一些體驗問題,例如:3D 模型體積較大,初次資源加載耗時長之類的問題也能夠得到一些緩解。
前端人在這塊能夠做些什么?從技術上來講,需要我們通過機器學習算法,實時的將虛擬圖像覆蓋到用戶屏幕,并且和真實世界中的位置進行對齊,結合 WebRTC 技術實現網頁瀏覽器實時獲取和展示視頻流,再利用 WebGL 的能力,進行 3D 人物模型加載,渲染和播放動畫。
Web 3D
對于 Web 3D 大家并不會陌生,有著豐富的業務應用場景:3D 類的 H5 小游戲、在線看房、電子商務、在線教育等,對于技術而言這無疑是一片沃土;
最讓人熟知的 Web 3D 渲染引擎 Three.js ,對此感興趣的人可能都嘗試過用它去畫過正方體,但因其門檻較高而被勸退的人也不在少數;
對于復雜動畫的實現,Lottie 可能是首先被我們想到的解決方案,而使用 Web 3D 的成本可能比想象中要高得多,這對設計、研發團隊的技能要求是很大的挑戰。
隨著 5G 技術發展,視頻加載速度會非常快,簡單的實時渲染會被視頻直接替代。復雜的可以通過服務器渲染,將畫面傳回網頁中,只要傳輸夠快,手機的性能就不再是問題。
降低 web 3D 研發成本應該是將來的一個重要發展路線,隨著技術門檻的降低,會吸引更多感興趣的人加入促使其正向的發展。所以 Web 3D 可能會朝著平臺化的方向發展,能提供簡單高效的工具將成為核心競爭力。
WebRTC?( Web Real-Time Communications )
WebRTC 是一項實時通訊技術,它為前端打開了信息傳遞的新世界大門,對于絕大多數前端開發者來說,對于信息的傳遞還局限于 XMLHttpRequest,升級到全雙工大家會用到 WebSocket ,對于能力閉塞的前端來說,WebRTC 無疑是打破了前端楚門的世界。
現狀:基于點對點傳輸,前端已經突破了一些原有的瓶頸,實現了以前遙不可及的能力
音視頻 P2P 技術方案
類似微信視頻的即時通信方案
信息消息傳遞
直播課堂
困境:WebRTC 的高封裝度,讓前端開發者幾乎不能介入到傳輸擴展和流媒體處理的兩大領域。
未來:WebRTC 會在點對點私密傳輸、娛樂領域,元宇宙領域,低延遲領域大放異彩
基于機器學習,音視頻算法的 WebRTC 玩法,可能會成為一個新的風口
在一些敏感等場景下,端到端的加密傳輸會是一個新的玩法
低延遲在中國除了直播課堂以外,還會在例如攝像頭等 IOT 的領域下持續發光
也許還能有點什么?
Wasm
WebAssembly 簡稱 Wasm,是一種可在 Web 中運行的全新語言格式,同時兼具體積小、性能高、可移植性強等特點,在底層上類似 Web 中的 JavaScript,同時也是 W3C 承認的 Web 中的第 4 門語言。Wasm 被設計為可供類似 C/C++/Rust 等高級語言的平臺編譯目標,最初設計目的是解決 JavaScript 的性能問題。
2020、2021 年 Wasm 因為有著 JS 所不具備性能的優勢,在前端的游戲、音樂、視頻等領域大放異彩,目前很多桌面軟件也紛紛通過編譯成 Wasm 的形式搬進了瀏覽器中,很多基于 Wasm 開發的 Web 應用也如雨后春筍一般出現,比如各種 Web 版的視頻編輯器、一些在線 VR 游戲等。除了很好的解決跨平臺問題以為,打開網頁就可以使用的用戶體驗對新手用戶來說是很容易接受的。
技術發展與技術使用是一個相互促進的事情,所以在 2022 年 Wasm 功能將會不斷完善,同時也會有越來越多的傳統 PC 軟件推出 Web 版本。目前 Rust 也已經在前端領域卷起了一股風,大部分前端開發者都在嘗試去了解 Rust,根據查看 Googlo Trends 對“ Rust Wasm ”關鍵詞,在過去一年該項組合一直是一個比較熱門的話題。
( Googlo Trends 關于“Rust Wasm”關鍵詞趨勢)
所以 2022 年我們可以預想到當同時了解和使用 Wasm + Rust 的前端開發者越來越多時,眾多的開發者碰撞肯定會成為出現一個新的火花。個人猜想在 Node 環境中很有可能會構建一些類似邊緣側的基礎設施,如使用 Rust + Wasm 構建的輕量級沙箱。
最后的最后
歡迎加入我們!招聘鏈接:https://job.toutiao.com/s/LgNjq47,聯系郵箱:fe.cs@bytedance.com 。
「Data-TnS-FE」部門為公司全球化產品的內容安全業務提供各類能力,其目標是從用戶/業務視角出發,結合技術賦能于業務,打造更多普適便捷的業務中臺、基礎架構、解決方案等,為團隊所有業務的運作提供穩定、高效、易用的能力支撐。
參考鏈接
Comparing the New Generation of Build Tools: https://css-tricks.com/comparing-the-new-generation-of-build-tools/
https://insights.stackoverflow.com/survey/2021#most-loved-dreaded-and-wanted-webframe-love-dread
探索低代碼的未來.pdf: https://bytedance.feishu.cn/file/boxcnvKV03brRBnDRM3ZEElL3Kg
國內外低代碼平臺交流: https://github.com/taowen/awesome-lowcode
2021 中國低代碼市場研究報告: https://pdf.dfcfw.com/pdf/H3_AP202108051508251387_1.pdf?1628205916000.pdf
小程序: https://developers.weixin.qq.com/ebook?action=get_post_info&docid=0000e82f924ca0bb00869a5de5ec0a)
底層框架: https://developers.weixin.qq.com/ebook?action=get_post_info&docid=0000e82f924ca0bb00869a5de5ec0a
同層渲染: https://developers.weixin.qq.com/community/develop/article/doc/000c4e433707c072c1793e56f5c813
Taro 對比原生: https://docs.taro.zone/blog/2020-04-27-taro-vs-jd#%E6%80%A7%E8%83%BD%E5%AF%B9%E6%AF%94
跨端框架橫評對比: https://juejin.cn/post/6844904118901817351
Taro: https://docs.taro.zone/blog/2020-01-02-gmtc
uniapp: https://v.qq.com/x/page/r0886mn8v6l.html
·················?若川簡介?·················
你好,我是若川,畢業于江西高校。現在是一名前端開發“工程師”。寫有《學習源碼整體架構系列》20余篇,在知乎、掘金收獲超百萬閱讀。
從2014年起,每年都會寫一篇年度總結,已經寫了7篇,點擊查看年度總結。
同時,最近組織了源碼共讀活動,幫助3000+前端人學會看源碼。公眾號愿景:幫助5年內前端人走向前列。
識別上方二維碼加我微信、拉你進源碼共讀群
今日話題
略。分享、收藏、點贊、在看我的文章就是對我最大的支持~