專注網(wǎng)站開發(fā)網(wǎng)站頁面seo
上一小節(jié)我們了解了前端 UI 框架的作用和意義，接下來我們再來了解前端 UI 框架的發(fā)展歷史。
雖然是講歷史，但我不想講得太復(fù)雜，也不打算搞什么編年史記錄啥的，畢竟我們不是來學(xué)歷史的。
我會簡單描述一下前端 UI 框架的發(fā)展歷程，同時在這個過程中，把我自己的一些感受和想法分享給你。
你可以以輕松娛樂的心態(tài)來看這篇文章，同時也大概了解一下我們前端開發(fā)是怎么發(fā)展到現(xiàn)在這樣子的。這樣可以讓你更好地去理解將要學(xué)習(xí)的前端 UI 框架。
前端行業(yè)到底是怎樣發(fā)展的呢？對于新人的你肯定是不了解的。我說說我的理解。
我認(rèn)為整個前端行業(yè)是圍繞著復(fù)雜度來發(fā)展的，跟很多其他的技術(shù)發(fā)展差不多。
因此，接下來我會以復(fù)雜度這個核心來聊聊前端 UI 框架的發(fā)展歷程。
無復(fù)雜度：JSP & Dreamweaver
在互聯(lián)網(wǎng)剛開始的階段，網(wǎng)站的頁面是非常簡單的。在現(xiàn)在的我們看來，幾乎就是純靜態(tài)的頁面，沒什么動效，也不會有多少復(fù)雜的交互，最復(fù)雜的交互就是填一張表單，然后提交到服務(wù)器。
當(dāng)時最大的瓶頸是帶寬。當(dāng)時的網(wǎng)速賊慢，跟現(xiàn)在是完全沒得比的，當(dāng)時正常的網(wǎng)速擱現(xiàn)在，那就是卡頓，而且是卡得要死。當(dāng)時有個笑話，當(dāng)你要打開某個網(wǎng)站，在瀏覽器輸入網(wǎng)址之后，可以先去洗個澡，回來才能看到網(wǎng)站。
在這種情況下，網(wǎng)站要做的就是提供最核心、最具性價比的內(nèi)容和功能，而不是漂亮、用戶體驗好的網(wǎng)站。另一方面，程序員行業(yè)也沒有迎來大發(fā)展，在當(dāng)時，程序員還是個新型職業(yè)，從業(yè)人數(shù)非常少。
這些原因共同造成了一個結(jié)果：就是沒有前端。那網(wǎng)頁誰來開發(fā)呢？當(dāng)然是后端，在當(dāng)時，沒有前端，所以也不叫后端，反正就叫程序員。當(dāng)時，他們實現(xiàn)網(wǎng)頁的方式是使用一種模板技術(shù)，不同的語言有自己的模板語言。在當(dāng)時比較流行用 Java 來做 Web 站點，因此配套的模板語言 JSP 也比較流行。
我們可以看一段 JSP 代碼感受一下：
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%@ page import="java.io.*,java.util.*" %>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>xx 教程</title>
</head>
<body>
<h1>讀取所有表單參數(shù)</h1>
<table width="100%" border="1" align="center">
<tr bgcolor="#949494">
<th>參數(shù)名</th><th>參數(shù)值</th>
</tr>
<%Enumeration paramNames = request.getParameterNames();while(paramNames.hasMoreElements()) {String paramName = (String)paramNames.nextElement();out.print("<tr><td>" + paramName + "</td>\n");String paramValue = request.getParameter(paramName);out.println("<td> " + paramValue + "</td></tr>\n");}
%>
</table>
</body>
</html>
這是我從網(wǎng)上隨便找的，不需要太在意這個網(wǎng)頁是干什么的，就單純感受一下 JSP 的語法。
在后端的角度來看，要展示 Web 站點，就要給瀏覽器返回一個 HTML 文件，而這個 HTML 文件就是一段包含 HTML 代碼的字符串。所以你會看到，上面的 JSP 代碼都在處理字符串拼接的事情。有經(jīng)驗的同學(xué)應(yīng)該能想到，這不就是 SSR 么，是的，它就是 SSR，本質(zhì)是一樣的。
你可能會問，那個時候既然沒有前端，那誰來做 UI 呢？答案是設(shè)計師。當(dāng)時有種職業(yè)叫原型開發(fā)。他也算設(shè)計師的一個分支，同時也是前端崗位的前身。當(dāng)時的 UI 偏向純靜態(tài)站點，沒有復(fù)雜交互，因此原型開發(fā)主要使用 HTML 和 CSS。
原型開發(fā)要么自己設(shè)計，要么根據(jù)設(shè)計師給的設(shè)計稿來開發(fā) HTML & CSS 代碼，調(diào)完了之后，把 HTML 文件發(fā)給后端開發(fā)，后端開發(fā)再把這個 HTML 文件轉(zhuǎn)換成 JSP 代碼。這就是原型開發(fā)和后端開發(fā)之間的協(xié)作方式。
當(dāng)時在原型界非?；鸬囊粋€框架是 Dreamweaver，嚴(yán)格來講，它其實是個工具。
之前的圖片很難找了，我隨便找了一張圖片，差不多能展示 Dreamweaver 是個什么工具了。簡單地說，原型師可以在 Dreamweaver 中通過拖拽配置的方式來搭建網(wǎng)頁，最后輸出 HTML & CSS 代碼。因此，當(dāng)時很多原型師都不需要直接寫 HTML & CSS 代碼，他們只需要了解 HTML & CSS 語法知識就好了，所以說原型師還是更偏向于設(shè)計師，而不是開發(fā)。實際上，當(dāng)時的程序員群體也是把原型師看做設(shè)計師的。
有經(jīng)驗的同學(xué)一下就看出來了，這不就是低代碼么，沒錯，Dreamweaver 本質(zhì)就是個低代碼工具。是不是覺得很神奇，在互聯(lián)網(wǎng)最開始，SSR 和低代碼技術(shù)就已經(jīng)大行其道了，所以現(xiàn)在前端屆流行的 SSR 和低代碼都不是什么新鮮事了，只是翻炒冷飯而已。
嚴(yán)格意義來說，當(dāng)時都還沒有前端，所以也談不上前端 UI 框架，但是我覺得既然聊歷史，那就不得不聊一下這段時期的事情。我把這一階段的前端 UI 框架定義為 JSP 模板框架 + Dreamweaver 低代碼框架工具。因為當(dāng)時的網(wǎng)站 UI 主要就是這兩個技術(shù)搭建出來的。
UI 效果復(fù)雜度：前端開發(fā)攻城獅
隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)速上來了，網(wǎng)站可以做更多東西了，設(shè)計和交互越來越有創(chuàng)意了，這時網(wǎng)站的 UI 效果復(fù)雜度就越來越高了。
這帶來的最直接的后果就是后端開發(fā)頂不住了。要同時負(fù)責(zé)前端和后端，如果是簡單的小站點還好說，但如果是復(fù)雜的電商網(wǎng)站和博客網(wǎng)站就難頂了。術(shù)業(yè)有專攻，要同時深入研究后端技術(shù)，還要鉆研前端動效，現(xiàn)在的全棧工程師都頂不住，何況當(dāng)時。因此，在一些大型網(wǎng)站公司，慢慢地就出現(xiàn)了專門的前端團隊，當(dāng)時最出名的，就是百度、淘寶、QQ 空間幾個前端團隊了。
在當(dāng)時，前端開發(fā)主要來源于 3 類：
- 后端程序員轉(zhuǎn)前端，這種算比較少，大部分是被強迫的；
- 原型師發(fā)展為前端，這是最多的，自然而然的事情；
- 新人程序員，直接上崗就做前端。
慢慢地，就沒有原型師這個職業(yè)了，要么回到老本行做設(shè)計，要么去做前端了，現(xiàn)在幾乎聽不到原型這個職業(yè)了。
這段時期的初期，設(shè)計師提供設(shè)計稿，原型師實現(xiàn)出 HTML & CSS，然后前端開發(fā) JavaScript 代碼，后端再轉(zhuǎn)換成 JSP。
最后隨著前端發(fā)展壯大，就逐漸地前后端分離了，原型師被淘汰。最后的流程就是現(xiàn)在這樣，設(shè)計師提供設(shè)計稿，前端開發(fā) HTML&CSS&JS，后端開發(fā)提供數(shù)據(jù)接口。
這一時期的前端 UI 框架是什么？我覺得是前端開發(fā)攻城獅本人。前端開發(fā)通過自己的前端技術(shù)知識和程序員知識，把設(shè)計稿實現(xiàn)成復(fù)雜的、可交互的 UI 界面，這不就是最厲害地前端 UI 框架嗎？
瀏覽器兼容復(fù)雜度：jQuery/ExtJs
隨著前端技術(shù)大發(fā)展，標(biāo)準(zhǔn)不斷更新，功能不斷疊加，各家瀏覽器廠商為了爭奪市場，也不遺余力的支持新標(biāo)準(zhǔn)和擴展功能。最終給前端界帶來了新的復(fù)雜度：瀏覽器兼容性復(fù)雜度。
這絕對是前端屆深惡痛絕的事情。我們在實現(xiàn)繁重地需求功能還有應(yīng)對老板的奇葩需求的同時，還要處理煩人的瀏覽器兼容性。這是一段煎熬的日子。
要處理瀏覽器兼容性，需要安裝不同的瀏覽器，對于同一個瀏覽器來說，還要安裝不同版本。
同一個頁面，要在不同的瀏覽器，不同的版本，把所有功能都測試一遍。
QA 給我們提了一個 bug，用戶給我們反饋了一個問題，很多時候都沒辦法復(fù)現(xiàn)。
現(xiàn)在的我回想當(dāng)初，也是無比煎熬，我認(rèn)為這是極大的消耗我們前端開發(fā)的生命！因為解決瀏覽器兼容性問題，對我們的職業(yè)生涯來說，毫無意義。
那段黑暗的日子就不多說了，我們聊回前端 UI 框架的話題。在當(dāng)時，jQuery 是當(dāng)之無愧的前端 UI 框架一哥，它的意義和流行程度比現(xiàn)在的 React/Vue 更有過之。在前端歷史中，必有 jQuery 的一席之地。
jQuery 核心就是解決瀏覽器兼容性，統(tǒng)一了前端代碼的寫法。使用 jQuery，能避免大部分的 JS 兼容性，極大地提升了前端開發(fā)的效率。除此之外，jQuery 還有非常多優(yōu)秀的設(shè)計：
- 它的語法糖讓人愛不釋手
- deferred 語法，那個時候還沒有 Promise 呢
- 動畫隊列，至今仍有借鑒意義
- …
在 admin 領(lǐng)域，同樣也有開箱即用的 UI 組件庫，當(dāng)時比較火的是 ExtJs。就是類似 antd 一樣的開箱即用 UI 組件庫，還有以此為基礎(chǔ)的 admin 基礎(chǔ)框架。值得一提的是，不管是 jQuery 還是 ExtJs，當(dāng)時的前端庫大多是用繼承的概念來組織前端庫的，不像現(xiàn)在，已經(jīng)流行組合了。
前端工程復(fù)雜度：React/Vue
接下來就到了現(xiàn)在這個時代了，React/Vue 作為主流的前端 UI 框架。
互聯(lián)網(wǎng)的蓬勃發(fā)展，對 Web 站點的功能、性能、交互體驗等方面都有極大的要求。前端項目的代碼量越來越多，頁面越來越多，組件也越來越多，這些變化給前端項目的工程化帶來極大的復(fù)雜度。
而 jQuery 已經(jīng)越來越力不從心了，jQuery 雖然解決了瀏覽器兼容性的問題，但它仍然是一個直接操作 DOM 的框架。使用 jQuery，我們不僅需要通過操作 DOM 來處理 UI 界面，還要處理復(fù)雜的邏輯。當(dāng)這兩部分的代碼交織在一起的時候，就是我們加班改代碼的噩夢所在。
jQuery 的自由度很高，但是想要基于 jQuery 把整個前端項目的代碼給管理好，需要極高的編碼功底，還有嚴(yán)格被執(zhí)行的規(guī)范，才能做到不錯的地步，僅僅是不錯而已。
于是，React/Vue 應(yīng)運而生，它們做了高度的封裝，可以讓前端開發(fā)不直接操作 DOM，而是通過操作數(shù)據(jù)來處理 UI。通過這種方式，來解耦 UI 和邏輯。我們在使用這些框架的時候，必須要遵循他們的基本用法，這樣就極大地在我們的項目中應(yīng)用了這些框架的方法論，讓我們的前端項目代碼可以被更好地組織和管理，從而擁有一個比較好的可維護性和開發(fā)效率。
當(dāng)然，不是說我們只要使用了 React/Vue 就可以讓我們的代碼更好維護了，React/Vue 只是給我們提供了下限而已。想要讓我們的代碼更好維護，還需要不斷提升我們自己的編碼和設(shè)計能力。
好了，前端 UI 框架的發(fā)展歷程差不多就介紹到這里了，可以看到，前端 UI 框架是伴隨著互聯(lián)網(wǎng)行業(yè)而發(fā)展的，你覺得，下一步，前端 UI 框架會如何發(fā)展呢？
----------------【END】----------------
如果你是真心喜歡前端，并相信成長，想要提升自己的話，歡迎加入之道前端學(xué)習(xí)圈子。
戳這里 免費獲取 之道前端的學(xué)習(xí)資料和專屬服務(wù)。