【本文來自：黃錦誠】
公司招了幾個剛畢業的學生，作爲重構的新手讓我來帶。
首先感謝感謝黨、感謝國家、感謝公司給了我這樣的一個機會，對我工作的肯定和認可，讓我帶這樣的一個重構團隊，同時我也明白任務的艱鉅，但我一定會將工作做好，不負公司對我的期望。（哈哈，好像從小到大，老師都是教育我們要這樣先說的。）
在網站的發展史上，初期的網站建設根本不需要網頁重構這個職位，WEB1.0時代的網頁，只需要程序員，一堆堆的表格嵌套就完成，或者美工進行配合完成，先由美工負責設計好，再用一些自動化的軟件拉伸幾下，直接將設計好的圖就可以通過軟件輸出表格的佈局了，根本不需要重構這個多餘的職位。隨着WEB2.0的到來和W3C的規範得到世人的認可，內容和樣式的分離更方便進行開發和維護，傳統的表格佈局和內容混排的方式逐漸地被淘汰，美工已不能完全一手包辦越來越複雜的效果和高要求的頁面佈局了。此因催生了一個新的職位——前端工程師。
鄙人剛好作爲一名WEB2.0成長起來的前端工程師，雖然說做的項目不多，但樂於與人分享。雖然分享的也許只是一些很表面甚至有些過時的東西，但也只希望爲大家提個醒，最好能起到拋磚引玉的作用。
一、前端工程師的職能和作用。
什麼是前端工程師？有人這樣來表述：我們是工程師中的設計師，是設計師中的工程師。上班不幹別的，就是玩，弄點效果，攢兩頁面，搞點創新。我們就是前端攻城師（工程師）。當然這個表述有點有點輕巧、調侃的味道，工作絕對不是玩那麼簡單的，有時候會爲一些效果的實現或優化，弄得加班加點一起開發，但其實有兩一句表述是非常中肯的，那就是：我們是工程師中的設計師，是設計師中的工程師。這句話將前端工程師的角色的定位說得很準確。前端工程師，在網站開發的初期，以工程師的身份來指導網頁的設計，前端工程師明白程序的輸出的方法，指導設計師在設計的過程中避免一些不能輸出的數據排版，指出哪一些陰影、透明、圓角的使用不能大範圍的使用等等；在進行頁面的重構的過程中，又將以一個設計師的身份將設置頁面轉化爲靜態頁面，需要用代碼對設計頁面進行最初的還原，實現好相應的前臺的效果，排列好相應讓後臺開發的工程師輸出數據的地方，以適應後臺數據的輸出並保持頁面的不變形、不走位，在有數據輸出正常的情況下，配合程序去修改樣式，以儘量達到和設計的效果基本一致。所以在這個頁面設計和到程序的現在過程中，需要前端工程師起到一個橋樑的作用。
前端開發是一項很特殊的工作，前端工程師的工作說得輕鬆，看似輕巧，但做起來絕對不是那麼的簡單。在開發過程中涵蓋的東西非常寬廣，既要從技術的角度來思考界面的實現，規避技術的死角，又要從用戶的角度來思考，怎樣才能更好地接受技術呈現的枯燥的數據，更好的呈現信息。簡單地說，它的主要職能就將網站的數據和用戶的接受更好地結合在一起，爲用戶呈現一個友好的數據界面。
二、前端工程師的發展前景如何
前端工程師是是一個很新的職業，在國內乃至國際上真正開始受到重視的時間不超過5年。互聯網的發展速度迅猛，網頁由WEB1.0到WEB2.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)指的是層疊樣式表，現在普遍在用的版本是css2.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（或其他數據）可以內嵌在p_w_picpath標籤的屬性當中（或者CSS中或JavaScript中），通過對圖片進行base64編碼，可以實現將圖片直接嵌入代碼中的目的，如此一來，可以減少HTTP請求，這對於提升web性能很有好處。對於較小的圖片，採用這樣處理是非常實用的，但是IE６、７不能支持這種方法，因此可以在IE6、７中採用傳統的方法，而在其他瀏覽器中使用這樣的方法來進行全面的兼容。
這種做法有利有弊，好處是可以減少HTTP請求，不好的地方是圖像的大小會增加1/3。因此，這種內嵌的方法適合對小的圖形、小圖標等進行處理，從而減少瀏覽器打開的連接數，但對大的照片、圖片等則不應該使用base64編碼了，以免影響圖像下載的時間。
但這種圖像的處理也需要另外的軟件，所以不熟悉的情況下操作起來也有一定的困難，這裏有一個在線版的轉換工具，有興趣的大家可以試試，嚐嚐鮮：點擊打開
當然這些都是更深一點的應用了，我也在學習當中，無法再作更深入的論述了，大家可以自行進行擴展。當然，我也樂於分享你們的觀點。
擴展閱讀：《Data URI scheme》
更多的圖片的格式可以查看一篇老外的文章，也有人進行了介紹：
《Tips for choosing a cache p_w_picpath format 》
《The difference between PNG24 and PNG32》
外文不太好的也可以看這裏，有人進行了相應的概括：
淘寶UED： 《圖片格式與設計那點事兒》
尹延超：《 PNG詳解》
6.2如何輸出合適的圖片
說了這麼多的圖片格式相關的知識，現在要實際操作來說明一下我們怎樣輸出一個適合我們的圖片了。
其實淘寶UED： 《圖片格式與設計那點事兒》這裏也說明得夠詳細了，這裏就不重複裏面的一些方法了。我們最常用的圖像處理軟件莫過於Firework和Photoshop，所以我們也以這兩個軟件就重點。雖然兩個軟件現在是同出一家，同屬一個Adobe Master套裝，但兩者的算法還是有一定的差別的。所以在做圖片處理的時候有時候可以在這兩個軟件中分別進行輸出對比來決定最後圖片的使用。
注：本文使用的是Adobe Master CS4開發套裝的，其他的版本沒測，已知的是Firework8中圖片輸出的算法也沒有Firework CS4的好，具體可以親測。
這裏不再進行深入的論述，大家清楚了上面的格式的差別和軟件的問題後，在具體的工作中通過不停的比較就能得出上面這些結論。
JavaScript：
因本人也是JS菜鳥一個，也正在努力學習的階段，沒法跟大家深入的講JavaScript的一些核心代碼分析什麼的，所以講一些無關緊要的所謂的理論問題。
頁面除了數據層的html、展示層的css，還有一個動畫和交互層的腳本，那就是JavaScript。JavaScript可以說是目前Web開發中一個非常流行的語言了，如果一個前端工程師能夠精通此語言，就單一項語言也能成就一份非常不錯的工作。
相信大家對之前google裏的那個用JavaScript做的紀念瑪莎·葛蘭姆的動畫還不會陌生，點擊此處觀看，這個用JavaScript配合圖像定位做成的動畫，展示了JavaScript的強大功能。
現在Prototype、JQuery、Mootools、Dojo、Extjs等的框架，各種各樣的基於js框架開發的插件方便我們的開發，大大的熱縮短了我們學習的週期，簡化了前端的開發，加快了開發速度，同時避免各類瀏覽器的兼容性問題。目前前端開發者使用JS框架是種很普遍的現象，但是我們的開發應該按需要