淺談前端天花板
前端天花板的高低
前端天花板的高低一直是一個爭議性很強的話題。在網路上更是各派相爭。
支援天花板高的人認為：前端的技術棧很廣，每一個領域都是可以長期鑽研的。如新的框架，腳手架工具，3D渲染等。
支援天花板低的人指出：從大廠高級別開發的分佈來看，無論是P9還是P8，前端的佔比都非常低。
而我的觀點是：前端確實是一個天花板很低的崗位。
職業天花板
當然，要討論這個問題，就必須帶上範圍。這裡我想指出，當我們談論“前端”天花板的時候，我們討論的實際上是“前端工程師”這個崗位的天花板，也就是這個崗位的發展上限。
不同職業之間的天花板都有高低之分，這是無法避免的。正如我們不會認為一個保安或者清潔工的職業天花板很高。這是由職業的業務價值決定的。
對於僱主來說，只要清潔工保持區域衛生就可以了，至於用什麼方式，僱主根本不在意。哪怕他對各種清潔工具瞭如指掌，幹起活來無比勤奮， 這並不會給僱主帶來額外的價值。換句話說，清潔工的職業天花板已經被僱主的需求限制了。
技術天花板
此外，前端作為工程師，存在職業天花板的同時，也存在技術天花板，而技術的天花板是無限的。
我們可以簡單把前端的方向分為幾個部分：
- 渲染框架（Vue，React，Svelte等）
- 腳手架/構建工具（Webpack，Vite，Esbuild等）
- 3D渲染（WebGL，WebGPU等）
分析後會得到一個結論：無論是哪個方向，都可以無限往下鑽研。
- 渲染框架 —— 挖掘V8，硬體效能
- 腳手架/構建工具 —— 開始Rust的內卷
- 3D渲染 —— 點亮圖形學技能
按照這個思路，如果用技術可挖掘深度定義前端的天花板，那麼它就是無限。
定義前端天花板
但別忘了，通常我們開始討論天花板的時候，我們大概率是在為自己的職業生涯感到迷茫。我們真正關心的是我們的職場還能往上走多遠。
那麼回到上文關於【職業天花板】的思路，我們來看看前端的業務價值究竟在哪裡。
首先，我們要清楚軟體產品的目標從始至終都只有一個，就是產品數字化。
以圖書管理為例，在沒有計算機的時代，我們需要用一個本子記錄各種圖書的資訊和數量。一旦書籍被借走或者入庫之後，我們需要在本子上塗改原來對應的數字。這就是圖書管理的業務。
當我們把這個業務數字化之後，我們會建立一個圖書管理平臺，上面顯示各圖書的資訊與數量。使用者可以在平臺上直接搜尋書名尋找自己感興趣的書籍。一旦確認借閱之後，只需點選按鈕，平臺上對應的數量就會修改。
總結這個流程，前端實際上只做了兩件事：渲染和互動。 這個規律可以應用到任何軟體中，這就是前端的業務需求，同時決定了前端的業務價值。
無論往後我們系統的圖書量與使用者量再怎麼增加，圖書資訊再怎麼豐富，圖書標籤之間的關係再怎麼複雜。對於前端來說，業務需求是一樣的，只需做好渲染跟互動就足夠了。但與前端不同的是，隨著業務越來越複雜，後端的業務需求難度會變逐漸高。因此，大家都偏向於認同後端的天花板比前端的高。
前端的方向建議
即便清潔工的天花板很低，但我們還是能找到一些高薪的清潔工作。因為總會有人對清潔有著更高的要求，而可以滿足這部分需求的清潔工就成為了清潔領域的專家，專門處理社會上一些特殊的高階需求，如奢侈品翻新，豪車清潔等。
也就是說，對於一個天花板普遍低的工作，對應的最好策略就是往業務價值上瘋狂地“卷”，成為領域專家。
回到前端，我們知道前端的業務價值在渲染跟互動。因此，可以大致推斷出一些前端高價值領域方向的猜測。
3D渲染
要突破目前前端的渲染瓶頸，方向一定是3D。3D帶來的使用者體驗將會是一個質的提升。想要插足這個領域，我們需要關注 WebGL 和 WebGPU 的動態。目前 WebGL 是被廣泛應用的技術，但由於它底層還是 OpenGL 那一套，所以帶來的價值是有限的。因此，我認為 WebGPU 應該是現在前端更值得關注的技術。
同時，Web 跟 Native 的鬥爭仍未結束。我們無法預估將來佔據網際網路3D技術的贏家是哪一派。雖然 Web 的開發軍隊很龐大，技術遷移成本更低，但隨著 WebAssembly 的發展，Native 在網際網路3D的落地效果越來越好，勢頭完全不比 Web 差。如果選擇 3D 這條賽道，開發者需要持續關注業內動態，並提前掌握相關技術。
元宇宙
無論發生了多少負面事件，我仍然相信元宇宙會是網際網路的下一個時代。對於前端而言，元宇宙帶來最明顯的改變就是使用者互動方式的變化。 互動方式的改變必須依賴於新的硬體，這就會給現階段的瀏覽器帶來很大的挑戰。在這個背景下，前端向客戶端（或者說“大前端”）轉移的可能性會非常大。
因此，選擇這個賽道的開發者應該做的是，關注業內硬體動態，以及提升“大前端”綜合能力。
低程式碼
除了渲染和互動以外，還有一個方向可以為業務帶來價值，就是 “降本增效” 。目前，低程式碼工具就是應這個需求而生的。與前兩個方向相比，低程式碼工具更像是傳統的前端專案。但別忘了，這個產品的需求背景是“降本增效”，這就意味著工具本身必須具體很強大的功能與相容性。一方面，企業希望這個工具能夠滿足儘可能多的需求，但又不會給員工帶來太大的使用負擔；另一方面，企業又希望在新增工具的同時，不額外購置新的硬體。
綜上，低程式碼作為一個產品，它的瓶頸其實來自於產品設計。但從技術角度分析，低程式碼工具給前端帶來最大的挑戰應該是相容與效能。它需要能在市場上大部分的硬體上執行，也要在功能增加的同時保證高效的效能。這個難度完全不亞於上方另外的兩個賽道。
開發低程式碼工具的前端要注意的應該是瀏覽器的相容性，以及對 JS 各種語法的瞭解。同時，為了高效解決這些問題，開發者應該嘗試從構建工具入手。其次，效能的提升必須依賴渲染框架的能力。因此，開發者還需要對業內各種渲染框架有深刻的掌握，必要時，甚至可能需要自研框架以突破效能需求。
選擇遠比努力重要
真實情況是，無論你的技術有多強，如果僱主對你的期待本來就不高，那麼一切都是徒勞。
想要突破自己的天花板，就必須主動選擇更適合自己的舞臺。例如，你決定了將來要死磕3D渲染這一賽道，那麼就應該找一家專注這個領域產品的公司就職。不必過分在意公司規模的大小。重要的是，你的能力是公司所需要的。只有這樣，公司才會尊重你的技能，你才能感受到自己的價值。
而這，才是對你的職業發展最好的長遠對策。