|
|
在過去使用JavaScript庫的一個缺點是，庫往往相當大，也許包括不少在你的個人網頁中實際是不怎么使用的代碼。或許，編寫自己的代碼可以被認為是最能完全滿足你真正需求的方法，而且沒有其他比這更有效的方法了。但在引入Google的一個通用倉庫后，每個人都可用通過鏈接使用比較流行的JavaScript庫的時候，就否定了這種說法，因為如果你鏈接到的是Google的庫副本，而不是使用自己的副本，這樣大量訪客將會有已經緩沖在他們的瀏覽器上的庫，實際須下載的只是你頁面的一部分代碼而已。這樣做可以使得使用它比自己做的庫更快。
自己編寫代碼而非依賴于庫的一個優點是，你不用學太多東西。要能夠自寫JavaScript，你只需要學習JavaScript就可以了。而要能夠使用庫則需要同時學習JavaScript以及這個庫。你可能可以做到像這樣的事情，只學習庫而還沒有學習JavaScript，但就能夠利用的最好方式來使用這個庫，那你將需要比那些只是使用JavaScript來編寫自己代碼的典型的人要對JavaScript有更多的了解。
使用庫的優勢在于，庫已處理了你需要運行的90%的操作，這意味著你只需要編寫的余下10％。在有大量的代碼編寫的時候，這可以節省你編寫代碼的時間。而在除了編寫代碼，還需要對其進行測試的時候，它就可能會或可能不會節省時間了，除非你深入了解如何讓你所選的庫在測試時間做應該做的事，使用庫最終可能會比你自己寫代碼大大延長了時間。
另一件你要考慮的事是，在一個給定的庫中包含了多少代碼是你實現你想達到的目標將實際需要使用到的，以及庫實際上是否包括了所有你想要的操作。如果你不能找到一個有你所需的一切功能的庫，那么你就需要自己編寫其余的代碼或嘗試引入第二個包括了缺少的功能的庫。取決于庫是如何工作，將可能可以或可能不可以在相同的網頁中同時使用兩個庫。
事實上在你考慮使用庫之前，你需要自己寫多少JavaScript代碼也會影響你的決定。如果你已經自己寫了能執行所有你需要的不同函數的處理，則有可能打消你選用一個同樣提供所有這些相同功能但實現方式不同的庫的想法。鑒于這些首先寫這些庫的人一般都是對JavaScript具有深入了解的人，你必須承認的一個合理的可能性是，一個提供這些功能的庫比你自己寫的更有效率（除非你也有一個JavaScript專家）。
你要添加到網頁中的JavaScript處理是什么樣的類型，也將影響是否合適使用庫。如果你只把很小的特效到你的網頁，只需要幾行JavaScript代碼，那么比起自寫所有的代碼，用一個庫可能會導致你不得不編寫更多的代碼去作為實現庫工作方式的接口。當然，反過來同樣適應，如果你要添加到你的網頁中的處理是數量相當大的且與你選用的庫的功能類型密切匹配的，那么都可以讓庫為你處理。
選擇一個功能是密切符合你想要使用到你的網頁中的庫，并很好的理解JavaScript以及這個庫，那就可以快速和容易加入所有你想要的功能，以這種現代的不唐突的方式可能是最適合你的方法。另外，如果你已經寫了多年的JavaScript，而且已經有你的能執行大多數你不斷要求的功能的代碼庫，那你就可以不必選擇和學習任何一個庫就達到相當的效果。
個人總結
個人覺得，Stephen Chapman的這篇文章很好的對比了JavaScript庫和自寫代碼的優缺點，其實，如果能夠在使用JavaScript庫的時候，充分的利用它，去實現它應有的價值，那JavaScript庫將會是一種很好的工具，一種創造富客戶端以及給用戶帶來良好體驗的一種工具，而非成為加載頁面時的一種額外的負擔。而對于喜歡自寫代碼的人，我覺得也有必要將一些功能，有如DOM操作和事件處理封裝起來，畢竟原生的JavaScript在不同的瀏覽器存在著較多兼容問題和效率問題（可參考 阿當的《JavaScript分層概念》）。同時我還覺得，如果在使用一個流行的JavaScript庫（如jQuery、YUI、Ext JS）的時候，能去了解一下這些庫的實現機制，這樣才能更好的駕馭這些庫！
中文由維奇翻譯，如有轉載請注明出處，翻譯如有錯漏歡迎留言指出
JavaScript技術：使用JavaScript庫還是自己寫代碼？，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
