為什麼快遞商qwintry選擇Vue.js而不是React
1.qwintry.com使用傳統的Drupal系統
2.qwintry.com新的分支完全重寫
3.logistics.qwintry.com時由Yii2支援b2b系統
4.在所有較小的內部和外部專案(大多使用PHP和Node.js後端)
在專案規模方面,速遞商Qwintry被全球五十萬客戶使用,軟體執行在美國和德國兩個倉庫 warehouse,而我們是在美國最大的船運和郵件分發商,專注於東歐和中東。 基本上,我們幫助在美國網上商店購買商品的人們運輸商品,能節省相當多運輸成本,透過利用我們的IT系統和物流鏈來獲得最優質的送貨服務和最優惠的價格。
我們決定使用Vue.js是在完成了現代化框架評估後作出的,我們已經基於React, Vue.js and Angular2建立了客戶的計算器上。
對React.js的想法
React在JS世界非常流行,它現在可能是前端檢視框架JS開發者的預設選擇。我已經在React上構建了一些SPA和動態小部件,我已經玩過React Native(在iOS下)和Redux。 我認為這是React在JS世界的狀態感知方面邁出了一大步,而事實證明,很多人能夠以之實現真正的函數語言程式設計。 我認為React Native是巨大的進步 - 它改變了原生開發的疆土。
對我來說,缺點是:
1,純潔,不變性和思想,但不能很好完成工作
不要誤會我。 我欣賞純函式和簡單的render()方法 -毫無疑問,這是一個偉大的想法,在現實生活中能完成偉大的工作。 我在這裡談論其他事情。
我在想嚴格和純度這個層面的事情,當你有1000的開發者可能是有用的-那個時候你決定要開發自己的語法,比如使用靜態型別編寫所有PHP程式碼 ;或者,當你是一個Haskell開發者來到JS世界時。但是大多數公司的開發團隊和其目標都比Facebook小得多。
我將在下面詳細說明。
2.JSX糟糕
我知道這“僅僅是具有特殊語法一個普通的JavaScript”。我們那些設計&html的傢伙,需要專注於包裝它的元素在各種數量的div上 - 將設計應用於React元件仍然很費時間,因為JSX缺乏可讀性。 不能把一些舊的IF條件放在某些HTML程式碼塊中,請不要相信React的粉絲們告訴你在有三元ternary運算子的時候不需要它。 我向你保證 - 當你編輯它讀取它時,仍然有HTML和JS的混亂,即使它被編譯為純JS。
<ul> {items.map(item => <li key={item.id}>{item.name}</li> )} </ul> <p class="indent"> |
很多開發人員(曾經包括我在內-但現在不了)相信這一特定語法限制將令你更強大,將幫助你寫出更模組化的程式碼,因為你必須把你的程式碼塊放入更小的輔助函式,在render()函式內部使用它們,這些傢伙建議:
http://stackoverflow.com/a/38231866/1132016
JSX會讓你將15行HTML程式碼元件拆分為3個元件,每個元件5行程式碼。
不要認為這是一個偉大的解決方法,會讓你成為一個更好的開發人員。
..
因為,在並不真正需要的地方,過度和過早強制使用(潛在)模組化元件,會降低編寫程式碼的速度。在我看來,過早的模組化非常類似於過早最佳化。
對我和我的團隊來說程式碼的可讀性很重要,但是有樂趣地編寫程式碼仍然更重要。當你實現真正簡單的計算器小部件時,建立6個元件是不有趣的。當對其維護,修改時,你需要跳過多個檔案/函式並分別檢查每個小塊的HTML。 再次宣告,我不建議編寫鐵板一塊的單片整體程式碼 - 我是建議使用元件,但不是日常開發的元件不能過於微型, 這只是常識。
3.在React中使用表單和Redux會讓你整天輸入
React是關於純潔和乾淨的單向流,現在你必須建立10種函式以獲取10路輸入。這些函式中的80%將包含帶有this.setState()呼叫或redux動作呼叫的單行(然後你可能需要建立另外10個常量 - 每個輸入一個)。 如果你可以想辦法自動生成所有這些程式碼,我想這是可以接受的,但我不知道有任何IDE可以明顯地做到。
你為什麼要輸入這麼多? 因為在大企業應用程式中雙向繫結被認為是危險的。 我可以確認雙向資料流程式碼有時不是那麼幹淨閱讀,但大多數這些恐懼並混合了痛苦是來源於Angular 1不好的整體雙向繫結,當然有可能這不是其最大的失敗之處。
讓我向你展示我最近用Vue.js(可見原文動畫圖片),為我們的Drupal網站建立的快速編輯器元件(我請求你原諒我的設計 - 它是我們的操作員的後端UI,我們的設計師忙於為我們的客戶建立前端介面,因此這件作品正在等待真正設計時修正):
編寫Vue是真正的樂趣,且程式碼是非常可讀。
我確信在React中為每個輸入建立一個單獨的函式來處理一個widget的方式肯定不會讓我高興。
4.工具過多
React建立時需要考慮Babel。如果沒有一堆npm包,你不能在真實世界中使用React,首先編譯器ES5。 基於簡單的應用程式的官方React包在node_modules下大約有75M的JS程式碼。 這不是關鍵,它更多的關係依賴到整個JS世界,它們整體加起來讓你使用React時感到沮喪。
Angular1:太多的自由有時是壞的
Angular1是一個偉大的前端框架,位於相反角度(從React角度看,從純潔和程式碼庫的可讀性的看) - 但它允許你快速開始,它給你一些真正的樂趣,可以編寫第一個1K程式碼行,然後它實際上迫使你寫低劣的程式碼。 你可能會迷失在指令,作用域和雙向的資料流中,你剛剛僱傭的開發人員甚至不想觸控它,因為它不可管理。
為什麼這樣?
Angular.js在2009年建立,那時前端世界看起來很簡單,沒有人甚至考慮狀態衛生處理(可變性狀態對於潔癖的函數語言程式設計來說類似一坨屎)。 你不能怪這些傢伙 - 他們只是建立了基於競爭對手Backbone的一些新的概念,他們想減少打字。
Angular2
只是建立hello world這樣簡單的應用程式,看看你的repo檔案的數量。必須使用Typescript和編譯器才能開始工作。這讓我受夠了。對我來說,在開始真正的工作之前還是打字太多了。 Angular 2這些傢伙正在努力構建完美的框架,目標是擊敗React,而不是構建一個解決一般使用者的業務任務的框架。 可能是我錯了,我的想法可能會改變 - 我沒有很多建立Angular2應用程式經驗,我們剛剛構建了演示客戶計算器的應用程式,作為我們的內部評估。
Vue.js
對我來說,Vue.js優點體現在優雅和簡潔的方面,並且專注於完成事情,Vue.這是我在2007年被jQuery糊弄了以後,JS的最大變化。
如果你看看Vue.js普及圖,你會發現它不只是我吹捧它: http://www.timqian.com/star-history/vuejs/vue&facebook/react
Vue.js是2016年增長最快的JS框架之一,我認為這不只是基於粉絲每3個月切換到新的JS框架,或者一個大公司的權威(和金錢)的另一個炒作。
Laravel將Vue.js新增到核心,這是一件大事。
1.Vue.js的優點
Vue.js在可讀性和可維護性和樂趣之間達到了一個最佳點。 React和Angular 1只是其中一個點,如果你看看Vue指南,你會立即注意到它從這些框架學習了多少好東西。
從React那裡它獲得了基於元件的方法,props,元件層次結構的單向資料流,效能,虛擬渲染能力和對應用程式的正確狀態管理重要性的理解。 從Angular那裡,它獲取了有類似良好語法的的模板和雙向繫結,當你需要它時(在單個元件內)。
Vue.js很容易開始 - 我們的團隊已經看到了這一點。 預設情況下它不強制執行任何編譯器,所以很容易將Vue放入到你的舊程式碼庫,並開始改進你的jQuery亂糟糕的JS程式碼。
2.適量的魔法
Vue.js非常容易使用,包括HTML和JS - 你可以做相當複雜的模板,而不會失去你的業務任務的重點,模板通常保持很好的可讀性,即使它變得非常大 - 在這一刻,你通常在解決業務任務方面取得了良好的進展,您可能希望重構模板並將其拆分為更小的元件 - 此時您會看到應用程式的整體“圖景”比您開始時更好。
從我的經驗來看,這與我以前在React中的方法有很大的不同:我在這裡節省了很多時間。 在React,你必須在編寫程式碼的初始版本時就分割成元件成微型元件和微函式。 在React中,你會花費很多時間來拋光道具和重構你的超小元件(以後也許永遠不會重複使用),因為你不清楚你是否必須在程式碼編寫過程的中間的某個地方改變你的應用邏輯的流程。
使用html表單在Vue中變得很輕鬆。 這是雙向繫結發光的地方。即使在複雜的情況下,它不會給我帶來任何問題,當您執行元件拆分時,具有回撥傳遞的單向流始終為您提供服務。
如果你想要一些編譯器魔法,linting,PostCSS和ES6 。 Vue開箱即用的理念看起來真的很好,可以減少需要在相應CSS層次命名和技術如BEM 。
Vue.js核心有很簡單和有用的狀態和props管理,透過data()和props()方法 - 他們在現實生活中工作得很好。 提供更好的關注分離。
3.缺點VueJS
(1)最大的一個:在模板中沒有執行時的描述性錯誤。 這與Angular 1非常相似。Vue.js設法為你的JS程式碼提供了很多有用的警告。 但是模板中的執行時錯誤仍然是Vue的弱點 - 異常堆疊跟蹤在很多時候是沒有用的,並且會導向Vue.js內部方法。
(2)框架是年輕的。 沒有穩定的社群元件 - 其中許多是為Vue.js 1構建的,有時候新手不容易從github repo檢視是為哪個版本的Vue庫構建的。
(3)中文註解遍佈大多數社群庫包 - 這並不奇怪,Vue.js在中國越來越流行(作者說中文)。
(4)單人專案? 不完全是一個真正的問題,但需要考慮的事情。 建立Vue的Evan You是在谷歌和Meteor工作之後。Laravel也曾經是一個單人專案,它仍然是一個巨大的成功,但你永遠不知道..
結論
我們每天在各種專案中編寫Vue.js程式碼約3個月,結果令人印象深刻。3個月沒有後端世界,但而是在JS世界:)讓我們看看它走得有多遠。
我期望Vue在16-24個月成為一個主要的JS框架,如果Evan採取正確的步驟,至少圍繞後端和前端更小的團隊為目標打造它。 我仍然認為React棧是2017年的主要JS框架,特別是如果React Native以相同的速度成熟和提高自身。
相關文章
- 為什麼你應當選擇 PostgreSQL 而不是 Oracle?SQLOracle
- 為什麼爬蟲語言選擇Python而不是Java?爬蟲PythonJava
- 分散式鎖為什麼要選擇Zookeeper而不是Redis?分散式Redis
- 為什麼爬蟲語言大多都會選擇Python而不是Java?爬蟲PythonJava
- [譯] Vue.js 還是 React?你會選擇哪一個?為什麼?Vue.jsReact
- 為什麼我不選擇React、Vue.js作為SAAS網站的前端框架ReactVue.js網站前端框架
- OceanBase的一致性協議為什麼選擇 Paxos 而不是 Raft?協議Raft
- Elasticsearch 中為什麼選擇倒排索引而不選擇 B 樹索引Elasticsearch索引
- [精選] 為什麼要選擇Go語言作為PHP的黃金組合?而不是Java或PythonGoPHPJavaPython
- 選擇Apache Pulsar而不是Kafka的理由 - KafkaesqueApacheKafka
- 為什麼選擇使用介面(如List)而不是具體實現(如ArrayList)來宣告集合變數?-AI變數AI
- 資料跟蹤應該是選擇加入而不是選擇退出
- 為什麼選擇.NETCore?NetCore
- 盤點爬蟲語言為何大多選擇Python而不是Java爬蟲PythonJava
- 為何Symless選擇Rust,而不是Go、C++或Node.js?RustGoC++Node.js
- 為什麼DNS使用UDP而不是TCP詳解!DNSUDPTCP
- 居中為什麼用transform,而不是margin top/leftORM
- 電商RPA告訴你為什麼可以這麼快收到快遞
- 電商小白該選擇怎樣的快遞查詢工具?
- 選擇 Pulsar 而不是 Kafka 的 7 大理由Kafka
- 快遞都比外賣快了?快遞按下“加速鍵” 今年雙11快遞為什麼這麼快?
- 為什麼ChatGPT採用SSE協議而不是Websocket?ChatGPT協議Web
- Aembit為什麼選擇 Rust?Rust
- 為什麼選擇使用Rust?Rust
- 為什麼選擇Guice框架GUI框架
- SPC控制圖為什麼是±3σ,而不是±2σ或±4σ?
- 為什麼VSCode是程式碼編輯器而不是IDE?VSCodeIDE
- 網際網路公司為什麼普遍996而不是666?996
- 為什麼選擇高防DNS?DNS
- 為什麼選擇centos系統CentOS
- 為什麼選擇Cynefin框架? – zwischenzugs框架
- gRPC為什麼使用截止時間而不是超時時間?RPC
- [譯] 為什麼我更喜歡物件而不是switch語句物件
- 每日安全資訊:資料跟蹤應該是選擇加入而不是選擇退出
- 為什麼選擇Python做爬蟲Python爬蟲
- 為什麼選擇ASP.NET CoreASP.NET
- 低延遲系統請選擇Java而不是C++ - stackoverflowJavaC++
- 技術分享 | 為什麼 SELECT 查詢選擇全表掃描,而不走索引?索引
- cad選擇框不是矩形怎麼設定 cad選擇物件的時候不是矩形物件