為什么學(xué)前端
我的前后端分離態(tài)度
前后端分離是指技術(shù)架構(gòu)上的分離而不是對(duì)“職位”的分離?？梢噪S便打開一個(gè)招聘網(wǎng)站看一下“前端工程師”的要求：
- 熟悉HTML、CSS、JavaScript
- 熟悉一個(gè)前端框架，Angularjs、ReactJS
- 熟悉webpack之類的打包工具;git、svn之類的版本控制工具
深層次的分析上面的要求，一個(gè)不懂“軟件工程”基本理論的人能理解“前端框架”嗎?能知道模塊化、工程化嗎?一個(gè)不懂HTTP協(xié)議，分不清WebServer、瀏覽器、Session、Cookie的人能寫前端?一個(gè)聽不懂“隊(duì)列”、“棧”、“鏈表”的人能寫程序?從這些角度分析世界上只有一種職業(yè)“軟件工程師”，職位只不過是大家的工作側(cè)重點(diǎn)不同而已。
技術(shù)演進(jìn)一定是為了解決更復(fù)雜，更困難的問題;這意味著更大的工作量也意味著新職位的出現(xiàn)。所以新職位不是簡單的“分工”能籠統(tǒng)概括的。
為什么會(huì)有專業(yè)前端
正如數(shù)據(jù)庫出現(xiàn)是為了“通用式數(shù)據(jù)共享”問題;URI出現(xiàn)是為了解決“統(tǒng)一資源標(biāo)識(shí)”的問題，每個(gè)技術(shù)的出現(xiàn)都有它出現(xiàn)的時(shí)機(jī)。前端也不例外，我個(gè)人理解它的出現(xiàn)要解決核心問題是——前臺(tái)組件化或者工程化。
整個(gè)B/S系統(tǒng)的工作原理可以用一段話概括通過瀏覽器與服務(wù)器交互獲取HTML、CSS、JavaScript或者圖片(視頻)，在瀏覽器中渲染HTML、CSS，執(zhí)行JavaScript。服務(wù)器端只是生成上面三個(gè)元素;更確切的說——生成HTML。仔細(xì)想想是一件非常吃驚的事情——所以我們“發(fā)明”的各種框架、各種牛B的語言都是為了“方便”生成HTML(囧)。
從B/S系統(tǒng)的演進(jìn)歷史我劃分二個(gè)階段
***階段——動(dòng)態(tài)頁面
HTML代碼和某個(gè)腳本語言混合在一起。“不必過分多說,你自己清楚,你我到底想要做些什么”，直接上圖
這段代碼摘錄自“世界上***的個(gè)人Blog——wordpress”。為了精簡頁面中的邏輯它已經(jīng)做了很大的努力，比如提取出來很多函數(shù)放在單獨(dú)的PHP文件中，在頁面部分直接調(diào)用這些函數(shù)。
這一階段基本上屬于互聯(lián)網(wǎng)初期發(fā)展階段，大家能用上“數(shù)據(jù)庫”，做出“絢麗特效”就已經(jīng)非常不錯(cuò)了。
第二階段——結(jié)構(gòu)化階段
(我不喜歡用MV$這個(gè)詞，已經(jīng)別用爛了要結(jié)合上下文才能理解它的含義)。
HTML和腳本混合在一起的滋味很不好受，修改代碼的時(shí)候往往是牽一發(fā)而動(dòng)全身。所以第二階段就嘗試把HTML從代碼中剔除出去引入了——模板。
為了證明PHP是世界上***的語言我依舊選擇一個(gè)PHP項(xiàng)目來說明問題(OpenCart)。這段代碼已經(jīng)剝離了很多業(yè)務(wù)邏輯，基本上是根據(jù)傳遞到模板中的數(shù)據(jù)來渲染界面，但是代碼依舊顯的很“凌亂”。(我故意找到一段很“現(xiàn)實(shí)”的代碼是想告訴大家：即便我們用了模板也僅僅是“把邏輯盡可能的剝離”——誰的view代碼沒有用過if之類的判斷?)
這一階段就是我們現(xiàn)在所采用的主流技術(shù)，無論你是什么程序員不用“模板”，沒有“MVC”都不好意思開工寫B(tài)/S程序。此時(shí)的“結(jié)構(gòu)化”更多體現(xiàn)在后端，比如絢麗無比的數(shù)據(jù)訪問分裝(ORM之類的)、各種牛B哄哄的組件容器(Spring之類的)，我們還有一大堆隨手可用的“庫”(apache commons、JDK標(biāo)準(zhǔn)庫)，琳瑯滿目的模板引擎(Freemarker、Velocity、Thymeleaf)。這些工具幫我們更加容易組織代碼，也讓代碼更加容易被復(fù)用、被修改。
不完整的“結(jié)構(gòu)化”
但是這場“結(jié)構(gòu)化”并沒有針對(duì)前端帶來什么幫助。前端主要面臨的問題
- 大家還在一次一次的重頭寫CSS，缺少一個(gè)框架;
- HTML所能表達(dá)的東西粒度太細(xì)。比如我想要一個(gè)文本框就必須先定義form，定義幾個(gè)外部元素(比如div)修飾文本框，最終才能定義input type="text"/;
***個(gè)問題基本上被Bootstrap之類的CSS Framework解決了，第二個(gè)問題始終是一個(gè)“老大難”。我們始終缺乏一個(gè)技術(shù)手段把HTML組件化，如果你仔細(xì)觀察我上面的截圖會(huì)發(fā)現(xiàn)我用紅色框標(biāo)記的部分，這是一個(gè)非常典型的問題根據(jù)不同的數(shù)據(jù)我們設(shè)置不同的css。我們對(duì)HTML的控制力度是直接作用于標(biāo)簽而不是一個(gè)一個(gè)的組件，這就導(dǎo)致了HTML無法被復(fù)用。
前端的出現(xiàn)
解決HTML粒度的問題很多人都嘗試過努力，從后端角度出發(fā)的GWT、JSF、Asp.net WebForm;從前端角度出發(fā)的ExtJS、YUI，但是這些工作成效甚微。究其原因我覺的是“做得太多”，無論哪種方式它都是在試圖過多的隱藏復(fù)雜度，GWT是典型的“JavaScript是萬惡”;JSF一門心思非要“所見即所得”;WebForm則完全無視“設(shè)計(jì)師”的感受，讓你告別HTML;ExtJS、YUI則一切都是“組件”。過分的簡化問題會(huì)讓問題更加復(fù)雜，一個(gè)框架一定要暴露出必要的細(xì)節(jié)。
現(xiàn)在的前端定義了一種更加抽象的標(biāo)簽來代替HTML，比如Reactjs的jsx、Vue的Component、Angular的component directives之類的都極大的提高了HTML的抽象粒度也提高了代碼的復(fù)用程度。這些框架都暴漏了必要的細(xì)節(jié)給使用者(沒有一個(gè)聲稱告別HTML、JavaScript;一切都是組件)而且明確的區(qū)分出了“組件化”的范圍是在“頁面”層次——所有的頁面渲染邏輯全部放到前端來做而后端代碼只提供數(shù)據(jù)(再次說明，此處的前端、后端僅僅是指技術(shù)架構(gòu)上的變化而不是說工作職責(zé)的變化)。
現(xiàn)在開始學(xué)習(xí)
軟件領(lǐng)域的很多新技術(shù)要解決的核心問題都是復(fù)用，這似乎是整個(gè)領(lǐng)域的“魔咒”。經(jīng)歷了多年的發(fā)展我們從非結(jié)構(gòu)化走向結(jié)構(gòu)化，從雜亂無章走向模塊化、組件化。我們用UML、用軟件工程、用設(shè)計(jì)模式、用面向?qū)ο?、用各種華麗的技術(shù)來試圖讓我們的代碼更加容易維護(hù)、更加容易被修改——而背后的動(dòng)機(jī)都是通過復(fù)用節(jié)省成本。
HTML抽象粒度太細(xì)帶來的直接問題就是無法復(fù)用，比如“列表頁面”，所有的表格長的都差不多，唯一的變化是不同的列不同的數(shù)據(jù)來源，但是我們卻很難尋找一種方式可以“封裝”這個(gè)表格。再比如“表單頁面”，也是這種尷尬的局面，我們的HTML結(jié)構(gòu)差不多但是就是沒有辦法做封裝。我覺得這就是前端能帶給我們***的改變。
【本文是51CTO專欄作者“邢森”的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)聯(lián)系作者本人獲取授權(quán)】
