- 做一個簡單介紹,年近48 ,有20多年IT工作經歷,目前在一家500強做企業架構.因為工作需要,另外也因為興趣涉獵比較廣,為了自己學習建立了三個博客,分別是【全球IT瞭望】,【架構師酒館】和【開發者開聊】.
- 企業架構師需要比較廣泛的知識面,了解一個企業的整體的業務,應用,技術,數據,治理和合規。之前4年主要負責企業整體的技術規劃,標準的建立和項目治理。最近一年主要負責數據,涉及到數據平臺,數據戰略,數據分析,數據建模,數據治理,還涉及到數據主權,隱私保護和數據經濟。 因為需要,最近在學習財務,金融和法律。打算先備考CPA,然后CFA,如果可能可以學習法律,備戰律考。
- 歡迎愛學習的同學和朋友關注,也歡迎大家交流。微信小號【ca_cea】
你可能經常聽到有人這么說
Angular在3年后等你。
Angular更適合大型或企業項目
Angular提供了出色的更新體驗
…
在這篇文章中,我將向您展示為什么我認為Angular不如您在2023 Angular 15、16之前聽到的那么好。
當然,在將Angular與其他框架/lib進行比較時,我不可能做到100%公平。此外,因為我試圖在2023年之前演示Angular并不是那么好,所以我會過多地關注缺點。這對Angular來說是不公平的。2023年之后,Angular變得更好了,但我將在其他文章中介紹這些部分。
公平地說,我將在2023/8/15創建兩個項目,一個用于Angular,另一個用于Vue。
For Angular, I’m creating with?ng new my-app-angular
?with?@angular/cli@16.2.0
.
For Vue, I’m creating with?npm create vue@latest
?with?create-vue@3.7.2
.
我將一步一步地演示它。
創建新項目時模板過于簡單
使用Angular CLI創建新項目時,我有兩個選項
- 需要路由
- CSS格式
While with Vue CLI,
除了2個選項,我還有4個以上的選項
- state-management lib
- e2e test lib
ESLint
Prettier
?for code formatting- ……
老實說,在我看來,對于一個大型或企業項目來說,配置以上4個選項很重要。
如果開發人員不是高級或專業的前端工程師,或者只是想節省一些時間,而CLI不提供這些選項,那么它們很容易丟失。
如果他們不是在一個大項目開始時建立的,那么讓所有團隊成員就一個特定的解決方案達成一致并不容易。有些人喜歡這個國家管理庫,而另一些人則喜歡另一個。有些人喜歡半成品,而另一些人則不…
即使幸運的是,開發人員在迭代中設置了它,仍然有一些遺留代碼需要遷移。
順便說一句,Angular直到現在還沒有官方的狀態管理解決方案。由于這個問題,Angular在2022年將此功能添加到了積壓工作中。到目前為止,Angular最出色的狀態管理解決方案是ngrx。還有許多人將自己設計的狀態管理庫與RxJs和DI一起使用。
默認項目文件夾結構過于簡單
對于Angular,在找到CodingStyleGuide一章之前,我甚至不知道如何使用模板進行編碼。
- 路由器視圖放在哪里?
- 將共享代碼放在哪里?
- …
而對于Vue,我認為開發人員可以立即編寫代碼。
無論如何,我將按照Angular樣式指南創建一個英雄特性模塊。
演示代碼是從Angular主頁演示中復制的。
這是UI:
默認更改檢測策略是性能殺手
你有沒有注意到當頁面被加載時,這個函數在控制臺被調用了多少次?6*9=54次!這是代碼
And if you move your mouse from top to bottom, the function will be triggered?2*9*9 times!
在這種情況下,我們可以使用OnPush策略。
isSensitiveHeroName
?will be triggered?9?times in the first time and?9*9?times for?mouseenter
?event.
因此,使用OnPush策略,性能提高了1200%。事實上,如果我們想將默認策略更改為OnPush,我們需要應用更多的更改,而不僅僅是這個演示中的一行。
對于這種情況,Angular有一個更好的解決方案。
現在,我們有了更好的表現,也許是最好的表現。這就是為什么你經常可以在Angular社區中看到這一點。
從不調用模板中的函數
好的。這是我關心的問題
避免在模板中使用函數真的好嗎?
為了獲得更好的性能,我們定義了一個派生狀態isSensitive。所以,每次我們更改英雄的名字時,我們都需要更新isSensitive。
在實際應用程序中,會有許多派生狀態依賴于2個或多個其他狀態。因此,我們需要添加越來越多的代碼來保持當前的性能,這將很快帶來錯誤和維護問題。
可能還有其他方法可以在不編寫更多代碼的情況下保持性能。但這是我關心的問題
Angular開發人員編寫高性能、易于維護的代碼需要多長時間?1個月還是1年?
幸運的是,Angular在2023年推出了Signals,目前正在開發者預覽中。Signals允許您編寫高性能且易于維護的代碼。
復雜的NgModule
現在,讓我們假設我想使用HeroesModule之外的HeroListComponent。我需要將其從HeroesModule導出,然后將HeroesMode導入另一個模塊(假設為AppModule)。
我只能看到一個優點。如果我想使用從HeroesModule導出的組件,我不需要再次將組件導入AppModule。
然而,我看到了許多缺點。
對于開發人員來說,要知道AppModule從HeroesModule導入了多少東西并不容易。只有Angular知道。
因為組件必須在模塊中聲明,所以開發人員很難知道組件在模塊中依賴于多少東西。例如,HeroListComponent是否依賴于CommonModule和HeroesRoutingModule?我們需要檢查一下。
因此,如果您將組件從一個模塊移動到另一個模塊,但它不起作用,這是很常見的,因為您需要找出組件需要什么依賴項,并移動依賴項。因為依賴項沒有在組件中聲明。
總之,一個組件本身無法工作,如果你來自其他框架,這很難想象。
幸運的是,我們在中獲得了獨立組件angular@15到2022年底。Angular團隊甚至為您提供了一個從NgModule遷移到獨立組件的工具。
與RxJs深度綁定
許多Angular API都是通過Observable公開的,甚至是HttpClient。然而,對于初學者來說,用RxJs編寫bug較少的代碼并不容易。
RxJs聲明風格中需要注意的事項
例如,以前的HeroListComponent是用聲明性樣式實現的。如果我們刪除模板中的英雄$|async,那么service.getHeroes將永遠不會被再次調用。如果你是Angular或RxJs的新手,這可能會讓你大吃一驚。
此外,如果service.getHeroes拋出一次錯誤,該函數將不再工作。這就是為什么您經常可以在聲明性代碼中看到catchError(() => EMPTY)
?。
RxJs命令式風格中需要謹慎的事情
事實上,許多開發人員都在使用命令式編程。在這種情況下,HeroListComponent會像
在模板中,需要將heroes$|async更改為heroes。
然而,它有錯誤。就像我們在addEventListener之后需要removeEventListener一樣,我們也需要取消訂閱或使用takeUntilDestroyed。
然而,直到現在,takeUntilDestroyed還在開發者預覽中。在2023年之前,我們需要添加更多的代碼。還有一點,這種方式對OnPush策略不友好。
簡短結論
正如您所看到的,與RxJs的深度綁定使開發人員更容易出錯或編寫性能較差的代碼。
我確實認為RxJs功能強大,特別適合邊緣情況。然而,擁有強大的工具并不意味著我們需要在所有情況下都使用它。許多沒有RxJ的框架/libs/項目都運行得很好。
此外,我沒有提到開發人員需要從RxJ中了解的內容以及它帶來的非常侵入性的代碼風格。
Angular的當前狀態
正如您所看到的,Angular帶來了許多新的解決方案。這是一件好事,但如果他們不及時指出建議的解決方案,那可能是一件壞事。社區可能會比以前更加分裂。
- 聲明式或命令式編程
- 更少或更多RxJ
- 默認或OnPush
- NgModule或獨立
- zone.js或Singals
- …
在它們之間進行選擇將導致不同的樣式,這也使得代碼難以維護。
前兩個選擇已經使社區分裂。現在我們有更多。
在我看來,
- 獨立+Singals是Angular的未來。
- RxJs對于Angular是可選的。
- 將提供官方的國家管理解決方案。
- Angular將更像其他框架/lib。
Angular已經做出了很好的選擇,比如選擇typescript,但選擇NgModule和zone.js可能并沒有那么成功。即使是內置的RxJs API也可能不是一個好的解決方案。
Angular在3年內不會等待其他框架/lib。
他正在做出進步和選擇。許多框架和開發人員沒有選擇的一些解決方案往往意味著它們可能不太適合前端開發。在這些情況下,Angular也在向其他框架/lib學習,而不是等待并堅持自己的方向是正確的。
實際上,框架/lib都在相互學習。學習和提高自己比認為我是最好的要好得多。
- Issue
- Source
文章鏈接
【Angular開發】Angular在2023年之前不是很好 | 程序員云開發,云時代的程序員.
歡迎收藏【架構師酒館】或者【開發者開聊】