【譯】當不使用JavaScript框架時

blair 發布于2019-08-20 18:26 / 3107人閱讀

摘要：在其他方面，我們只需要考慮針對特定任務時所使用框架的成本。當我們必須使用或不應該使用框架時我強烈主張要了解編寫某個工具的目的。

非常有價值的建議：哪些框架是合理的，哪些并不合理。

作者：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元素，但是這對頁面加載時間產生了明顯的影響?，F在思考一下下面的案例：

// 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工作。

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

云服務器 GPU云服務器大數據實時分析框架 javascript框架 javascript框架分類 javascript開源框架

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/84509.html

2017-07-31 前端日報

摘要：前端日報精選中的組件通信問題詳解頁面的渲染過程面試中問什么問題加實現圖片前端壓縮并上傳用畫一個迷宮中文譯當不使用框架時瘋狂的技術宅在翻譯面向編程連續改造個網頁掘金周刊技術周刊期知乎專欄技術周刊包管理的前世今生眾成翻譯版發布 2017-07-31 前端日報精選 React中的組件通信問題詳解 Weex 頁面的渲染過程面試中問什么React問題？HTML5 file API加canvas...

shadowbook 2019-08-20 18:26 評論0 收藏0
【譯】發送表單數據

摘要：若該特性未指定，則數據會發送到包含該表單的頁面所在的。其中使用了來處理表單數據。特殊案例發送文件文件是表單中一個特殊的例子，其他數據都是文本數據，而文件則一般是或者被認為是二進制數據。系列文章說明原文多數時候，HTML表單的目的只是為了把數據發給服務器，之后服務器再處理這些數據并發送響應給用戶。雖然看起來挺簡單的，但我們還是得注意一些事情以確保傳送的數據不會破壞服務器、或者給...

Eidesen 2019-08-01 15:45 評論0 收藏0
【譯】 WebSocket 協議第十章——安全性考慮（Security Considerations

摘要：概述本文為協議的第九章，本文翻譯的主要內容為安全性相關內容。安全性考慮協議正文這一章描述了一些協議的可用的安全性考慮。連接保密性和完整性連接保密性是基于運行的協議的。使用一個合適的狀態碼的關閉幀有助于診斷這個問題。概述本文為 WebSocket 協議的第九章，本文翻譯的主要內容為 WebSocket 安全性相關內容。 10 安全性考慮（協議正文）這一章描述了一些 WebSocke...

darkerXi 2019-08-23 15:20 評論0 收藏0
【譯】 WebSocket 協議第十章——安全性考慮（Security Considerations

摘要：概述本文為協議的第九章，本文翻譯的主要內容為安全性相關內容。安全性考慮協議正文這一章描述了一些協議的可用的安全性考慮。連接保密性和完整性連接保密性是基于運行的協議的。使用一個合適的狀態碼的關閉幀有助于診斷這個問題。概述本文為 WebSocket 協議的第九章，本文翻譯的主要內容為 WebSocket 安全性相關內容。 10 安全性考慮（協議正文）這一章描述了一些 WebSocke...

MasonEast 2019-08-23 15:19 評論0 收藏0
[譯]JSX：硬幣的另一面

摘要：它不過是硬幣的另一面。因此，既然我們能夠接受與通過這種方式混合在一塊兒，那么是時候讓介入并向我們展示硬幣的另一面了第三階段的并不是一個激進的改變，是因為我們這個行業從一開始就注定和應該是在一起的。 React框架剛剛發布的時候，JSX顛覆了很多人的想法。習慣了HTML標簽與JavaScript代碼分離的前端工程師們，看到JSX大概都會不禁吐槽：這些奇怪的標簽出現在JavaScript里...

mudiyouyou 2019-08-20 14:28 評論0 收藏0