DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> JavaScript入門知識 >> JavaScript綜合知識 >> 2015年JavaScript或“親庫而遠框架”
2015年JavaScript或“親庫而遠框架”
編輯:JavaScript綜合知識     

   JavaScript世界似乎進入了一個churn rate(流失率)的危機,框架和技術在以一種不可持續的速度被擠出和消失。不過我認為社會將會適應以及采取新的實踐來回應這一現狀。開發者將會把目標從整理框架(如Angular.js和Ember)轉移到多種小型專用庫混合體,以此來緩解生產的風險並解決來自外部競爭的不同問題。

2015年JavaScript或“親庫而遠框架”

  流失

  2014年過去了,作為一個JavaScript開發者很難滿懷信心的去“挽回”一個特定的庫或技術,即便是強大的Angular,似乎也因為最近的一些事情而動搖。

  2014年10月的ng-europe會議上,Angular開發者團隊透露了一個關於Angular 2.0路線圖的重大更新。而最有爭議的信息之一是NG2.0將與現有的Angular代碼“向後不兼容”。事實上,幾個關鍵的概念將在全新的體系結構中被棄用,Angular開發者需要有效的掌握全新的框架。

  顯然,這一舉措令很多人感到不滿。是對還是錯?我們不太清楚,不過感覺上,Angular開發者在過去兩年裡的知識、實踐和代碼已經被任意的棄用了。更糟糕的是,替代品還不會馬上出現——這應該是一年以後的事了,反對者認為,一旦Angular 2.0在2015年發布的話,那麼開發者手中的新項目將經歷“由生到死”的命運。

  有很多不快的評論專門指向Angular和谷歌,有些是中肯的,有些或許並非如此。但最高得票意見之一的並不是關於Angular。它指向整個JavaScript環境,Reddit的othermike評論道:

  我不明白,我不明白為什麼有人認為這是一個好注意,這是很恐怖的,因為沒有人有時間去理解它,當它以每三十秒的速度改變。

  othermike所反映的問題也正是流失的問題,有太多的JavaScript框架都改變的太快了。

  這種變化的速度是可持續的嗎?

  創新是偉大的,但是這種churn rate似乎過度了,當不能保證創新物的壽命時,不僅讓開發者不可能做大,也加大了前期時間投入——掌握處理新框架和技術。程序員想要創造事物,並且要成為事物的主人。但是當花費大量時間去學習時,程序員該如何完成事情?又如何通過不熟悉的技術在黑暗中探索?

  無需絕望

  情況是糟糕的,但是人是聰明的,開發者有夠足智多謀,而且編寫新應用的需求不會讓任何人放棄,那麼我們需要做些什麼呢?或許我們可以采取以下三個主要的經驗教訓:

  以健康的懷疑態度對待新的技術。謹慎的將新的GitHub項目投入產品,等待一些事物被通用、錯誤修正以及被證明毫無疑問的成熟。

  不要輕信於公司的支持。谷歌不是第一次對開發者所依賴的生態系統“釜底抽薪”。去問問那些使用Google的Web API的開發者就知道了。公司總會存在非理性的行為,他們的利益並不總是和你一致。

  更傾向專門的庫而不是整體框架。當你選擇一個框架時,意味著你做了一個大的、長期的承諾。然而一旦框架被證明是錯誤的,你會失去很多,但是如果你從庫中選擇時,你可以替代一部分前端堆棧的同時保留其余部分。

  庫>框架?

  在Angular爭論的結果中,Reddit網站跟帖中有這麼個問題:JavaScript開發者感覺更喜歡遷移到哪個技術?這裡有r/javascript不得不說的:

  React.js 和 Flux (一個只有視圖 view-only 的庫和事件驅動模塊)

  Ember.js(MVC框架)

  Knockout.js (視圖庫)

  Backbone.js (MVC框架)

  Meteor(同構框架)

  Mithril(MVC框架)

  Ember(MVC框架)

  不要框架,只需要一堆庫就可以

  Vue.js (視圖庫)

  Breeze.js (數據庫Model-only)

  Ractive (視圖庫)

  有趣的是這裡有多少選項根本不是成熟的框架,而是專業的庫——主要用於數據綁定的DOM。有人提出:“在沒有整體框架,只有模塊化組件的情況下去做一件事情會比較好。”他是這麼說的:

  我真的認為這是最好的答案。世上永遠不會有一個完美的框架,因此你僅可以使用npm將相關的特征聚在一起。我發現這些小的組件的文檔通常是很簡單的,你不需要去等待下一個完整框架的發布。你簡單的拋出一個問題,作者修復它,把它推到npm的同時不會打擾到其他組件。

  如果你發現自己不喜歡制模語言或錯誤處理,你不必考慮整個項目,只需要以自己的方式換掉目前的組件。

  不知你的感受如何?通過使用小型庫,讓選擇和混合成為可能。屆時,當它們被取代時,我們可以使用相近的來交換前端堆棧。庫不再是一個“非此即彼”的命題,如果你喜歡Angular的控制反轉容器,但不喜歡其數據綁定。你完全可以從NPM中選擇你喜歡數據綁定方式。你可以將你的遺留項目遞增的遷移到新的技術中,而不是重新寫一邊。

  更重要的是,當不同的問題被不同的庫解答時,他們的解決方法可以直接比較。如果框架A用於X很好,用於Y很差,而框架B完全相反的時候,你會很困惑。不過如果庫A和B都試著用於X時,它們會以一種直接的方式在獨立部件和可衡量方面進行比較。

  總結

  前端JavaScript技術的流失率是有問題的

  人們開始疲憊於改變的步伐,被迫疏遠

  答案可能是“親庫而遠框架”

  當然,在2015年我們將看到多少會實際發生呢?Angular的主導地位完全有可能繼續保持穩定,如果是這樣,Angular需要尋求標准以及穩定近兩年的“騷動”。當然也有另一種可能,就是會出現更龐大的事物代替Angular的位置。一個非正式的組合,Flux和Browserify似乎是很明顯的候選人。

XML學習教程| jQuery入門知識| AJAX入門| Dreamweaver教程| Fireworks入門知識| SEO技巧| SEO優化集錦|
Copyright © DIV+CSS佈局教程網 All Rights Reserved