新的一年已經(jīng)過去幾個月,小伙伴們對前端的技術規(guī)劃是否還處于一個迷茫期呢,那么不要擔心,今天小編在這里給你們在這里做一個技術上指引。
有些技術,則會從采用走向棄用。若是以此為出發(fā)點,那么這個 2019 年和過去的 2018 年相比,并不會有太大的區(qū)別。
學一些新的技術,忘掉一些不同使用的技術。
只是前端一個這么廣的領域,到底要關心什么技術,到底要忽略什么技術呢?
前端是個最近幾年火起來的工種,而且持續(xù)火熱中,有個詞叫水漲船高,來的人多了,競爭多了,標準也就提高了。
現(xiàn)在對前端工程師的要求跟當年前已經(jīng)不能同日而語了。
今天給大家分享下前端的趨勢,當然了,所謂的趨勢,不是一天兩天就到來的,它是未來的一個技術方向。
我們之所以關注趨勢,是要關注變化,技術的發(fā)展與普及不是一日之功,一定是慢慢過渡的,但是你能夠比其他人提前看到方向。
真正的市場到來的時候,你就可以提前做好準備,提前發(fā)掘機會。
我光告訴你 2019 將會流行什么,可能并沒有多大的意義。你們需要自己去學會擁有這樣的技能,學會去分析出 2020 需要規(guī)劃什么內(nèi)容。
技術規(guī)劃
W-H-Y
每每談到技術規(guī)劃,我們談的總是下一年、下一個階段、下一個五年的目標??蔀槭裁次覀冃枰黾夹g規(guī)劃?或許是出于 KPI 的影響,或者是出于預算的原因,或是在追求技術卓越。
我們的目的是: 變得更好 。于是乎:“為什么我們就不能使用現(xiàn)在的架構?現(xiàn)在的架構不是挺好的嗎??”
為此,我們只需要嘗試回答這么幾個問題:項目的編譯速度快嗎?編寫新功能的速度快嗎?能滿足快速上線的需求嗎?多個團隊并行開發(fā),會出現(xiàn)問題嗎?我們依賴的第三方組件,會出現(xiàn)問題嗎?……
嗯,對這個問題就好像,別人在問你,“你有什么不足?”。
HOW
從這篇文章的寫作過程,及筆者的相應規(guī)劃步驟來看,可以分為這么幾步:
調(diào)研技術遠景
從社區(qū)獲得相應的輸入
整理潛在的技術方案、架構、技術棧
從利益相關者獲得想法。
制定相關的實施計劃
規(guī)劃,它類似于技術遠景的味道??梢徽劦竭h景,那么要談論的東西可多了。說不到我們還需要尋找利益相關者——如團隊成員、項目領導,了解一下,他/她對于技術團隊的一些期望。我們在社區(qū)上看到相似的問題,總有一個相似的開頭:“我們的領導……。”
談理想都特別有意思,因為我們不一定會去做。我們有了一個宏大的想法,只是受限于多個因素,我們只能做這么一點。比如說,我們未來想造一個筆記本,那么現(xiàn)在我們可以只選一個螺絲釘。
而在我們獲取更進一步方向的時候,需要從這么幾個維度來考慮問題:
從業(yè)務現(xiàn)狀出發(fā) 。
譬如,在下一年里,我們的團隊將從 20 人擴大到 100 人,為了支撐這么大的團隊。
我們需要擁有培訓機制,來應對這樣的人員擴張;需要設計一個更好的架構,來實現(xiàn)多個團隊的并行開發(fā)。從技術、架構出發(fā) 。
在項目中引入新的技術,改進原有的技術方案。
架構的預研 。提前試用未來可能使用的技術,如 AR、VR。這些往往是一些非必需的規(guī)劃,但是有了它們會更好。
團隊能力規(guī)則 。談論到團隊規(guī)劃,我怕是并不是那么擅長。
大抵上,哪怕是技術負責人也不是 KPI 的制定者,我們只能談談理想,聊聊團隊建設的一些建議。
有針對性地培養(yǎng)項目的 2nd Tier,至少對方是否能接受,那便不在我們的控制之下。這大抵也是個人發(fā)展的好處,可以選擇自己感興趣的內(nèi)容學習。
當然了,其它相當多的東西,還是要落地的——我們還是得造螺絲釘。只有落地的東西,才能證明它是真正有價值的東西。
為此我們要用 SMART 原則制定一個 smart 目標。當然了,如果你還要對領導匯報,請不到忘了你的時間節(jié)點。
總之,保持現(xiàn)在,探索擴展,嘗試未來。
WHAT
是不是我們規(guī)劃每件的事,都值得去做?是不是我們只做規(guī)劃的事情?未來是一直在發(fā)生變化的。
而規(guī)劃,只針對我們知道的內(nèi)容提出的。它無法用于我們不知道的領域。它也無法應對未知的事務,如產(chǎn)生了一個新的技術,它提高了三倍的生產(chǎn)力。
那么,先前我們設計的一些規(guī)劃,可能在此被新的技術替代掉了。
這方面的實踐,便有點類似于演進式架構的味道。
我們定好了一個大體的目標,核心的部分,只在真正實現(xiàn)的時候完善。
為此,它需要具備一定的可演進式,也因此不會受過去的設計所限制。倘若基于這一點因素考慮,那便是容易得多了。
只需要去尋找那些真正可能影響我們的趨勢,套上一個模糊的概念,就可以這么輕裝上陣。
可是呢,在做這件事情的時候, 每個人心里都有了一個答案 。
事實上,你心底也已經(jīng)有了一個答案,只是說呢,你不敢、不想直接說出自己的想法——一來,受限于能力;
二來,怕做了錯誤的決定。而直接、間接地,你在社區(qū)上看到一個大佬的回答,與你想要的答案是類似的。
便將這個答案懷chen出來,信心也就有了,再說 “我們也可以這么搞”。好了,以后一旦出現(xiàn)了問題,還有一個人可以莫名地幫你背鍋。
大家活著都不容易,背鍋事小,不帶人身攻擊就好。責任,它與能力和屁股的位置是成正比的。
我們從基礎來看,在對2019前端開發(fā)如何進階,提升自己,再做更深一層講解。
1 基礎技術
前端的三大基礎毫無疑問就是HTML、CSS和JS。我稱之為前端的骨、肉和魂。
先說“骨”——HTML。HTML,翻譯過來就是超文本標記語言,而不是江湖上的HOW TO ML。方向不能搞錯了,我們整的東西可是老少咸宜的。HTML學習最重要的標簽的學習,div、h1-h6、p、ul-li、strong、圖片、字體等,什么內(nèi)容用什么框.
再說“肉”——CSS。CSS定義了HTML標簽的顯示外觀,氣質(zhì)。主要掌握浮動,寬高設置、顯示屬性等
最后“魂”——Javascript。這是運行在瀏覽器上的腳本,但是現(xiàn)在javascript已經(jīng)遠遠不是當年的那個js了,尤其Ecmascript6標準出來后,nodeJS 橫空出世,JS暴露出一統(tǒng)天下的野心,JS讓網(wǎng)頁變得靈活,其實現(xiàn)的每一個明里暗里的交互,其實是為了觸及您的靈魂,這也是其成為魂的原因。
而現(xiàn)在,CSS3和HTML5的發(fā)展,又將web推向下一個時代,一個更為豐富多彩的時代。
2 環(huán)境基礎
設備、瀏覽器以及工作原理
必須指出的是,html CSS JS都是運行在瀏覽器的,是由瀏覽器負責編譯和呈現(xiàn)的。所以必須了解瀏覽器的工作原理。但是瀏覽器千千萬萬,也不是每個都要去解剖,主要的有Chrome, Firefox, IE,Safari,Opera,國內(nèi)的主瀏瀏覽器基本是基于chrome內(nèi)核開發(fā),做了一些更為接地氣的功能,了解下就可以了,主要有QQ瀏覽器,UC,百度瀏覽器,360瀏覽器,搜狗瀏覽器,獵豹瀏覽器等。
3 計算機基礎
計算機網(wǎng)絡,http協(xié)議。既然是web必不可少需要知道計算機網(wǎng)絡的知識,這對于網(wǎng)頁的加載和速度優(yōu)化有很大的幫助,并且,我們做的不是靜態(tài)的頁面,而是動態(tài)的,所以必然涉及到與后臺之間的數(shù)據(jù)的傳輸和存儲,這個是要掌握的。
必須懂:Ajax,必須會的工具:fiddler
4 流行框架
流行的前端UI框架:
Bootstrap、jQuery UI、Amaze UI
流行的前端框架:
Node.Js
jquery mobile
angular.Js
Vue.js
React.js
5 可視化組件
Echarts
tableau(收費)
前端 in 后端
所謂的前端 in 后端,便是 在后端開發(fā)中,使用前端相關的語言和技術棧 。
最典型的場景,便是使用 Node.js 開發(fā)后端服務。
雖然 Node.js 已經(jīng)有了 10 年的歷史了,但是以我的角度來看,我更希望的是使用編譯型語言,來開發(fā)后端服務。
動態(tài)語言,無法使用編譯器來檢測錯誤,難以約束代碼變動。
大前端
作為一個新興的技術領域范圍,大前端在不同的語義環(huán)境下,有著不同的解釋和含義,我們以幾個視角去對大前端并做逐一的分析。
Node.js 與前后端分離
在絕大多數(shù)的前端開發(fā)者口中,大前端有時與 Node.js 一起講,有時與前后端分離一同講,事實上,大前端概念也正是由廣大前端開發(fā)者提出的。
過去幾年,前端技術經(jīng)歷了爆發(fā)式的發(fā)展,這種發(fā)展最重要的推動者之一就是 Node.js。
Node.js 為前端建立了與系統(tǒng)之間溝通的橋梁,從此前端技術不僅能在服務端大放異彩,并且在本地的前端開發(fā)工具與工作流上大展身手,前端從此被解放,JavaScript 統(tǒng)治世界的論調(diào)一度甚囂塵上。
不過,當人們冷靜之后,發(fā)現(xiàn) Node.js 在服務端并沒有太多的優(yōu)勢,再加上 Node.js 本身技術發(fā)展的一些波折,導致它在服務端的應用并不理想。
但盡管如此,廣大的前端開發(fā)者還是取得了一些階段性勝利,其結果就是前后端分離。
在傳統(tǒng) Web 開發(fā)時代,前端頁面模板是由后端生成的,導致在頁面需要頻繁修改的時候,效率極低。
前后端分離指的是后端只提供接口,前端對頁面有完整控制,同時通過中間層將前后端隔開,在這里對數(shù)據(jù)進行抽取、聚合、分發(fā)等操作。這個中間層,通常也是由前端開發(fā)工程師負責。
從這種意義上講,大前端的原始定義可以稱為前端技術的擴大化,包括 Node.js,同時對 Web 頁面有更強的控制權,開發(fā)也將承載更多功能的頁面。
Node.js 打造后端服務
從社區(qū)的探索來看,存在一些完全使用 Node.js 開發(fā)的后臺服務。
但是,也存在一系列由于代碼不規(guī)范造成的問題。
從社區(qū)的經(jīng)驗來看,Node.js + Express + MongoDB + Angular/Vue/React,便是一些不錯的選擇。
當然了,也有相當多的應用,只是采用了 Node.js 來完成 BFF 層(Backend For Frontends)。在這一層業(yè)務上,它只做業(yè)務數(shù)據(jù)的中間處理。
雖然,我經(jīng)常建議在一些關鍵的節(jié)點上,不要采用 Node.js 來打造后臺服務。
可一旦涉及到 SPA 的服務端渲染,我們就不得不使用 Express、Koa 等這樣的服務端 JavaScript/TypeScript 框架,來解決這樣的問題。
Serverless
作為一種折中方案,也是我最喜歡的方案。
Serverless 架構是指大量依賴第三方服務(也叫做后端即服務,即“BaaS”)或暫存容器中運行的自定義代碼(函數(shù)即服務,即“FaaS”)的應用程序,函數(shù)是無服務器架構中抽象語言運行時的最小單位。
采用 Serverless 架構,也就意味著,我們提取出了大量的基礎設施。而使用 Node.js + JavaScript 作為膠水,來快速連接不同的服務,以形成一個快速有效的方案。并且,編寫更少的代碼,也意味著更安全、快速。
除了直接基于 AWS 的 Serverless Framework 框架的方案,還有 OpenFaaS、Kubeless、OpenWhisk、Fission 等不同的 Serverless 框架。
前端架構
由于前端的代碼量在不斷地增加,前端不在是一個大泥球架構,越來越多的新架構,將出現(xiàn)在前端領域。
微前端架構
微前端是一種類似于微服務的架構,它將微服務的理念應用于瀏覽器端,即將 Web 應用由單一的單體應用轉(zhuǎn)變?yōu)槎鄠€小型前端應用聚合為一的應用。
各個前端應用還可以獨立運行、獨立開發(fā)、獨立部署。
從筆者在 2018 年的實踐經(jīng)歷來看,微前端架構確實是一個不錯的架構方案。
它能有效地解決臃腫前端應用、遺留前端應用和復雜前端應用。
我們在項目上嘗試使用了多種不同的實踐方式:微件化、微應用化、路由分發(fā)、前端微服務化等。
將一個應用分解,拆解成更多的應用,確實能相對高效地提升開發(fā)效率。
如果你們的應用已經(jīng)相當?shù)拇螅浀貌捎梦⑶岸讼鄳募夹g。還有閱讀我寫的《微前端的那些事兒》。
組件庫及設計系統(tǒng)
自 Ant Design 的圣誕節(jié)事件之后,我相信: 在 2019 年,有越來越多的團隊將構建自己的組件庫 。一種頗為簡單的方案,便是:
評審一個開源組件庫 Ant Design、Material Design 等
在開源組件庫的基礎上,進行二次封裝。如 變成
替換部分的開源組件代碼
隨后,在那些的基礎上,加入自己的模式庫和設計系統(tǒng)。
BFF 架構
有越來越多的系統(tǒng)中,出于應對多端(Android、iOS、Web)變化的考慮,便在后端做數(shù)據(jù)相關的處理工作。
為了更好的解耦業(yè)務邏輯,并提供更快的業(yè)務響應,便在這一層級采用了 BFF 架構。
BFF 全稱是 Backends For Frontends (服務于前端的后端),它是指在設計 API 時根據(jù)不同的設備類型,來返回不同的結果。
除了,采用 Node.js 中相應的后端框架,作為 BFF 層的開發(fā)模式。GraphQL 是在 2018 年特別流行的一種 BFF 模式,毫無疑問在 2019 年也是一個值得考慮的方案。
好了今天小編就更新到這里,還有太多內(nèi)容下次更新,一回更新太多,怕你們消化不了,讓我們一起期待下一次的干貨分享。