|
|
公司招了幾個剛畢業的學生，作為重構的新手讓我來帶。
首先感謝感謝黨、感謝國家、感謝公司給了我這樣的一個機會，對我工作的肯定和認可，讓我帶這樣的一個重構團隊，同時我也明白任務的艱巨，但我一定會將工作做好，不負公司對我的期望。（哈哈，好像從小到大，老師都是教育我們要這樣先說的。）
在網站的發展史上，初期的網站建設根本不需要網頁重構這個職位，Web 1.0時代的網頁，只需要程序員，一堆堆的表格嵌套就完成，或者美工進行配合完成，先由美工負責設計好，再用一些自動化的軟件拉伸幾下，直接將設計好的圖就可以通過軟件輸出表格的布局了，根本不需要重構這個多余的職位。隨著Web 2.0的到來和W3C的規范得到世人的認可，內容和樣式的分離更方便進行開發和維護，傳統的表格布局和內容混排的方式逐漸地被淘汰，美工已不能完全一手包辦越來越復雜的效果和高要求的頁面布局了。此因催生了一個新的職位 —— 前端工程師。
鄙人剛好作為一名Web 2.0成長起來的前端工程師，雖然說做的項目不多，但樂于與人分享。雖然分享的也許只是一些很表面甚至有些過時的東西，但也只希望為大家提個醒，最好能起到拋磚引玉的作用。
一、前端工程師的職能和作用。
什么是前端工程師？有人這樣來表述：我們是工程師中的設計師，是設計師中的工程師。上班不干別的，就是玩，弄點效果，攢兩頁面，搞點創新。我們就是前端攻城獅（工程師）。當然這個表述有點輕巧、調侃的味道，工作絕對不是玩那么簡單的，有時候會為一些效果的實現或優化，弄得加班加點一起開發，但其實有兩一句表述是非常中肯的，那就是：我們是工程師中的設計師，是設計師中的工程師。這句話將前端工程師的角色的定位說得很準確。
前端工程師，在網站開發的初期，以工程師的身份來指導網頁的設計，前端工程師明白程序輸出的方法，指導設計師在設計的過程中避免一些不能輸出的數據排版，指出哪一些陰影、透明、圓角不能大范圍的使用等等；在進行頁面重構的過程中，又將以一個設計師的身份將設計頁面轉化為靜態頁面，需要用代碼對設計頁面進行最初的還原，實現好相應的前臺效果，排列好相應讓后臺開發的工程師輸出數據的地方，以適應后臺數據的輸出并保持頁面的不變形、不走位，在有數據輸出正常的情況下，配合程序去修改樣式，以盡量達到和設計的效果基本一致。所以在這個頁面設計和到程序的實現過程中，需要前端工程師起到一個橋梁的作用。
前端開發是一項很特殊的工作，前端工程師的工作說得輕松，看似輕巧，但做起來絕對不是那么的簡單。在開發過程中涵蓋的東西非常寬廣，既要從技術的角度來思考界面的實現，規避技術的死角，又要從用戶的角度來思考，怎樣才能更好地接受技術呈現的枯燥的數據，更好的呈現信息。簡單地說，它的主要職能就將網站的數據和用戶的接受更好地結合在一起，為用戶呈現一個友好的數據界面。
二、前端工程師的發展前景如何
前端工程師是是一個很新的職業，在國內乃至國際上真正開始受到重視的時間不超過5年。互聯網的發展速度迅猛，網頁由Web 1.0到Web 2.0，再到新生的HTML5、CSS3，到現在手機、3G網絡等新科技的興起，網頁也由最原先的圖文為主，到現在各種各樣的基于前端技術實現的應用、交互和富媒體的呈現，更多的信息、更豐富的內容、更友好的體驗，已經成為網站前端開發的要求，網站的前端開發發生了翻天可覆地的變化。
網站的開發對前端的需要越來越重要，高質量的前端開發工程師將會是后五年內一個非常熱門的職業，發展的前景非常可觀。
三、前端工程師需要掌握的技能
作為一個前端工程師，需要掌握的技能還真的不少。
最基本的三個技能：HTML、CSS、JavaScript。
這是前端開發中最基本也是最必須的三個技能。前端的開發中，在頁面的布局時， HTML將元素進行定義，CSS對展示的元素進行定位，再通過JavaScript實現相應的效果和交互。雖然表面看起來這些很簡單，但這里面需要掌握的東西絕對不會少。在進行開發前，需要對這些概念弄清楚、弄明白，這樣在開發的過程中才會得心應手。
HTML：
指的是超文本標記語言 (Hyper Text Markup Language)，這個也是我們網頁最常用普通的語言了，經歷了多個版本的發展，現在已經發展到4.01版了，得力于W3C建立的標準和規范，現在已普遍升級到了XHTML，XHTML 指可擴展超文本標簽語言（EXtensible HyperText Markup Language）， XHTML 于2000年的1月26日成為 W3C 標準，是更嚴格更純凈的 HTML 代碼，XHTML 的目標是取代 HTML。XHTML 與 HTML 4.01 幾乎是相同的，XHTML 是作為一種 XML 應用被重新定義的 HTML，是一個 W3C 標準。W3C 將 XHTML 定義為最新的HTML版本。所有新的瀏覽器都支持 XHTML。
另外，W3C 與 WHATWG 合作創建一個新版本的 HTML，就是HTML5。HTML5 將成為 HTML、XHTML 以及 HTML DOM 的新標準，為HTML世界注入更多驚喜，盡管 HTML5 仍處于完善之中，然而，大部分現代瀏覽器已經具備了某些 HTML5 支持，顯示出來的生機和活力已是那樣的激奮人心，特別是前端的工作中，那些針對瀏覽器兼容的問題將能得到很好的解決，更多的效果和應用也能更方便的實現。
前端工程師，也必然要與時俱進，緊跟業界時代發展的前沿，不然永遠只停留在舊的技術上，只會被無情的淘汰。
其實HTML的元素也就不過幾十個，常用的元素更少，所以掌握起來的話應該不困難。但就是這些看似簡單的元素，很多新手在剛開始的時候就不注意規范，養成一些不好的習慣。
1、不要忽略一些細節
隨便打開一個個網站，隨手點到了163（點擊鏈接可直接查看）的首頁，163算是一個比較規范和專業的門戶網站了，已經用上了HTML5的一些元素了，具體可以看到源文件。
在頭部的焦點廣告圖那里，用小BUG右鍵查看一下元素，看到這樣的一個圖像標簽img代碼：
img必備和可選的參數都有寫了上了，但是必備參數里的一個值alt沒寫（其實一些大型的專業門戶網站其實也是有存在一些小問題的，只要我們細心一點就能發現）。雖然這樣alt不寫，在頁面中也不會有任何的問題，因為這個alt屬性也只是在圖像丟失、禁用或加載不到的情況下才顯示，但是如果一些其他特定的設備訪問或一些其他條件下圖片不顯示的情況下，那這里就是一塊大紅XX和一大塊白塊，多影響用戶體驗。
雖然只是一個小小的alt屬性，但是有時候是細節決定決定成敗，用與不用，表面上看不出有什么問題，但是在某些特定的條件產生的作用是無法估計的，也就是從這些小小的細節就可以看出一個前端工程師的水平如何。
一些前端的新同學甚至什么也不填，放一張無任意命名意義的圖上去就算了事，養成這樣的習慣是非常不好的。
2、規范語義使用標簽
很多同學說是學習div+css，其實這個說法是存在誤區的，甚至是錯誤的。一個規范標準的頁面是合理地使用標簽，使其更加語義化，如果只是靠一堆堆的div通過層層的嵌套來布局完成的話，那么，除了div和a標簽這兩個標簽外，所有的HTML元素都沒有存在的必要了。
上面是一個前來應聘的朋友發給我看的一個頁面布局作品（點擊進行查看），這個同學還算是工作了一定時間的，據他介紹之前是在游戲公司工作的，但不知是不是當時所在的公司是不是他負責前端這塊的，不做評論。
這個朋友的頁面在瀏覽器查看沒有什么大問題，瀏覽罵的兼容性還可以說是沒有太大問題的，雖然從頁面的效果上看起來沒有什么問題，用小bug一看，可以看到他寫的這個代碼好像還蠻整齊的，所有的東西都是一層層的div，包裹得很仔細，類的命名也很有規律，但仔細一看，這個導航做的很有問題。查看一下源文件，發現不僅僅只是導航的問題了，整個頁面都有問題，所有的body下出現過的HTML標簽加起來總共只有七個，分別是：div、a、strong、font、input、br、img。先不說他寫行內樣式、align在HTML4.01中已經丟棄的屬性這些很低級錯誤的問題，一個很大的問題就是，語義的使用極不規范，使用層層的div來包裹定位。
例如這個導航可以用一個無序列表ul來就可以完成了，這樣簡潔明了，不需要這么多div和巨量的樣式來進行控制，最重要的是語義化也比較清晰了。
網頁布局就像是一篇文章那樣，有標題、有段落、有加強、有突出，HTML提供了這么多的元素給我們使用，就是要求我們要按照其語義來使用，該用標題的時候用標題（h），該用段落的時候用段落（p），該重點強調的時候用強調（em, strong），而不是都不管三七二十一，千篇一律的先用div來包裹再來進行控制。我們使用了這些相應語義的HTML元素，同樣可以使用css來進行控制的，可以達到任何我們想要的布局效果的。css的魅力就在于此。
研究表明， 語義化的標簽，越少的嵌套，對瀏覽器的解析就越快，顯示的速度就越快，當然對不同用戶群的用戶體驗也就越好！特別是對于一些特殊群體和閱讀設備，如盲人，使用的是閱讀HTML的機器，對于一塊塊的div，就不知道哪里是標題哪里是正文了，只能閱讀到的是這里有一整塊的內容。如果使用的是語義化的標簽就不一樣了，即使看不到屏幕，但也知道哪里是標題哪里是標題下相應的正文。所以，我們有css這個這么神奇的東西幫助我們網頁布局的時候，語義化的使用HTML標簽，用最少的嵌套和代碼實現同樣的效果，就是我們前端工程師所追求的。
再次回到前面div+css布局的一些誤區，什么是div?它的英文名是division，意思是分開、分割、分塊的意思。也就是說div在網頁中是用來進行分塊布局或是在沒有更適合的HTML元素的情況下用來配合分塊布局的，如果胡亂的濫用div，那么就會犯上“div控”了。剛入門不久的新同學最容易會犯這種思想的。
CSS：
CSS (Cascading Style Sheets)指的是層疊樣式表，現在普遍在用的版本是CSS 2.1 ，雖然已經發布了3.0的版本，且有一些個人的博客和站點已經使用HTML5+CSS3了，但受目前國內的主流瀏覽器IE6的影響，更多的人還是在使用2.1的版本，在這個的基礎上有選擇性的使用少量的不影響兼容的CSS3的某些功能，CSS3的普及還需時日。不管如何，CSS3的出現讓我們眼前一亮，增加了很多新的屬性，如圓角、陰影、漸變、動畫、流媒體等等的效果，讓頁面實現的效果更加方便和容易。
現在要和大家分享的并不是CSS3那些激動人心的屬性如何使用和實現，因為這些當我們學習到了一定階段的時候都會去學習到CSS3這個將來必將成為王者的使用，現在與大家分享一些與版本無關的東西，讓大家在學習的過程中少走一些彎路。
1、 Reset
關于重置也有太多的東西要說了，YUI、Eric Meyer等都有各自不同的方法，甚至有些人是不用重置的，不管怎樣，只要遵循一個原則：適合自己的就好。所以不對這方面過多的強求，也不作過多的討論。因為要討論的話幾大篇幅也討論不完。當然我自己有一個自己用的reset的地方，究竟好與不好，大家有空的時候可以研究，最好能把研究的結果與我分享，我也很愿意聽。這個是我的Reset的文件，大家可以點擊下載（aqy106_lab.css）
2、 樣式書寫要注意的事項
看過《Efficient, maintainable CSS》的譯文《如何書寫高效、可維護、組件化的CSS》，里面講到一些樣式的書寫要注意的事項。還是看一看這個同樣是一個新同學寫的樣式，看上去很整齊，命名也很有次序，但是仔細一看，問題還是很多的，先不說命名，因為這個得用另外的一個篇幅去說了。
如果作為一般的小站這樣寫，樣式的也許只是多幾個K的大小的問題，在性能上影響并不大，但在大型的網站中，幾個K的大小就不容忽視了。
基于前人的總結，個人認為高效的CSS書寫應該要注意：
1） 精簡屬性寫法，提高可觀賞性
很多屬性是有精簡的寫法的，如padding、margin、background等等，這些寫法雖然可拆可合，但我們習慣了精簡的寫法后，會讓css更加整潔、明了，看起來更加賞心悅目，感覺寫css就是一個雕刻一件藝術作品。
2） 使用多重選擇器，提高可重用性
多重選擇器的寫法相信很多人都會使用，但是多重選擇器的使用與進行二次編輯或多次編輯的時候會有一個矛盾，多次的修改，有可能需要重新定義的樣式不同，這時候又需要重新的將原先的選擇器進行分享出來單獨定義，這不能不說是一件痛苦的事情，所以在使用多重選擇器的時候，最好針對固定的版塊使用多重選擇器，這樣大大降低你日后維護、編輯的成本。當然，這是需要你的時間和經驗才能積累起來的。
3） 減少層級及繼承的寫法，一般不輕易用id
相信很多人都會考慮到重用這一高效的寫法，所以越少的層級、越少的繼承就為重用這一方法的實現提供了可能。也許有人會說，那我可以采用上面的“使用多重選擇器”來提高css的可重用性啊。其實這里面還有另外一個原因，就是更少的層級，渲染所使用的時間更少。css的渲染與JavaScript的方式完全不一樣，JavaScript的篩選直接使用id，能夠精準的定位到相應的dom，但是css的層級多的話反而會影響到性能，但具體沒做相應的測試。此處也許不嚴謹，請大家賜教，哪位大俠有空來測試一下，給一些相應的數據會有更好的說服力。但基于重用的原則，個人還是建議用最直接、有效的簡短的命名，也同樣就是這樣的一個原則，雖然id的唯一性解決了沖突問題，但違反了重用性的原則的同時也加大了維護和的成本，如非必要，盡量不用id。
4） 命名面向屬性和面向對象結合
其實命名這個方面有很長的一個篇幅可以說的，因命名的方法和各個人的習慣也不樣，有人喜歡用駝峰式，有人喜歡下杠線，有人喜歡縮寫，也有人喜歡全寫，個人認為這個主觀色彩太重了，不予作過多的展開，不管哪一種，都是沒有問題的。
和大家分享的是另外一個問題，是樣式的命名是面向屬性還是面向對象呢？相信這個也會困擾著一些同學。現在就和大家分享一些我的心得。在分享我的觀點之前，先跟大家解釋一下什么是面向屬性、什么是面向對象。面向屬性就是面向css的屬性來進行命名，面向對象就是面向要重構的頁面的模塊這個對象來進行命名。如下圖：
4.1 面向屬性命名
4.2 面向對象命名
關于這個問題，有人覺得面向屬性好，因為可以最大限度的利用好css的重用性；也有人認為面向對象好，因為面向對象可以讓后期的維護更方便直接。既然各自都有好處，那我們可不可以將兩者結合起來呢？答案是肯定的，而我個人也是這樣做的。
對于一些固定的、常用的、重用性非常高的css，可以將其按面向屬性來進行命名，上面的“面向屬性命名”的這個圖這樣，也可以說是一個小小的框架或是作為一個底層來方便自己的開發，放到哪里都是可以使用，具體可以見我整理的自已用的面向屬性的css（點擊下載aqy106_lib.css）。另外對于于具體的版塊就應該使用面向對象，針對版塊的對象來進行命名，這樣也讓后期維護或接手的人來編輯也不會困難。163采用的也是采用面向屬性和面向對象結合的方法來進行命名的。
作為一名前端開發的工程師，應該要有有利節流的思想，把css的書寫當作一門藝術來學習、來追求。書寫出一個高效、可維護的樣式往往是通向大師之路的必走之路。
樣式不僅僅是寫給自己看的，更要給團隊開發或后來接手的人看的，如果能做到簡潔、高效、重用性、可讀性強，相信，你離大師的級別也不遠了。
3、 CSS Sprite（圖片精靈、背景定位技術）
現在的網頁，各種各樣的媒體、圖標、背景都是多得眼花繚亂的，特別是背景圖片、圖標是我們網頁中使用最多的，按照以前的使用的話，插入一個個的小圖標或圖片用來控制來進行修飾，這些不和內容相關的圖標圖片也一并混排在內容中了，且頁面中一大堆無關的圖標圖片，還不方便管理。并且還有一個很大的弊病，一個圖片在頁面中是一個http的請求，頁面中存在n個的這樣的小圖標的話，對服務器的請求也就有N個，也許對于一些小站來說沒什么影響，但對于一個大型網站來說的話，這個數字可就不得了，這時的服務器并發請求就會多上N乘以用戶的個數，這樣無疑加重了服務器的負擔。
而解決這個問題的最好辦法就是CSS Sprite。
將所有的圖片整合到一張大圖上，通過css來進行定位。首先能將內容和修飾的元素進行了分離；其次能減少頁面請求的個數，那么減輕了服務器的負擔；再次，能夠提高頁面加載的速度，加快頁面載入速度，提升用戶體驗。
另外，將圖標圖片作為背景來進行加載，都是在文檔的主要內容進行加載完畢，再加載樣式時才進行請求的（細心的大家也許也發現，網絡不好的時候，頁面加載進來的是亂七八糟的，待一會樣式加載進來后，頁面馬上正常了，其實這個就體現到了文檔加載的先后順序，如果不相信的話，可以用小bug或相應的工具查看一下是不是這樣的加載順序）。
當然，事物都是具有兩面性的，將小圖標小圖片整合到一張圖片上，雖說有百利，但仍有一害的，就是當需要更換圖標或調整的時候，必須要在這張圖片進行處理和定位，需要在Firework等這些圖像處理軟件中定位好坐標再去寫相應的CSS，會增加一定的工作量，如果身邊沒有這些工具，處理起來還是會有些麻煩的。但總的來說，圖片整合，利大于弊，我們為何不用呢？
1、 兼容性
2、 以Trident為內核的IE、以Gecko為內核的FireFox、以Presto為內核的Opera、以Webkit為內核的google chrome和Safari等四大內核的瀏覽器四分天下。
兼容性的問題相信是很多前端工程師肯定會遇到且最頭痛的一個問題，且不說目前市面上有這么多的瀏覽器，就僅僅單一的IE系列家族的問題也夠多的了，特別是IE6，雖然微軟宣布了IE6的死亡和下臺，但國內的機器仍以IE6為主流，IE6在國內的消亡還需時日，作為前端開發沒法規避的情況下，暫時也只能折衷的進行兼容。不過雖然繁多復雜，但我們可以化繁為簡，重點問題重點處理，基本上IE6的問題解決了，也就解決最大的問題了。
當然，這個IE6的問題太多了，需要用另外的篇幅去進行說明了，這里就不再跟大家再作深入的研究了，給大家提個醒，讓我們一些新同學在成長過程中能夠有目的地去學習、發現和處理問題就OK了。
3、 圖片的優化
雖然現在的富媒體越來越多了，網頁展現的數據從單一的圖文向音頻、視頻、動畫等類型擴展，但受限于網絡傳送帶寬、速率等影響，圖片仍以最高的可壓縮比、傳送速度快、展現效果好等優點作為一個主角在網頁呈現和展示方面活躍著。目前網頁主流的格式現在常用的也就不外乎幾種：png、gif、jpg，其他一些在網頁中不常用的格式暫不在本次的討論之列。
3.1 圖片格式知多少
相信png、jpg、gif這些格式大家都能大概的了解和清楚一些使用，這里就不再細說，這里說一些使用中注意的事項或是大家不夠深入了解的東西。
png：png有多個不同的位數的格式：png8、png24、png32。前端的新同學們常常遇到的就是png在IE6中不透明，其實IE6是支持PNG透明的，不過只支持png8的透明而已，具體可以看我的頁面中圖標，就是用了png8的透明，但是png8下不支持半透明，所以頂部的這個有背景色的時候用了png32配合JS處理了一下透明效果，不然有白白的邊在IE6里太難看了。png8和gif都支持全透明和256色，所以在正常情況下兩者是可以互換的，兩者輸出的大小也差不多，甚至png8比gif更有優勢，但png8不能像gif那樣做成動畫。
而png24和png32也有一些不同。png24在png8的基礎上增加了顏色的支持數，但是沒有透明信息，png32在png24的基礎上增加了透明的信息。Firework和Photoshop雖然同為Adobe公司的產品，但是輸出的時候也是有些不太一致的。Firework能夠正常的輸出各種規格的png，但Photoshop不支持8位png+alpha透明的格式，而且Photoshop中也沒有32位png選項，其中的png24+透明實際上就是 png32（不信你可以嘗試用Photoshop輸出一個png24+透明的png再到Firework中看看就知道了），如果要IE6支持png32的透明，就只能用別的方法了，而我采用了js的方法，用法可見《IE6下PNG圖像透明完美解決方案》（其實標題應該改成“IE6下PNG32圖像透明完美解決方案”）。
gif：gif和png8一樣，都是只支持256色，模式都是索引顏色，但gif比png一個較大的優勢是可以將圖片做成動畫，而png8不能（現在最新版的png標準是支持一個文件內存放多個圖像的，也就是說同樣可以做動畫的）。
現在還有一些更非常規的圖片的用法，大家可以看到google的404頁面（點擊打開Google的404頁面），將圖片進行base64編碼再放到css中（當然IE6、7是無法正常解析的，嘿嘿）。
這種data: URI的格式能把base64（或其他數據）內嵌在image標簽的屬性當中（或者CSS中或JavaScript中），通過對圖片進行base64編碼，可以實現將圖片直接嵌入代碼中的目的，如此一來，可以減少HTTP請求，這對于提升Web性能很有好處。對于較小的圖片，采用這樣處理是非常實用的，但是IE6/7不能支持這種方法，因此可以在IE6/7中采用傳統的方法，而在其他瀏覽器中使用這樣的方法來進行全面的兼容。
這種做法有利有弊，好處是可以減少HTTP請求，不好的地方是圖像的大小會增加1/3。因此，這種內嵌的方法適合對小的圖形、小圖標等進行處理，從而減少瀏覽器打開的連接數，但對大的照片、圖片等則不應該使用base64編碼了，以免影響圖像下載的時間。
但這種圖像的處理也需要另外的軟件，所以不熟悉的情況下操作起來也有一定的困難，這里有一個在線版的轉換工具，有興趣的大家可以試試，嘗嘗鮮：點擊打開。
當然這些都是更深一點的應用了，我也在學習當中，無法再作更深入的論述了，大家可以自行進行擴展。當然，我也樂于分享你們的觀點。
擴展閱讀：《Data URI scheme》
更多的圖片的格式可以查看一篇老外的文章，也有人進行了介紹：
《Tips for choosing a cache image format 》
《The difference between PNG24 and PNG32》
外文不太好的也可以看這里，有人進行了相應的概括：
淘寶UED： 《圖片格式與設計那點事兒》
尹延超：《 PNG詳解》
6.2 如何輸出合適的圖片
說了這么多的圖片格式相關的知識，現在要實際操作來說明一下我們怎樣輸出一個適合我們的圖片了。
其實淘寶UED： 《圖片格式與設計那點事兒》這里也說明得夠詳細了，這里就不重復里面的一些方法了。我們最常用的圖像處理軟件莫過于Firework和Photoshop，所以我們也以這兩個軟件就重點。雖然兩個軟件現在是同出一家，同屬一個Adobe Master套裝，但兩者的算法還是有一定的差別的。所以在做圖片處理的時候有時候可以在這兩個軟件中分別進行輸出對比來決定最后圖片的使用。
注：本文使用的是Adobe Master CS4開發套裝的，其他的版本沒測，已知的是Firework 8中圖片輸出的算法也沒有Firework CS4的好，具體可以親測。
這里不再進行深入的論述，大家清楚了上面的格式的差別和軟件的問題后，在具體的工作中通過不停的比較就能得出上面這些結論。
JavaScript：
因本人也是JS菜鳥一個，也正在努力學習的階段，沒法跟大家深入的講JavaScript的一些核心代碼分析什么的，所以講一些無關緊要的所謂的理論問題。
頁面除了數據層的html、展示層的css，還有一個動畫和交互層的腳本，那就是JavaScript。JavaScript可以說是目前Web開發中一個非常流行的語言了，如果一個前端工程師能夠精通此語言，就單一項語言也能成就一份非常不錯的工作。
相信大家對之前Google里的那個用JavaScript做的紀念瑪莎·葛蘭姆的動畫還不會陌生，點擊此處觀看，這個用JavaScript配合圖像定位做成的動畫，展示了JavaScript的強大功能。
現在Prototype、JQuery、Mootools、Dojo、Extjs等的框架，各種各樣的基于js框架開發的插件方便我們的開發，大大的熱縮短了我們學習的周期，簡化了前端的開發，加快了開發速度，同時避免各類瀏覽器的兼容性問題。目前前端開發者使用JS框架是種很普遍的現象，但是我們的開發應該按需要進行選擇。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
