個有經驗的Java開發人員特征之一就是善于使用已有的輪子來造車?!禘ffective Java》的作者Joshua Bloch曾經說過:“建議使用現有的API來開發,而不是重復造輪子”。在本文中,我將分享一些Java開發人員應該熟悉的最有用的和必要的庫和API。順便說一句,這里不包括框架,如Spring和Hibernate因為他們非常有名,都有特定的功能。
本文總結了日志、JSON解析、單測、XML解析、字節碼處理、數據庫連接池、集合類、郵件、加密、嵌入式SQL數據庫、JDBC故障診斷以及序列化等20個方面的常用類庫。都是你日常開發經??赡芤玫降?,現在不用不要緊,但是你要知道有這么一篇文章可以供你參考。
不知道不可怕,可怕的是你不知道你不知道。
日志庫是很常見的,因為你在每一個項目中都需要他們。打印日志是服務器端應用中最重要的事情,因為日志是你了解你的程序發生了什么的唯一途徑。盡管JDK附帶自己的日志庫,但是還是有很多更好的選擇可用,例如Log4j、SLF4j和LogBack。
Java開發人員應該熟悉日志記錄的利弊,并且了解為什么SLF4J要比Log4J要好。
在當今世界的web服務和物聯網中(IoT),JSON已經取代了XML,成為從客戶端到服務器傳送信息的首選協議。有一個好消息和一個壞消息。壞消息是JDK沒有提供JSON庫。好消息是有許多優秀的第三方庫可以用來解析和創建JSON消息,如Jackson 和Gson
一個Java web開發人員應該熟悉Jackson 和 Gson這兩種中的至少一種庫。
單元測試技術的使用,是區分一個一般的開發者和好的開發者的重要指標。程序員經常有各種借口不寫單元測試,但最常見的借口就是缺乏經驗和知識。常見的單測框架有JUnit, Mockito和PowerMock。
有幾個很好的第三方通用庫可供Java開發人員使用,例如Apache Commons和Google Guava。我會經常在我的代碼中使用這些通用類庫,因為這些類庫都是經過無數開發者實踐過的,無論是實用性還是在性能等方面都是最佳的。
我不是很喜歡JDK的一個重要原因就包括他們缺乏對HTTP的支持。雖然可以使用java.net包類,但是這和直接使用像Apache HttpClient和HttpCore等開源類庫比起來麻煩太多了。
盡管JDK 9將開始HTTP 2.0,也對HTTP的支持做了優化,但是我還是強烈建議所有的Java開發人員熟悉流行的HTTP處理類庫,例如HttpClient和HttpCore HTTP等庫。
市面上有很多XML解析的類庫,如Xerces, JAXB, JAXP, Dom4j, Xstream等。Xerces2是下一代高性能,完全兼容的XML解析工具。Xerces2定義了 Xerces Native Interface (XNI)規范,并提供了一個完整、兼容標準的 XNI 規范實現。該解析器是完全重新設計和實現的,更簡單以及模塊化。
許多應用程序需要提供把數據導出到Excel的功能,如果你要做相同的Java應用程序,那么你需要Apache POI API。
這是一個非常豐富的類庫,你可以從Java程序讀寫XLS文件。
如果你正在編寫一個框架或者類庫。有一些受歡迎的字節碼庫如javassist和Cglib Nodep可以供你選擇,他們可以讓你閱讀和修改應用程序生成的字節碼。
Javassist使得JAVA字節碼操作非常簡單。它是一個為編輯Java字節碼而生的類庫。ASM是另一個有用的字節碼編輯庫。
如果你的Java應用程序與數據庫交互不是使用數據庫連接池庫的話,那么你就大錯特錯了。因為在運行時創建數據庫連接非常耗時并且會拖慢你的程序。所以墻裂建議使用,有些好用的連接池可供選擇,如Commons Pool 和 DBCP。
在web應用程序中,web服務器通常提供了這些功能。但是在java項目中需要把數據庫連接池的類庫導入到應用中。
像日志和數據庫連接池一樣,消息傳遞也是很多實際的Java項目中必備的。Java提供了JMS Java消息服務,但這不是JDK的一部分,你需要單獨的引入jms.jar。類似地,如果您準備使用第三方消息傳遞協議,Tibco RV是個不錯的選擇。
除了Excel和Word,PDF也是一種常用的文件格式。如果你的應用程序要支持PDF格式的文件處理,你可以使用iText和Apache FOP類庫。兩者都提供了非常有用的PDF處理功能。
在Java之前,JDK的日期和時間庫一直被人們所詬病,比如其非線程安全的、不可變的、容易出錯等。很多開發人員會選擇更好用的JodaTime類庫。
但是在Java8推出之后,我們就可以徹底放棄JodaTime了,因為Java 8提供了其所有功能。但是,如果你的代碼運行在一個低版本的JDK中,那么JodaTime還是值得使用的。
雖然JDK有豐富的集合類,但還是有很多第三方類庫可以提供更多更好的功能。如Apache Commons Collections、 Goldman Sachs collections、 Google Collections和 Trove。Trove尤其有用,因為它提供所有標準Collections 類的更快的版本以及能夠直接在原語(primitive)(例如包含int 鍵或值的Map 等)上操作的Collections 類的功能。
FastUtil是另一個類似的API,它繼承了Java Collection Framework,提供了數種特定類型的容器,包括映射map、集合set、列表list、優先級隊列(prority queue),實現了java.util包的標準接口(還提供了標準類所沒有的雙向迭代器),還提供了很大的(64位)的array、set、list,以及快速、實用的二進制或文本文件的I/O操作類。
javax.mail 和 Apache Commons Email 提供了發送郵件的api。它們建立在JavaMail API的基礎上,提供簡化的用法。
和XML與JSON類似,HTML是另外一種我們可能要打交道的傳輸格式。值得慶幸的是,我們有jsoup可以大大簡化Java應用程序使用HTML。你不僅可以使用JSoup解析HTML還可以創建HTML文檔。
Apache Commons家族中的Commons Codec就提供了一些公共的編解碼實現,比如Base64, Hex, MD5,Phonetic and URLs等等。
我真的是非常喜歡像H2這種內存數據庫,他可以嵌入到你的Java應用中。在你跑單測的時候如果你需要一個數據庫,用來驗證你的SQL的話,他是個很好的選擇。順便說一句,H2不是唯一嵌入式DB,你還有Apache Derby和HSQL可供選擇。
有不錯的JDBC擴展庫的存在使得調試變得很容易,例如P6spy,這是一個針對數據庫訪問操作的動態監測框架,它使得數據庫數據可無縫截取和操縱,而不必對現有應用程序的代碼作任何修改。P6Spy 分發包包括P6Log,它是一個可記錄任何 Java 應用程序的所有JDBC事務的應用程序。其配置完成使用時,可以進行數據訪問性能的監測。
Google Protocol Buffer 是一種輕便高效的結構化數據存儲格式,可以用于結構化數據串行化,或者說序列化。它很適合做數據存儲或 RPC 數據交換格式??捎糜谕ㄓ崊f議、數據存儲等領域的語言無關、平臺無關、可擴展的序列化結構數據格式。目前提供了 C++、Java、Python 三種語言的 API。
一些有用的網絡庫主要有Netty的和Apache MINA。如果您正在編寫一個應用程序,你需要做的底層網絡任務,可以考慮使用這些庫。
這都是每位Java開發人員應該熟悉的,并且十分有用的庫。Java生態系統非常龐大的,你會發現有很多不同的類庫可以做不同的事情。每個你想到的東西,都可能有一個庫可以做到。
要相信,你遇到的問題,肯定不止你一個遇到過。
要相信,也許有很多人比你更勤奮。
要相信,你用或不用,輪子就在那里。
要相信,使用這些類庫,你和你的代碼都會變得更好。
文章來源:https://dwz.cn/kON36g6Q
作者: Hollis
介:無明JavaScript 仍然是 2020 年最受歡迎和使用最為廣泛的編程語言,因此 JavaScript 生態系統也會繼續發展壯大。然而,JavaScript 的標準庫仍然繼續保持“短小精悍”的身材。為了填補 ...轉發+關注,私信小編“資料”免費分享資料給你!
在筆記本電腦上工作的女子
JavaScript 仍然是 2018 年最受歡迎和使用最為廣泛的編程語言,因此 JavaScript 生態系統也會繼續發展壯大。
然而,JavaScript 的標準庫仍然繼續保持“短小精悍”的身材。為了填補標準庫功能方面的空白,在過去幾年中,GitHub 上出現了很多流行的 JavaScript 庫。以下列出了 11 個有用的庫,這些庫的維護狀態均很活躍。
1.Underscore 和 Lodash(dah)
可能大多數人都知道這兩個庫。Underscore 的目的是為 JavaScript 中的常見任務提供實用的函數。Lodash 是下載量最大和被依賴最多的庫之一,旨在為數組、字符串、object 和 argument 對象提供更一致的跨環境迭代支持,并已成為 Underscore 的超集。這兩個庫由相同的核心貢獻者維護,在技術選型時完全可以考慮使用它們。
Lodash - https://github.com/lodash/lodash
Underscore - https://github.com/jashkenas/underscore
2. Ramda
在 GitHub 上的 Star 已經超過 12,000,這個庫專為函數式編程而設計,可以輕松創建不改變用戶數據狀態的函數式管道。Ramda 的核心設計理念是創建具有不變性和無副作用的函數。所有的函數會被自動柯里化,并根據易用性安排參數的順序。
Ramda - https://github.com/ramda/ramda
3. MathJS
在 GitHub 上的 Star 已經超過 6000,這個庫是 JavaScript 和 Node.js 的數學擴展庫,與 JavaScript 內置的 Math 庫兼容。該庫包含一個靈活的表達式解析器,能夠運行符號計算,并提供了一系列內置函數和常量。用戶還可以對其進行擴展。
MathJS - https://github.com/josdejong/mathjs
4. Moment
在 GitHub 上的 Star 已經超過 37,000,是一個 JavaScript 日期和時間操作庫,用于解析、驗證、操作和格式化日期。Moment 可以在瀏覽器和 Node.js 中運行。從 2.10.0 版本開始遷移到 ECMAScript 6。
Moment - https://github.com/moment/moment
另外兩個同類的庫:
Date-fns(10,000 個 Star)- https://github.com/date-fns/date-fns
DateJS - https://github.com/datejs/Datejs
5. Sugar
在 GitHub 上的 Star 已經超過 3500,主要用于處理本地對象。這個庫支持自定義構建,還提供了模塊化的 npm 包,因此可以只使用其中必要的部分模塊(也可以與 Bit 結合使用),用戶還可以通過自定義方法或使用插件來應對特定的使用場景。
Sugar - https://github.com/andrewplummer/Sugar
6. Lazy
在 GitHub 上的 Star 將近 5000,是一個功能強大的 JavaScript 庫,它的 lazy 引擎“盡可能地少做一些工作”,同時保持足夠的靈活性。
Lazy - https://github.com/dtao/lazy.js
7. CollectJS
在 GitHub 上的 Star 超過 3200,主要用于處理 JavaScript 中的數組和對象,無需其他依賴,提供了幾十個有用的功能和 API,這些 API 幾乎與 Laravel Collections 5.5 相同。該庫的維護狀態很活躍,值得關注。
CollectJS - https://github.com/ecrmnn/collect.js
8. ChanceJS
Chance 在 GitHub 上的 Star 超過 3200,一個簡單的隨機對象生成器,用于生成隨機的字符串、數字等。在編寫自動化測試代碼或任何需要隨機對象的地方,可以用它來減少單調的工作。
ChanceJS - https://github.com/chancejs/chancejs
9. ChartJS
在 GitHub 上的 Star 將近 40,000 個,提供了 8 種不同類型的數據可視化,每種類型都支持動畫和定制。借助 Chart.js,我們可以使用<canvas>標簽創建簡單的HTML5圖表,而且在所有現代瀏覽器中都具有出色的渲染性能。
ChartJS - https://github.com/chartjs/Chart.js
10. Polished
在 GitHub 上的 Star 超過 3500 個,由 styled-components 團隊開發,是一個非常優秀的輕量級工具集,支持使用 JavaScript 編寫具有 SASS 風格輔助函數和 mixin 的樣式。該庫與 styled-components、Aphrodite、Radium 或簡單的內聯樣式兼容。這個庫可以在 GitHub 上找到,Bit 社區(非官方)也單獨提供所有的功能,因此可以單獨安裝、導入和使用。
Polished - https://github.com/styled-components/polished
Bit 社區提供的單獨安裝版 - https://bitsrc.io/ranm8/polished
11. Mout
Mout.js 是一組模塊化的 JavaScript 庫,可以在瀏覽器或 node.js 中運行,提供類似于其他語言標準庫(Python、Ruby、PHP 等)中的輔助方法。mout.js 允許僅加載必需的模塊或函數,并提供了一致的 API,規范了跨瀏覽器行為。
Mout - https://github.com/mout/mout
特別推薦
Bit utils
一個模塊化和高性能的庫,已經被用在 Bit 的 web hub 中。這些函數可使用 NPM/Yarn 進行單獨安裝,用戶也可以創建自己的集合,并從不同的庫和項目中收集有用的功能。
Bit utils - https://bitsrc.io/bit/utils
Voca
一個用于操作字符串的 JavaScript 庫。它提供的功能包括大小寫轉換、trim、pad、slugify、latinise、sprintf、truncate、escape 等。用戶可以加載單個函數,以便最小化應用程序的構建。該庫具有很高的測試覆蓋率,并且不依賴其他庫。
Voca - https://github.com/panzerdp/voca
Licia
只有 400 個 Star,這個有趣的項目基本上是一個簡單但有用的 JavaScript 片段集合,具有很高的測試覆蓋率,文檔也很齊全。
java學習資料獲取方式
右上角點擊關注,私信回復“學習” 領取資料
私信不要多字,不要少字,不要錯字,私信方法:點擊我頭像,進入主頁面,右上角有私信功能,在關注的上方位置。
Element-UI 是目前針對于 Vue 開發 PC 端項目的時候所使用到的一個主流 UI 庫。在座的有學習 Vue 開發的同學或多或少應該都知道 Element-UI 。那我們就從它開始聊。
? 大家有沒有想過,對于一個 UI 庫來說,它是如何被廣大的開發者所接受的?或者說它是如何被用戶所接受的?
? 我認為,一個產品,具體到當前就是 Element-UI 這個庫,這個庫對于我們開發者來說就是產品,我們開發者就是它的用戶。而一個產品之所以可以被用戶所接受,所依賴的無非是三點:
1. 產品的文檔對于用戶來說足夠清晰
2. 產品的功能對于用戶來說足夠簡單
3. 產品的 UI 對于用戶來說足夠友好
? 什么意思呢?我們一個一個來解釋。
? 首先我們來看第一個:產品的文檔對于用戶來說足夠清晰。這是什么意思呢?大家想一下當我們買了一個東西的時候,最初我們不知道這個東西是怎么用的?那么我們一般都會去看一下它的說明書,或者直接去網上搜索一些這個產品的資料,對吧。那么這個時候如果它的說明書寫的不清不楚,甚至有些地方寫的根本就不對。那么你如果想要把這個東西使用熟練,是不是要花費特別大的精力。也就是我們開發者常說的,這個框架擁有了過高的學習成本,或者說這個框架學習曲線過于陡峭,不夠平滑。那么這樣的話無疑會勸退一部分用戶。對吧。
? 所以說如果一個框架如果想要被開發者廣為接受,那么一個清晰的文檔肯定是首要的條件。那么對于 Element-UI 來說,它的一個文檔就比較清晰。在組件部分,從安裝 Element-UI 到各個組件的效果描述的都是非常清楚的,每一步應該如何做,這樣做會產生什么樣的結果都在文檔上描述的很清楚。這個就是一個清晰的產品文檔。
? 第二條:產品的功能對于用戶來說足夠簡單。這一條也好理解。對于我們開發者來說,當我們使用一個框架的時候,我們想要的是什么?我們想要一個框架:你的功能要足夠的復雜,但是你的接口要足夠的簡單。什么意思呢?大家可以參照一下自己的手機?,F在智能手機的功能已經非常復雜了。可以打電話,可以玩游戲,可以看電影。但是一旦你熟悉了它之后,它使用起來確實非常簡單的。你不會去關心它的功能是如何實現的,你關心的只是是否可以通過簡單的操作來完成復雜的功能。就是這個道理放到我們開發者身上也一樣。我不關心你組件封裝的如何復雜,我所關心的只是你暴露出來的接口。
? 第三條:產品的 UI 對于用戶來說足夠友好。這一點是什么意思呢?其實這一點主要是對于產品經理和設計師來說的。大家有過開發經驗的同學,特別是有過在公司工作過的同學。應該很清楚,你的項目最終開發出來帳什么樣子,不是你決定的。是產品經理和設計師來決定的。那設計項目的 UI 他們的依據是什么呢?他們會依據產品的特性、產品的定位等等,但是絕大部分的 UI 依據都是目前用戶的一個普遍審美。
? 大家有沒有發現對于現在的 APP 、網頁甚至手機來說,他們的 UI 同質化非常嚴重嗎?差不多都是一個風格的,對吧。出現這個問題的原因就是因為大眾的一個審美會定位到同一塊區間,而設計根據大眾的審美來定位產品的樣式,所以才會出現這種同質化的問題。
? 那么這個和我們開發者有什么關系呢?大家想一下,如果一個 UI 庫它能夠符合大眾的普遍審美,并且提供了一種良好的交互體驗,那么如果你是設計師的話,你會不會參照或者直接使用 UI 庫所提供的樣式。因為對于這種 UI 庫來說,它的樣式會比大部分的設計做出來的樣式還要好。
? 那么對于我們開發者來說,當你拿到設計稿的時候,你發現設計稿上的樣式和 Element-UI 一樣,你是不是到 Element-UI 上直接拿過來用就可以了呀。
? 并且對于 Element-UI 它額外還提供了 自定義主題 和 國際化的功能。這些具體怎么做,文檔說的很詳細,我們就不展開說了。
? 那么總結一下 Element-UI 。
1. Element-UI 是現在基于 Vue 的一個非常好用的桌面端 UI 組件庫
2. 支持 @vue/cli 項目的直接添加,支持按需導入、國際化、支持自定義主題
3. 文檔清晰,學習成本低
4. 提供的組件足夠使用
5. UI 的風格符合目前大眾的普遍審美
6. 如果你想要做一個公司級別的產品,那么 Element-UI 基本可以滿足需求,但是難免樣式、風格上會同質化嚴重
但是如果你想要弄一個自己的網站、自己的項目,并且希望在樣式上,不喜歡那么同質化,應該怎么呢?這個時候,你可以參考下,另外一個 UI 庫,就是 vuetify。
? vuetify 是麻省理工學院的開源項目,文檔同樣支持全球化,它是基于 Android Material Design 風格的一個 vue 前端組件庫。同樣支持 @vue/cli 項目的直接添加。
? 不過 vuetify 的 Material Design 風格在國內并不是很大眾, Material Design 是由Google開發的設計語言,第一次公開使用應該是在 Android 5.0 上面,但是在國內這種樣式風格一直推行的效果不好。在國外這種風格被接受的程度還可以,但是國內你會發現很少見。
? 這樣就導致這種設計風格不會存在大量同質化的問題。同樣的如果你使用了這種風格的話,也必須要承擔一定的風險。所以對于公司級項目來說,如果使用了 vuefity 的話,那么無形中就會為產品增加一些風險。不過如果你是要做一個自己的項目,并且希望你的項目擁有一些自己的個性,那么 vuetify 無疑是一個很好的選擇。
? 對于 vuetify 本身的一個功能層面上,它的文檔、它的組件都可以完全滿足我們的一個日常使用,比如,在它的 UI 組件里面,我們常用到的這些組件都是比較全的。
? 另外它還提供了一些擴展的指令,這些指令是在 vue 的基礎上做的一些擴展,可以滿足一些特定的需求。
? 總的來說,vuetify 上手的難度會比 elementUI 要高一些,主要是因為國外的人的思維和國內的人還是有一些不同,所以這就導致了 vuetify 對于國內來說會難免有一些水土不服,而產生兩個極端,也就是所謂的:喜歡他它的人很喜歡,討厭它的人很討厭。
? 總結一下 vuetify:
1. vuetify 是國外團隊進行開發的一個基于 vue 的組件庫
2. 支持 @vue/cli 項目的直接添加,支持按需導入、國際化、提供了定制功能(樣式、顏色、主題等等)
3. 文檔相對清晰,但是和國人的思維不太一樣,導致學習成本相對高一些
4. 提供的組件足夠使用,并且提供了 v- 開頭的擴展指令,還有付費專題模塊
5. UI 的風格使用的是 Google 推出的 Material Design 的設計風格,在國內推廣度相對低一些
6. 使用 vuetify 在 UI 樣式上,會有一些額外的風險,但是可以避免同質化的問題,比較適合一些個人或者需要彰顯個性的項目
介紹了兩個都是基于 vue 的 UI 庫。那么下面我們來看一下基于(常用于) React 的 UI 庫。
Ant Design 被官方定義為一種設計體系,不過設計體系這種高雅的東西,對咱們這些俗人應該認知不大,我們所認知最明確的,就是這個東西能為我們的開發帶來什么幫助。所以我們下面就把它當作一個 UI 庫來看。
Ant Design 在 react 中的地位,應該和 element UI 在 vue 中的地位是一樣的,都可以說是最火爆的 UI 庫之一。
Ant Design 同時支持 React、Vue、Angular,也就是說我們在這三個主流框架中都可以使用,但是 Ant Design 對于React 的支持是最好的,所以一般我們說到 Ant Design ,都會說他是一個基于 React UI 的一個組件庫。
? Ant Design 是阿里巴巴-螞蟻金服體驗技術部所設計的一個 UI 庫,目前最新的是 4.x 的版本,我們看它的主頁,就能夠感覺出來,一個整體的設計風格是非常贊的。
? 同樣,像國際化、定制主題的這些功能,Ant Design 也同樣是支持的,這個沒得說,具體怎么做,大家看文檔。
? Ant Design 的文檔也非常的詳細,無論到快速上手,到各個組件的使用,都有非常詳細的文檔。
? 另外非常值得一提的就是關于 Ant Design 的社區,它的社區中提供了非常多的精品組件和一些開發中常用的一些工具推薦,這一點是 ElementUI 上所沒有的,可以說它的社區是真的很用心的在做的。
? 對于 Ant Design 來說,如果把它作為 React 項目的一個核心 UI 庫的話,那么它是完全可以勝任的,沒有一點問題。并且無論是它的開發團隊也好,它的一個社區也好,都可以很好的保證該庫的一個正常的升級和迭代。
? 總結一下 Ant Design:
1. Ant Design 是阿里巴巴-螞蟻金服體驗技術部所設計的一個 UI 庫,一般用于基于 React 的項目
2. 支持在 create-react-app(React 官方腳手架) 項目的直接添加,支持按需導入、國際化、提供了定制主題
3. 文檔清晰,學習成本低
4. 提供的組件足夠使用,并且提供了精品社區服務
5. UI 的風格符合目前大眾的普遍審美
6. 如果你想要做一個公司級別的產品,那么 Ant Design 基本可以滿足需求,但是難免樣式、風格上會同質化嚴重
上面說的都是一些對于現階段,也就是 web 3.0 階段的 UI 庫,然后我們來看兩個適用于 web 2.0 階段的 UI 庫。
? Bootstrap 前端的同學應該沒有不知道。在之前的 web 2.0 階段,可以說是大名鼎鼎了。我們這里提到了 web 3.0 和 web 2.0 ,那么給大家解釋一下。
? 整個前端開發的歷史,我把它分成了三個階段,web 1.0 、web 2.0 和 web 3.0。
? 對于 web 1.0 來說, 指的就是 html、css、js的那個階段,整個前端的交互還都是以一種原生的方式進行展示,這個時候還沒有前端工程師的概念,或者說這個概念很稀薄,大部分的前端工作都是由后端的工程師來兼職進行開發的。
? 而 web 2.0 階段,最大的標志就是 jQuery、bootstrap、還有各種模板引擎的庫開始出現,這個時候開始逐漸有了前端開發工程師的崗位,但是前端依然不夠興盛,因為雖然這些新出現的東西使前端的開發有了一些壁壘,但是這種壁壘明顯不夠堅固,并且這些庫并沒有帶來太大的本質上的變化,更多的是一種增強。
? 而 web 3.0 階段,最大的標志就是 angular、react、vue 的出現。從最初 google 推出了 angular 1, angular 1 一出現,確實可以說是驚艷。他把之前零零碎碎的內容,比如數據驅動,比如模板語法,比如模塊化的東西進行了整合,變成了一個大一統的框架。但是因為 angular 1 屬于一個最初的嘗試,所以在設計上還有很多不完善的地方,這就導致了 angular 2的變化過大,成了一個斷層,就引起了很多人的不滿。
? 而這個時候 react、vue 也開始逐漸崛起,從 angular 手中搶走了大量的開發者。而 react、vue 所推崇的這種漸進式框架的方案,明顯更被開發者所接受,所以就導致現在 react 和 vue 的開發者基數要遠遠的大于 angular了。不過就算是這樣,沒有人可以否認 angular 所帶來的貢獻。
? angular、react、vue 完全提高了前端的壁壘,隨之也逐漸出現了很多的周邊庫,比如 前端路由庫、全局狀態管理工具、webpack 這種大一統的前端打包工具。
? 這些內容的出現,就導致了前端的學習成本變得越來越高,也就使得前端的壁壘變得越來越堅固。
? 再加上用戶對于體驗的要求越來越高,后端工程師對此逐漸開始無力,這就導致前端工程師開始出現,前后端的項目分離變成了現在的正統,大家各司其事,后端的工程師主要做后端的內容,前端工程師主要做前端的內容。
? 這就是整個前端的一個大概的發展歷史,而對于 bootstrap 來說,他在 web 2.0 的時候,是頂頂大名的。使用它來開發的項目不計其數啊,主要原因就是因為它足夠簡單、易用,并且它的一個設計風格在當時相當超前的。
? 不過在現在的階段,bootstrap 已經開始被使用的越來越少了,哪怕是推出了 bootstrap vue 這種擁抱現階段的庫,也只能說是表現平平。
? 但是對于 bootstrao 來說,它就完全沒有價值了嗎?不是的。如果你的項目需要兼容到 IE8,那么你就沒有辦法使用之前咱們提到的那些 UI 庫,這個時候, bootstrap 這種純 css 的庫,會給你帶來很大的幫助。關于 bootstrap,大家應該都會比較熟悉了,我們就不詳細說了。
? 總結一下 bootstrap:
1. Bootstrap 是 Twitter 所設計的一個 UI 庫,以 css 樣式為主,也提供了一些組件的功能需要配合 js 來進行使用
2. 使用簡單,文檔清晰,學習成本低
3. 提供的組件相對較少
4. 可以只使用框架中的 css 樣式,可嵌入性較高
5. UI 的風格符合目前大眾的普遍審美
6. 適合使用在對游覽器兼容性有要求的項目中
除了 bootstrap 之外,另外一個 web 2.0 階段的 UI 庫就是 layui 。
? layui 是自由職業者(賢心)進行開發的一個前端庫,最低可以兼容到 IE8 ,官網介紹它是一個更加適合服務端工程師來開發前端頁面的庫,但是對于前端工程師來說,如果你的項目要兼容到 IE8 的話,那么使用 layui 也是一個很好的選擇。
? layui 的主要內容被分成了兩個大的部分,1.頁面元素。 2.內置模塊
? 對于頁面元素來說,主要就是一些 css 的樣式,也就是一些定義好的 css 樣式類,這一點和 bootstrap 很像。
? 對于內置模塊來說,是 layui 比較推崇的一個概念。比如按需引入的模塊化。當然這個概念對于現在的前端開發來說,已經變成了一個普遍的功能點了。比如我們前面說到的 Element-UI、vuetify、And Design 都擁有這個功能。 但是在 web 2.0 階段的時候,這個模塊化的功能還是比較先進的。
? 至于 layui 中所涉及到的樣式部分,按照現在的一個審美來說依然是不過時的,所以說對于現在來說,如果你對前端的技術了解的并不深,或者說你是一個服務端工程師,那么想要開發一個前端頁面的話,layui 依然是一個比較好的選擇。
? 總結下 layui:
1. layui 是 自由職業者(賢心)進行開發的一個前端庫,最低可以兼容到 IE8
2. 設置的初衷是讓非前端的工程師可以很方便的開發前端頁面
3. 使用簡單,文檔清晰,學習成本低
4. 提供頁面元素和模塊化的概念
5. UI 的風格并不過時
6. 適合非專業前端工程師使用
之前看了很多桌面端的組件庫了,那么下面我們來看幾個移動端的 UI 組件庫。
? Vant-UI 是有贊前端團隊開發的一個基于 vue 的移動端組件庫。不過對于移動端組件庫來說,它和桌面端有非常多的不同。
? 比如說,官方的文檔,對于移動端的組件庫文檔來說,大部分都會把整個項目中所有的組件通過一個類似于手機的UI形式給一次性全部羅列出來。
這個在 PC 端的 UI 庫中,大家應該很少見吧。我個人是比較喜歡這種方式的,因為這樣它可以讓開發者很方便的知道,這個 UI 庫它的各個組件的樣式效果,是否可以滿足個人的需求。
? 還有關于兼容性方面,因為是移動端的組件庫,那么它都會運行在手機上,而對于手機來說就不會存在 PC 端瀏覽器 IE 兼容性的問題了。更多的是關于手機系統版本的問題。咱們就以 Vant-UI 為例,他在瀏覽器支持這方便介紹說,現代瀏覽器以及 Android 4.0,IOS 8.0 以上的系統都支持,那么以咱們現在的這個時間點來說,基本上就不會存在兼容性的問題了。
? 還有就是組件的樣式風格上,因為對于移動端設備來說,畢竟大小、尺寸、操作方式都不一樣,所以在 UI 的一個整體設計風格上,肯定和 PC 端上有很大的不同。
? 然后還有最重要的一點,也是考驗移動端組件庫的一個非常重要的難點。就是流暢性的問題。這個問題在桌面端組件庫上一般不會是一個太大的難點。但是在移動端上面就不太一樣了。手機使用的流暢度的問題,在咱們現在依然還是一個大家都非常關注的點,并且對于現在的用戶來說,對于移動端流暢度的要求,要更加苛刻,這種苛刻的程度遠高于 PC 端。所以說如果你開發了一個 web app 或者 web 端網頁的話,如果很卡,那么無論你的 UI 樣式做的再好,估計也會大大減分的。
? 所以說對于一個移動端的 UI 庫來說,它如果要做好其實要比 PC 端的組件庫難度更大上一些。而 Vant-UI 在基于 Vue 的移動端組件庫中,各方面都是非常不錯的。無論是文檔、組件的豐富性、易用性上,我個人都比較喜歡。
? 另外對于 Vant-UI 來說他還提供了幾個非常有意思的組件,我們來看一下。
? 大家打開 Vant-UI的官網,在業務組件部分,它提供了一些目前商城類系統所常用到的業務模塊。比如商品規格,像這種擁有相對固式樣式的業務,它提供了成套的業務組件,并且這些業務組件,我們也可以使用 Vue 中的 插槽 功能去進行一些定制這個我覺得是非常非常好的一個功能。
? 總結一下 Vant-UI:
1. Vant-UI 是有贊前端團隊所設計的一個 UI 庫,一般用于基于 Vue 的移動端項目
2. 支持 @vue/cli 項目的直接添加,支持按需導入、國際化、提供了定制功能(樣式、顏色、主題等等)
3. 文檔清晰,學習成本低
4. 提供的組件足夠使用,性能不錯,并且提供了基于商城業務的成套組件
5. UI 的風格以及交互操作可以達到現在的主流標準
6. 適用于 web app 或者 基于移動端的網頁開發
然后我們來看另外一個移動端組件庫
? Framework7 是獨立開發者開源的一個全功能框架??梢杂脕順嫿?IOS、Android和桌面應用程序。注意我們這里說的是框架,不再是一個簡單的 UI 組件庫了。
? 由組件庫變成了框架,那么顯然帶來的問題就是復雜度直線上升了。但是復雜度上升的同時,它能夠給我們帶來的東西也完全不一樣了。打開官網,我們一起來看一下。
? 打開官網,首先我們能看到它的一個功能演示。我們主要看 IOS 和 android 這兩個部分。
? Framework7 針對 IOS 和 Android 的不同風格提供了不同的展示樣式。對于 IOS 是標準的蘋果風。對于 Android 則提供了基于 Material Design 的一種設計風格。并且 Framework7 提供了一種很牛的功能,這個功能是其他的 UI 組件庫所沒有的,那就是基于移動端不同頁面的一個過場動畫。
? 對于 Framework7 因為它是一個框架,所以說它不需要再依賴于向 vue、react 這種其他的框架,它本身就可以完整的去開發一個項目。同時如果你想要基于 vue 或者 react 來配合 Fragment7 使用的話,那么也是可以的。Fragment7 同時也提供了 Framework7 Vue 和 Framework7 React 這兩個框架。
? 另外對于 Framework7 提供了很多新的概念,比如 Framework7 CLI 、DOM 7 等等,咱們再這里就不在詳細說了。
? 總結一下 Framework7 :
1. Framework7 是獨立開發者所設計的一個全功能框架??梢杂脕順嫿?IOS、Android和桌面應用程序。
2. 本身是一個獨立的框架,同時也可以配合 vue 和 react 來使用。整體比較重
3. 文檔漢化不是很好,具有一定的學習成本。
4. 提供的功能組件、交互視圖足夠強大,并且也有很多新的概念,性能優秀。
5. UI 的風格以及交互操作可以達到原生 APP 95%的體驗
6. 適用于沒有資深前端開發工程師的公司使用。
最后我們來看一個由 微信團隊開發的 weui
? weui 是微信官方團隊開發的一套同微信原生視覺體驗一致的基礎樣式庫。提供了一些組件和樣式的簡單使用。主要應用于微信內部網頁和微信小程序。
? 對于 weui 的文檔沒有放到官網上,而是在 guthub 中。這個大家注意下,別找不到文檔就可以。不過微信的文檔是相對比較亂的,并且有一些示例代碼的地址已經打不開了(2020-03 時測試)。這就導致大家如果想要學習 weui 的使用,那么只能從 github 上下載一下實例代碼來學習了。
? weui 的話我們不做過多介紹,簡單總結下:
1. weui 是微信官方團隊開發的一套同微信原生視覺體驗一致的基礎樣式庫。
2. 因為只應對微信內部網頁和微信小程序,所以所提供的功能相對簡單。
3. 文檔稍微亂一些。
4. 提供的功能組件有限,主要還是應對場景的問題。
5. UI 的風格同微信原生視覺體驗一致
6. 適用微信內部網頁和微信小程序。
合理的運用 UI庫 , 可以大大的提升我們的開發效率,并且保證我們的項目設計維持在一個平均水平之上。
但是合理的使用,并不代表著完全依賴,UI 庫 可以幫助我們解決設計上 80% 的問題,但是 UI 庫也會給我們帶來一些限制,比如風格上和設計上。
所以我們大家需要合理的看待 UI 庫的存在。
作者:LGD_Sunday
*請認真填寫需求信息,我們會在24小時內與您取得聯系。