你必須做出決定以這兩種方法中的哪一種來寫你的JavaScript，為了幫助您作出明智的決定哪個更適合你，我們將對比一下這兩種方法的一些優(yōu)劣。

　　在過去使用JavaScript庫的一個缺點是，庫往往相當大，也許包括不少在你的個人網(wǎng)頁中實際是不怎么使用的代碼?；蛟S，編寫自己的代碼可以被認為是最能完全滿足你真正需求的方法，而且沒有其他比這更有效的方法了。但在引入Google的一個通用倉庫后，每個人都可用通過鏈接使用比較流行的JavaScript庫的時候，就否定了這種說法，因為如果你鏈接到的是Google的庫副本，而不是使用自己的副本，這樣大量訪客將會有已經(jīng)緩沖在他們的瀏覽器上的庫，實際須下載的只是你頁面的一部分代碼而已。這樣做可以使得使用它比自己做的庫更快。

　　自己編寫代碼而非依賴于庫的一個優(yōu)點是，你不用學太多東西。要能夠自寫JavaScript，你只需要學習JavaScript就可以了。而要能夠使用庫則需要同時學習JavaScript以及這個庫。你可能可以做到像這樣的事情，只學習庫而還沒有學習JavaScript，但就能夠利用的最好方式來使用這個庫，那你將需要比那些只是使用JavaScript來編寫自己代碼的典型的人要對JavaScript有更多的了解。

　　使用庫的優(yōu)勢在于，庫已處理了你需要運行的90%的操作，這意味著你只需要編寫的余下10％。在有大量的代碼編寫的時候，這可以節(jié)省你編寫代碼的時間。而在除了編寫代碼，還需要對其進行測試的時候，它就可能會或可能不會節(jié)省時間了，除非你深入了解如何讓你所選的庫在測試時間做應該做的事，使用庫最終可能會比你自己寫代碼大大延長了時間。

　　另一件你要考慮的事是，在一個給定的庫中包含了多少代碼是你實現(xiàn)你想達到的目標將實際需要使用到的，以及庫實際上是否包括了所有你想要的操作。如果你不能找到一個有你所需的一切功能的庫，那么你就需要自己編寫其余的代碼或嘗試引入第二個包括了缺少的功能的庫。取決于庫是如何工作，將可能可以或可能不可以在相同的網(wǎng)頁中同時使用兩個庫。

　　事實上在你考慮使用庫之前，你需要自己寫多少JavaScript代碼也會影響你的決定。如果你已經(jīng)自己寫了能執(zhí)行所有你需要的不同函數(shù)的處理，則有可能打消你選用一個同樣提供所有這些相同功能但實現(xiàn)方式不同的庫的想法。鑒于這些首先寫這些庫的人一般都是對JavaScript具有深入了解的人，你必須承認的一個合理的可能性是，一個提供這些功能的庫比你自己寫的更有效率（除非你也有一個JavaScript專家）。

　　你要添加到網(wǎng)頁中的JavaScript處理是什么樣的類型，也將影響是否合適使用庫。如果你只把很小的特效到你的網(wǎng)頁，只需要幾行JavaScript代碼，那么比起自寫所有的代碼，用一個庫可能會導致你不得不編寫更多的代碼去作為實現(xiàn)庫工作方式的接口。當然，反過來同樣適應，如果你要添加到你的網(wǎng)頁中的處理是數(shù)量相當大的且與你選用的庫的功能類型密切匹配的，那么都可以讓庫為你處理。

　　選擇一個功能是密切符合你想要使用到你的網(wǎng)頁中的庫，并很好的理解JavaScript以及這個庫，那就可以快速和容易加入所有你想要的功能，以這種現(xiàn)代的不唐突的方式可能是最適合你的方法。另外，如果你已經(jīng)寫了多年的JavaScript，而且已經(jīng)有你的能執(zhí)行大多數(shù)你不斷要求的功能的代碼庫，那你就可以不必選擇和學習任何一個庫就達到相當?shù)男Ч?

個人總結

　　個人覺得，Stephen Chapman的這篇文章很好的對比了JavaScript庫和自寫代碼的優(yōu)缺點，其實，如果能夠在使用JavaScript庫的時候，充分的利用它，去實現(xiàn)它應有的價值，那JavaScript庫將會是一種很好的工具，一種創(chuàng)造富客戶端以及給用戶帶來良好體驗的一種工具，而非成為加載頁面時的一種額外的負擔。而對于喜歡自寫代碼的人，我覺得也有必要將一些功能，有如DOM操作和事件處理封裝起來，畢竟原生的JavaScript在不同的瀏覽器存在著較多兼容問題和效率問題（可參考 阿當?shù)摹禞avaScript分層概念》）。同時我還覺得，如果在使用一個流行的JavaScript庫（如jQuery、YUI、Ext JS）的時候，能去了解一下這些庫的實現(xiàn)機制，這樣才能更好的駕馭這些庫！



中文由維奇翻譯，如有轉載請注明出處，翻譯如有錯漏歡迎留言指出

最新評論