網(wǎng)站建設(shè)的時(shí)候采用的語言有很多，大面上我們看就是動(dòng)態(tài)站和靜態(tài)站。而今天筆者小丹要和大家分享的這篇文章就是關(guān)于網(wǎng)站建設(shè)中的技術(shù)補(bǔ)充AngularJS，它是基于HTML語言上的一種彌補(bǔ)。

    AngularJS是為了克服HTML在構(gòu)建應(yīng)用上的不足而設(shè)計(jì)的。HTML是一門很好的為靜態(tài)文本展示設(shè)計(jì)的聲明式語言，但要構(gòu)建WEB應(yīng)用的話它就顯得乏力了。所以我做了一些工作來讓瀏覽器做我想要的事。

    之前的時(shí)間中，當(dāng)我的代碼開始變得混亂和jQuery選擇器和回調(diào)AngularJS來到我的救援。

    Angular幫我的可維護(hù)性開發(fā)項(xiàng)目，它有很多的開箱即用的功能。這是用工具加工為構(gòu)建大規(guī)模的網(wǎng)絡(luò)應(yīng)用，極大地促進(jìn)快速發(fā)展在這種類型的應(yīng)用程序。

    我記得它的雙向綁定和模型的哲學(xué)真理的單一來源令我始料未及。在實(shí)踐中他們?cè)谖业膽?yīng)用程序減少了數(shù)據(jù)冗余。隨著時(shí)間的推移我發(fā)現(xiàn)一些角痛點(diǎn)。最終他們足夠讓我失望，我開始尋找替代品。這是我和角的擔(dān)憂。

    DOM來執(zhí)行。Angular嚴(yán)重依賴于DOM的執(zhí)行流，在角的默認(rèn)引導(dǎo)程序，掃描DOM并編譯指令的優(yōu)先權(quán)，這使得它難以調(diào)試和測(cè)試的執(zhí)行順序。

    雙向綁定是一把雙刃劍。隨著組件的復(fù)雜性增加，這種方法可能會(huì)導(dǎo)致性能問題。

    雙向綁定如何影響性能JavaScript(ES5)沒有任何實(shí)現(xiàn)通知任何更改的變量或?qū)ο?，所以角使用所謂的“臟檢查”來跟蹤數(shù)據(jù)變化和同步的用戶界面(UI)。

    “臟檢查”進(jìn)行Angular的范圍內(nèi)執(zhí)行任何操作后($digest周期)導(dǎo)致較慢的性能隨著綁定的數(shù)量增加。

    雙向綁定的另一個(gè)問題是許多組件在頁面上可以變化的數(shù)據(jù)，這意味著有多個(gè)來源的數(shù)據(jù)輸入。如果沒有管理好這可能會(huì)導(dǎo)致混亂和擁擠的情況。公平地說，這是一個(gè)實(shí)現(xiàn)的問題而不是一個(gè)角問題本身。

    Angular都有自己的世界。每個(gè)操作在角必須經(jīng)過消化周期否則你的組件不會(huì)與你同步數(shù)據(jù)模型，這導(dǎo)致兼容性問題與其他依賴項(xiàng)。

    如果您使用任何第三方JavaScript庫(kù)包括數(shù)據(jù)更改，你需要將它與角的$apply功能?；蛘吣阈枰獙⑺D(zhuǎn)換成一個(gè)服務(wù)，如果它是一個(gè)實(shí)用程序庫(kù)。這就像要重塑每個(gè)JavaScript庫(kù)使用為了它與角進(jìn)行互操作。依賴注入，JavaScript目前沒有包管理器和依賴自己的解析器。AMD、UMD格式和CommonJS已經(jīng)解決這一差距。但是直到最近角不玩這些。相反它引入了一個(gè)自己的依賴注入(DI)。不過，公平地說有非官方使用RequireJS角依賴項(xiàng)注入的實(shí)現(xiàn)。

    陡峭的學(xué)習(xí)曲線，使用Angular需要學(xué)習(xí)大量的概念包括但不限于：

    模塊

    控制器

    指令

    作用域

    模板

    連接功能

    過濾器

    依賴注入

    它可以用角開始是非常困難的，這不是一時(shí)的事。所有這一切讓我做出反應(yīng)。

    反應(yīng)新的開源框架可用來構(gòu)建用戶界面，是一個(gè)不同的方式開發(fā)JavaScript應(yīng)用程序。反應(yīng)是由Facebook和Instagram。需要明確的是：反應(yīng)并不像AngularJS這樣的應(yīng)用程序開發(fā)框架。這不公平比較一分之二的標(biāo)準(zhǔn)方式。當(dāng)反應(yīng)介紹了JSConf歐盟在2013年5月。觀眾感到震驚的一些概念如“單向數(shù)據(jù)流”和“虛擬DOM”。

    反應(yīng)是構(gòu)建用戶界面。換句話說，直接從官方的著陸頁的項(xiàng)目：“人們使用MVC的V的反應(yīng)?！辈贿^您可以編寫?yīng)毩⒌慕M件。這或多或少比較角指令。反應(yīng)審視我們當(dāng)前的web開發(fā)的概念和最佳實(shí)踐。

    例如，它鼓勵(lì)單向數(shù)據(jù)流和哲學(xué)認(rèn)為組件狀態(tài)機(jī)由數(shù)據(jù)驅(qū)動(dòng)的。而大多數(shù)的其他類似框架愛使用DOM和直接操作，反應(yīng)討厭DOM和工作保護(hù)開發(fā)人員。提供反應(yīng)所需的最低限度的API定義UI組件。不多不少，它遵循UNIX哲學(xué)：小就是美。做一件事做到最好。

    你可以找到更詳細(xì)比較角與反應(yīng)皮特·亨特(在Facebook工作/ Instagram)。反應(yīng)快采用不同的方法反應(yīng)DOM相比其他框架。它不會(huì)讓你直接使用DOM。它引入了一個(gè)層，稱為虛擬DOM,您的JavaScript邏輯與實(shí)際的DOM。

    這一概念將提高網(wǎng)絡(luò)性能。連續(xù)呈現(xiàn)，執(zhí)行一個(gè)微分反應(yīng)(diff)虛擬DOM,然后只更新需要更新的部分實(shí)際DOM。

    跨瀏覽器兼容性：虛擬DOM也有助于解決跨瀏覽器的問題，因?yàn)樗鼮槲覀兲峁┝艘粋€(gè)標(biāo)準(zhǔn)化的API，甚至早在IE8。

    模塊化：編寫?yīng)毩⒌哪K化應(yīng)用程序的UI組件，從而隔離問題只對(duì)有問題的組件/s。每個(gè)組件都可以獨(dú)立開發(fā)和測(cè)試，并且他們可以使用其他組件。這相當(dāng)于可維護(hù)性的改進(jìn)。

    單向數(shù)據(jù)流讓事情更理智，通量是一個(gè)架構(gòu)在JavaScript應(yīng)用程序中創(chuàng)建單向數(shù)據(jù)層。這是概念化的Facebook以及查看圖書館的反應(yīng)。通量的概念使得大規(guī)模應(yīng)用開發(fā)更簡(jiǎn)單。通量是一個(gè)概念而不是一個(gè)特定工具實(shí)現(xiàn)。它可以納入其他框架。例如，亞歷克斯Rattray不錯(cuò)通量的實(shí)現(xiàn)在反應(yīng)中使用骨干收集和模型。

    只是JavaScript，現(xiàn)代web應(yīng)用程序工作在不同的方式比傳統(tǒng)的web。例如，視圖層與用戶交互而不需要更新服務(wù)器。因此視圖和控制器需要依賴彼此。車把或胡子等許多其他框架使用模板引擎來處理視圖層。但反應(yīng)相信視圖和控制器相互依存，他們必須駐留在一個(gè)地方不使用任何第三方的模板引擎，而且最重要的是，不離開了JavaScript的范圍。

    同構(gòu)JavaScript，單頁JS web應(yīng)用程序的最大的缺點(diǎn)是，當(dāng)被搜索引擎爬行的局限性。反應(yīng)有一個(gè)解決方案。反應(yīng)可以在發(fā)送之前pre-render應(yīng)用服務(wù)器上的用戶代理。它可以將同樣的狀態(tài)恢復(fù)到預(yù)渲染靜態(tài)內(nèi)容的動(dòng)態(tài)應(yīng)用程序在服務(wù)器上。因?yàn)樗阉饕媾老x依賴服務(wù)器響應(yīng),而不是JavaScript執(zhí)行預(yù)呈現(xiàn)應(yīng)用程序有助于搜索引擎優(yōu)化。

    它與他人裝載機(jī)和籌款人喜歡RequireJS,Browserify和Webpack急需當(dāng)你構(gòu)建大型應(yīng)用程序。他們可戰(zhàn)勝的艱巨任務(wù)。不幸的是當(dāng)前版本的JavaScript模塊不提供打包機(jī)或加載程序。而幸運(yùn)的是我們有一些替代品如RequireJS和Webpack，漂亮整潔。建立與Browserify反應(yīng)，但如果你想注入資產(chǎn)和編譯形象少或CoffeeScript然后可能Webpack是更好的選擇。關(guān)鍵是：你提供這種選擇。

    使用反應(yīng)您可以構(gòu)建用戶界面，但你仍然需要AJAX調(diào)用應(yīng)用數(shù)據(jù)過濾器和其他角已經(jīng)做的事情。因此，如果我們需要一個(gè)額外的JavaScript應(yīng)用程序開發(fā)框架?？蚣苁且唤M模塊和規(guī)則。如果我不需要它的一些模塊或想換出一個(gè)模塊對(duì)另一個(gè)更好的工作。我怎么做的一種方式更好地實(shí)現(xiàn)模塊化和依賴關(guān)系管理是通過計(jì)劃經(jīng)理。

    但是，我們?nèi)绾喂芾戆怯赡銢Q定但知道角都有自己的世界。你將最有可能需要適應(yīng)第三方包角的世界。反應(yīng)另一方面，只是JavaScript，任何JavaScript編寫的包不需要任何包裝的反應(yīng)。

    對(duì)我來說，使用包經(jīng)理喜歡npm和鮑爾更好。我們可以選擇我們的組件和工藝自定義工具集。需要明確的是：這是更復(fù)雜的比只使用一個(gè)全面的應(yīng)用程序開發(fā)框架角。

    在這方面的可取之處是，鼓勵(lì)使用npm的反應(yīng)這有很多現(xiàn)成的軟件包。與反應(yīng)開始構(gòu)建應(yīng)用程序，你可以。例如，使用其中之一完整的配套。切換到反應(yīng)不是無痛。由于Angular是一個(gè)應(yīng)用程序開發(fā)框架，它有很多好處。我放棄和AJAX的包裝一樣偉大的功能$http服務(wù)、$q承諾服務(wù)、ng-show、ng-hide、ng-class、ng-if作為模板，所有的控制語句神奇的東西。

    反應(yīng)不是應(yīng)用程序開發(fā)框架所以你需要考慮如何處理構(gòu)建應(yīng)用程序的其他方面。例如，我正在一個(gè)開源項(xiàng)目react-utils可用于緩解發(fā)展的反應(yīng)。社區(qū)也積極貢獻(xiàn)填空類似的可重用的組件，可以這么說。反應(yīng)組件是一個(gè)非官方的目錄網(wǎng)站你可以找到這樣的開源組件。

    反應(yīng)的哲學(xué)并不鼓勵(lì)你使用雙向綁定，這帶來了很多的痛苦當(dāng)你處理表單元素和可編輯的數(shù)據(jù)網(wǎng)格。然而，當(dāng)你開始理解通量數(shù)據(jù)流和商店，事情就變得更清晰更簡(jiǎn)單和容易。反應(yīng)是新的，這將需要一些時(shí)間它周圍的社區(qū)成長(zhǎng)。Angular另一方面，已經(jīng)獲得了巨大的人氣相對(duì)大量可用的擴(kuò)展(例如AngularUI和Restangular)。

    然而，盡管社區(qū)的新反應(yīng)它正在快速成長(zhǎng)。擴(kuò)展像反應(yīng)引導(dǎo)是一個(gè)很好的證明，這只是一個(gè)時(shí)間問題我們有了更多的可用組件。

     (轉(zhuǎn)載請(qǐng)注明轉(zhuǎn)自：flw114.cn/news/n1588.htm，謝謝!珍惜別人的勞動(dòng)成果，就是在尊重自己!）