【譯】當不使用JavaScript框架時

很是有價值的建議：哪些框架是合理的，哪些並不合理。

做者：Tod Hansmann
來源：https://opensource.com/articl...
翻譯：瘋狂的技術宅
說明：本專欄文章首發於公衆號：jingchengyideng 。

Image by : opensource.com

隨着互聯網的發展，網絡發展已經遠遠超出了預期——不論是好的仍是壞的方面。爲了打磨粗糙的細節，web開發人員發明了大量的框架，既有小巧又的也有不那麼小巧的。這對開發人員來講是一件好事，由於瀏覽器的碎片化和標準問題比比皆是，特別是對於那些想要新的API功能和更多統一語法的用戶而言。此外大多數框架都是開源的，這對每一個人都是有好處的。

如今能夠看到這些粗糙的細節已經隨着時間被逐漸打磨掉掉，再也不像之前那麼尖銳了，因此咱們應該適當的減小一些框架的使用。在其餘方面，咱們只須要考慮針對特定任務時所使用框架的成本。

一些事情能夠本身來作

考慮一下簡單的HTTP請求，曾經是一段50行的函數，就能夠在 Firefox 和 Internet Explorer 中完成簡單的GET搞做。舉個例子，這裏有一個簡單的函數能夠完成POST操做；咱們曾經在網站 Phone Janitor（網址：https://phonejanitor.com/ ）的生產環境下使用它超過一年，並把它做爲React的主用數據泵：

function postMe(name, data, callback, onError) {
    var request = new XMLHttpRequest();
    request.onreadystatechange = function() {
        if (request.readyState != 4 || request.status != 200) { return; }
        var body = JSON.parse(request.responseText);
        if (body.error) {
            onError(body.error);
        }
        else {
            callback.(body);
        }
    };
    request.open("POST", '/api/' + name, true);
    request.setRequestHeader("Content-type", "application/json");
    request.send(JSON.stringify(data));
}

這段沒有使用任何框架的代碼能夠很容易的被重寫，而後很好的與Promise一塊兒工做，並可以適應新的請求類型，或者能夠支持任何對你的應用相當重要的功能。它的設計是否良好？也許不是。它是健壯的嗎？這僅僅是爲了咱們當前的須要。它的意義不在於它是或者是什麼，而更多須要思考的是我爲何要使用其餘的框架。

若是我不想編寫本身的HTTP請求引擎，也會有不少選擇。不過它們都是有代價的。它們有多大？我該怎樣在本身的代碼中包含它們，以及它是如何影響個人工做流程的？他們還作了哪些沒必要要的事情消耗了時間？若是我花了一個小時（這是咱們花在代碼和測試上的時間）來實現這個功能以知足我全部的需求，那麼與集成一個庫來來實現一樣的功能相比，會節省不少時間嗎？對此咱們每一個人都會有不一樣的答案。

全部人的一切問題

咱們使用服務（services）來知足各類不一樣的需求。這纔是問題的癥結所在。爲了社區利益而統一API是一件好事，由於有些事情很微妙，很難單獨完成。jQuery之因此被編寫出來，是由於瀏覽器的差別性很是大，而 JavaScript API 對此能作的事情太少了。有一段時間，幾乎每一個Web開發人員都在使用 jQuery ，這樣他們可使用文檔對象模型（DOM）來處理簡單的innerHTML元素，可是這對頁面加載時間產生了明顯的影響。如今思考一下下面的案例：

// Author's note, this is mostly for example, 
// don't manipulate DOM unless you know what 
// that means for your app

var el1 = document.getElementById(id_Name);
var el2 = document.getElementsByClass(class_Name); // returns array
var el3 = document.querySelector("div.user-panel.main input[name='login']");

// Want it in a jquery style function name?

var $ = document.querySelector; // Or get fancier if you wish
var el4 = $("div.user-panel.main input[name='login']");

直到如今咱們仍然在普遍使用 jQuery (例如:通常的WordPress主題)。不要隨意相信我說的話，你能夠本身去看看究竟是不是這樣。若是沒有它們，咱們幾乎什麼也作不了。

即便咱們使用框架

這不只僅是咱們如何以及什麼時候使用框架的問題；它還涉及到咱們如何處理特性和附加組件。例如，例如，將 Google Visualization 集成到 Angular 框架中。在 MobilSense ，咱們嚴重依賴圖表向管理團隊提供報告——但咱們也使用Angular 1.5。那麼怎樣作才能把新功能集成到咱們的應用程序的圖表中呢？

咱們能夠選擇 angular-google-chart 或開發本身的解決方案庫。雖然 angular-google-chart是一個很棒的庫，我在其餘地方也使用過它，同時很感激做者貢獻他的免費項目——可是因爲一些顯而易見的緣由，咱們本身實現了相關的功能庫——如下是他們的特徵對比:

Angular-Google-Charts	咱們本身的庫
20個源碼文件	1個源碼文件
平均每一個文件約40行代碼	包括註釋在內的81行代碼(遺憾的是，沒有太多的註釋)
被npm集成到angular中	不是一個包，不依賴任何東西，它只是另外一個指令

咱們本身的解決方案並不處理全部狀況，也並不須要處理這些狀況，若是一旦須要，咱們能夠很容易地擴充它們，而且以某種方式移植到咱們的工做流和其餘框架中。這是咱們每一個人都須要根據本身的具體需求作出的權衡。這兩種選擇都不丟人。

當咱們必須使用或不該該使用框架時

我強烈主張要了解編寫某個工具的目的。若是咱們的目標是一種暫時的、須要快速拼湊的東西，那麼可能並不須要將其工程化。可是若是是須要被長久使用的東西，我認爲使用框架工具是更合適的。一個框架一經使用便很難擺脫，特別是假如咱們添加了一些庫，這將進一步把咱們和這個框架綁定在一塊兒。

若是隻有要一兩天的時間來編寫本身的解決方案，我就會傾向於這樣作。若是有一週或更長的時間，我也許會改變本身的主意。

另一個本身編寫的庫的理由是，使本身的項目依賴一個可能不適合你的項目生命週期的框架，代價是很昂貴的。可是，若是你要作的是一件很是複雜的事情，好比集成PDF支持，那麼您可能徹底不肯意考慮本身編寫，由於這會把你逼瘋。

與任何類型的軟件工程同樣，把您的工做看做是在修建一棟建築。假如你是在造一個狗窩，實際上不管怎樣均可能很好。可是若是你正在修建摩天大樓，那麼就必須作更多的規劃。咱們應該在哪裏畫一條線？框架的做用與你正在使用建築材料和建築風格的做用是同樣的。它是否適合環境，之後能夠在須要時替換材料嗎？雖然怎樣作出決定是你本身的事情，可是我但願這些信息和例子可以幫到你。

---

關於做者：

Tod Hansmann - 託德·漢斯曼（Tod Hansmann）是一名技術專家，他是一名程序員，並指導新人，關注着經常被當今技術愛好者忽視的舊的開發方式。同時也是一名軟件架構師，成天都在解決問題。在他看來，開源是解決問題的最佳工具。他目前在Phonejanitor.com工做。

---

歡迎掃描二維碼關注公衆號，天天推送我翻譯的技術文章。