摘要:在其他方面,我們只需要考慮針對(duì)特定任務(wù)時(shí)所使用框架的成本。當(dāng)我們必須使用或不應(yīng)該使用框架時(shí)我強(qiáng)烈主張要了解編寫某個(gè)工具的目的。
非常有價(jià)值的建議:哪些框架是合理的,哪些并不合理。
作者:Tod Hansmann
來(lái)源:https://opensource.com/articl...
翻譯:瘋狂的技術(shù)宅
說(shuō)明:本專欄文章首發(fā)于公眾號(hào):jingchengyideng 。
Image by : opensource.com
隨著互聯(lián)網(wǎng)的發(fā)展,網(wǎng)絡(luò)發(fā)展已經(jīng)遠(yuǎn)遠(yuǎn)超出了預(yù)期——不管是好的還是壞的方面。為了打磨粗糙的細(xì)節(jié),web開(kāi)發(fā)人員發(fā)明了大量的框架,既有小巧又的也有不那么小巧的。這對(duì)開(kāi)發(fā)人員來(lái)說(shuō)是一件好事,因?yàn)闉g覽器的碎片化和標(biāo)準(zhǔn)問(wèn)題比比皆是,特別是對(duì)于那些想要新的API功能和更多統(tǒng)一語(yǔ)法的用戶而言。此外大多數(shù)框架都是開(kāi)源的,這對(duì)每個(gè)人都是有好處的。
現(xiàn)在可以看到這些粗糙的細(xì)節(jié)已經(jīng)隨著時(shí)間被逐漸打磨掉掉,不再像以前那么尖銳了,所以我們應(yīng)該適當(dāng)?shù)臏p少一些框架的使用。在其他方面,我們只需要考慮針對(duì)特定任務(wù)時(shí)所使用框架的成本。
一些事情可以自己來(lái)做考慮一下簡(jiǎn)單的HTTP請(qǐng)求,曾經(jīng)是一段50行的函數(shù),就可以在 Firefox 和 Internet Explorer 中完成簡(jiǎn)單的GET搞作。舉個(gè)例子,這里有一個(gè)簡(jiǎn)單的函數(shù)可以完成POST操作;我們?cè)?jīng)在網(wǎng)站 Phone Janitor(網(wǎng)址:https://phonejanitor.com/ )的生產(chǎn)環(huán)境下使用它超過(guò)一年,并把它作為React的主用數(shù)據(jù)泵:
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)); }
這段沒(méi)有使用任何框架的代碼可以很容易的被重寫,然后很好的與Promise一起工作,并能夠適應(yīng)新的請(qǐng)求類型,或者可以支持任何對(duì)你的應(yīng)用至關(guān)重要的功能。它的設(shè)計(jì)是否良好?也許不是。它是健壯的嗎?這僅僅是為了我們當(dāng)前的需要。它的意義不在于它是或者是什么,而更多需要思考的是我為什么要使用其他的框架。
如果我不想編寫自己的HTTP請(qǐng)求引擎,也會(huì)有很多選擇。不過(guò)它們都是有代價(jià)的。它們有多大?我該怎樣在自己的代碼中包含它們,以及它是如何影響我的工作流程的?他們還做了哪些不必要的事情消耗了時(shí)間?如果我花了一個(gè)小時(shí)(這是我們花在代碼和測(cè)試上的時(shí)間)來(lái)實(shí)現(xiàn)這個(gè)功能以滿足我所有的需求,那么與集成一個(gè)庫(kù)來(lái)來(lái)實(shí)現(xiàn)同樣的功能相比,會(huì)節(jié)省很多時(shí)間嗎?對(duì)此我們每個(gè)人都會(huì)有不同的答案。
所有人的一切問(wèn)題我們使用服務(wù)(services)來(lái)滿足各種不同的需求。這才是問(wèn)題的癥結(jié)所在。為了社區(qū)利益而統(tǒng)一API是一件好事,因?yàn)橛行┦虑楹芪⒚?,很難多帶帶完成。jQuery之所以被編寫出來(lái),是因?yàn)闉g覽器的差異性非常大,而 JavaScript API 對(duì)此能做的事情太少了。有一段時(shí)間,幾乎每個(gè)Web開(kāi)發(fā)人員都在使用 jQuery ,這樣他們可以使用文檔對(duì)象模型(DOM)來(lái)處理簡(jiǎn)單的innerHTML元素,但是這對(duì)頁(yè)面加載時(shí)間產(chǎn)生了明顯的影響?,F(xiàn)在思考一下下面的案例:
// 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"]");
直到現(xiàn)在我們?nèi)匀辉趶V泛使用 jQuery (例如:一般的WordPress主題)。不要隨意相信我說(shuō)的話,你可以自己去看看到底是不是這樣。如果沒(méi)有它們,我們幾乎什么也做不了。
即使我們使用框架這不僅僅是我們?nèi)绾我约昂螘r(shí)使用框架的問(wèn)題;它還涉及到我們?nèi)绾翁幚硖匦院透郊咏M件。例如,例如,將 Google Visualization 集成到 Angular 框架中。在 MobilSense ,我們嚴(yán)重依賴圖表向管理團(tuán)隊(duì)提供報(bào)告——但我們也使用Angular 1.5。那么怎樣做才能把新功能集成到我們的應(yīng)用程序的圖表中呢?
我們可以選擇 angular-google-chart 或開(kāi)發(fā)自己的解決方案庫(kù)。雖然 angular-google-chart是一個(gè)很棒的庫(kù),我在其他地方也使用過(guò)它,同時(shí)很感激作者貢獻(xiàn)他的免費(fèi)項(xiàng)目——但是由于一些顯而易見(jiàn)的原因,我們自己實(shí)現(xiàn)了相關(guān)的功能庫(kù)——以下是他們的特征對(duì)比:
Angular-Google-Charts | 我們自己的庫(kù) |
---|---|
20個(gè)源碼文件 | 1個(gè)源碼文件 |
平均每個(gè)文件約40行代碼 | 包括注釋在內(nèi)的81行代碼(遺憾的是,沒(méi)有太多的注釋) |
被npm集成到angular中 | 不是一個(gè)包,不依賴任何東西,它只是另一個(gè)指令 |
我們自己的解決方案并不處理所有情況,也并不需要處理這些情況,如果一旦需要,我們可以很容易地?cái)U(kuò)充它們,并且以某種方式移植到我們的工作流和其他框架中。這是我們每個(gè)人都需要根據(jù)自己的具體需求做出的權(quán)衡。這兩種選擇都不丟人。
當(dāng)我們必須使用或不應(yīng)該使用框架時(shí)我強(qiáng)烈主張要了解編寫某個(gè)工具的目的。如果我們的目標(biāo)是一種暫時(shí)的、需要快速拼湊的東西,那么可能并不需要將其工程化。但是如果是需要被長(zhǎng)久使用的東西,我認(rèn)為使用框架工具是更合適的。一個(gè)框架一經(jīng)使用便很難擺脫,特別是假如我們添加了一些庫(kù),這將進(jìn)一步把我們和這個(gè)框架綁定在一起。
如果只有要一兩天的時(shí)間來(lái)編寫自己的解決方案,我就會(huì)傾向于這樣做。如果有一周或更長(zhǎng)的時(shí)間,我也許會(huì)改變自己的主意。
另外一個(gè)自己編寫的庫(kù)的理由是,使自己的項(xiàng)目依賴一個(gè)可能不適合你的項(xiàng)目生命周期的框架,代價(jià)是很昂貴的。但是,如果你要做的是一件非常復(fù)雜的事情,比如集成PDF支持,那么您可能完全不愿意考慮自己編寫,因?yàn)檫@會(huì)把你逼瘋。
與任何類型的軟件工程一樣,把您的工作看作是在修建一棟建筑。假如你是在造一個(gè)狗窩,實(shí)際上無(wú)論怎樣都可能很好。但是如果你正在修建摩天大樓,那么就必須做更多的規(guī)劃。我們應(yīng)該在哪里畫一條線?框架的作用與你正在使用建筑材料和建筑風(fēng)格的作用是一樣的。它是否適合環(huán)境,以后可以在需要時(shí)替換材料嗎?雖然怎樣做出決定是你自己的事情,但是我希望這些信息和例子能夠幫到你。
關(guān)于作者:
Tod Hansmann - 托德·漢斯曼(Tod Hansmann)是一名技術(shù)專家,他是一名程序員,并指導(dǎo)新人,關(guān)注著常常被當(dāng)今技術(shù)愛(ài)好者忽視的舊的開(kāi)發(fā)方式。同時(shí)也是一名軟件架構(gòu)師,整天都在解決問(wèn)題。在他看來(lái),開(kāi)源是解決問(wèn)題的最佳工具。他目前在Phonejanitor.com工作。
歡迎掃描二維碼關(guān)注公眾號(hào),每天推送我翻譯的技術(shù)文章。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/84509.html
摘要:前端日?qǐng)?bào)精選中的組件通信問(wèn)題詳解頁(yè)面的渲染過(guò)程面試中問(wèn)什么問(wèn)題加實(shí)現(xiàn)圖片前端壓縮并上傳用畫一個(gè)迷宮中文譯當(dāng)不使用框架時(shí)瘋狂的技術(shù)宅在翻譯面向編程連續(xù)改造個(gè)網(wǎng)頁(yè)掘金周刊技術(shù)周刊期知乎專欄技術(shù)周刊包管理的前世今生眾成翻譯版發(fā)布 2017-07-31 前端日?qǐng)?bào) 精選 React中的組件通信問(wèn)題詳解 Weex 頁(yè)面的渲染過(guò)程面試中問(wèn)什么React問(wèn)題?HTML5 file API加canvas...
摘要:若該特性未指定,則數(shù)據(jù)會(huì)發(fā)送到包含該表單的頁(yè)面所在的。其中使用了來(lái)處理表單數(shù)據(jù)。特殊案例發(fā)送文件文件是表單中一個(gè)特殊的例子,其他數(shù)據(jù)都是文本數(shù)據(jù),而文件則一般是或者被認(rèn)為是二進(jìn)制數(shù)據(jù)。 系列文章說(shuō)明 原文 多數(shù)時(shí)候,HTML表單的目的只是為了把數(shù)據(jù)發(fā)給服務(wù)器,之后服務(wù)器再處理這些數(shù)據(jù)并發(fā)送響應(yīng)給用戶。雖然看起來(lái)挺簡(jiǎn)單的,但我們還是得注意一些事情以確保傳送的數(shù)據(jù)不會(huì)破壞服務(wù)器、或者給...
摘要:概述本文為協(xié)議的第九章,本文翻譯的主要內(nèi)容為安全性相關(guān)內(nèi)容。安全性考慮協(xié)議正文這一章描述了一些協(xié)議的可用的安全性考慮。連接保密性和完整性連接保密性是基于運(yùn)行的協(xié)議的。使用一個(gè)合適的狀態(tài)碼的關(guān)閉幀有助于診斷這個(gè)問(wèn)題。 概述 本文為 WebSocket 協(xié)議的第九章,本文翻譯的主要內(nèi)容為 WebSocket 安全性相關(guān)內(nèi)容。 10 安全性考慮(協(xié)議正文) 這一章描述了一些 WebSocke...
摘要:概述本文為協(xié)議的第九章,本文翻譯的主要內(nèi)容為安全性相關(guān)內(nèi)容。安全性考慮協(xié)議正文這一章描述了一些協(xié)議的可用的安全性考慮。連接保密性和完整性連接保密性是基于運(yùn)行的協(xié)議的。使用一個(gè)合適的狀態(tài)碼的關(guān)閉幀有助于診斷這個(gè)問(wèn)題。 概述 本文為 WebSocket 協(xié)議的第九章,本文翻譯的主要內(nèi)容為 WebSocket 安全性相關(guān)內(nèi)容。 10 安全性考慮(協(xié)議正文) 這一章描述了一些 WebSocke...
摘要:它不過(guò)是硬幣的另一面。因此,既然我們能夠接受與通過(guò)這種方式混合在一塊兒,那么是時(shí)候讓介入并向我們展示硬幣的另一面了第三階段的并不是一個(gè)激進(jìn)的改變,是因?yàn)槲覀冞@個(gè)行業(yè)從一開(kāi)始就注定和應(yīng)該是在一起的。 React框架剛剛發(fā)布的時(shí)候,JSX顛覆了很多人的想法。習(xí)慣了HTML標(biāo)簽與JavaScript代碼分離的前端工程師們,看到JSX大概都會(huì)不禁吐槽:這些奇怪的標(biāo)簽出現(xiàn)在JavaScript里...
閱讀 1456·2021-09-22 15:43
閱讀 2171·2019-08-30 15:54
閱讀 1174·2019-08-30 10:51
閱讀 2096·2019-08-29 18:35
閱讀 439·2019-08-26 11:58
閱讀 2491·2019-08-26 11:38
閱讀 2450·2019-08-23 18:35
閱讀 3648·2019-08-23 18:33