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

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

    之前的時間中，當我的代碼開始變得混亂和jQuery選擇器和回調AngularJS來到我的救援。

    Angular幫我的可維護性開發(fā)項目，它有很多的開箱即用的功能。這是用工具加工為構建大規(guī)模的網絡應用，極大地促進快速發(fā)展在這種類型的應用程序。

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

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

    雙向綁定是一把雙刃劍。隨著組件的復雜性增加，這種方法可能會導致性能問題。

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

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

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

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

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

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

    模塊

    控制器

    指令

    作用域

    模板

    連接功能

    過濾器

    依賴注入

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

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

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

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

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

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

    跨瀏覽器兼容性：虛擬DOM也有助于解決跨瀏覽器的問題，因為它為我們提供了一個標準化的API，甚至早在IE8。

    模塊化：編寫獨立的模塊化應用程序的UI組件，從而隔離問題只對有問題的組件/s。每個組件都可以獨立開發(fā)和測試，并且他們可以使用其他組件。這相當于可維護性的改進。

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

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

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

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

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

    但是，我們如何管理包角由你決定但知道角都有自己的世界。你將最有可能需要適應第三方包角的世界。反應另一方面，只是JavaScript，任何JavaScript編寫的包不需要任何包裝的反應。

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

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

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

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

    然而，盡管社區(qū)的新反應它正在快速成長。擴展像反應引導是一個很好的證明，這只是一個時間問題我們有了更多的可用組件。

     (轉載請注明轉自：www.urbncart.com/news/n1588.htm，謝謝!珍惜別人的勞動成果，就是在尊重自己!）