如何評價LayUI和他的作者閑心？
layui - 經典模塊化前端框架
文案寫得不錯，可是用幾年前的方式開發這不能叫經典吧……？到什麼年代了還自己搞一套模塊載入，我只能認為是不理解規範化的意義了。
最近幾天發現從知乎來了些訪問源，還頗有些些奇怪，一搜才發現原來是從這個話題中來的。既然有幸能在高大上的知乎上露臉，那還是說一兩句吧，保證就一兩句！
其實寫 layui 的出發點很簡單：滿足服務端程序員的需求。
因此可以毫不保留地說，layui 並非面向於前端開發者，所以我們在組織形式上毅然採用了幾年前的以瀏覽器為宿主的類AMD模塊管理方案。layui 定義為「經典模塊化」，絕非是自吹她自身有多優秀，也並非是刻意強調「模塊」理念，而是有意避開當下JS社區的主流方案，試圖以最簡單的方式去詮釋高效！她的所謂經典，是在於對返璞歸真的執念，她以當前瀏覽器普通認可的方式去組織模塊！ layui 認為這種輕量的組織方式，仍然可以填補 WebPack 以外的場景。所以她堅持採用經典模塊化，也正是能讓人避開工具的複雜配置，回歸到簡單而原生態的HTML/CSS/JavaScript！
有人說 layui 的「抱殘守舊」 是一項倒退，在去年剛發布時就飽受前端同行的鄙夷，很多人質疑為毛不直接擁抱MVVM？然而事實上，在國內仍有相當一部分群體依舊在採用較傳統的前端開發模式（當然主要是以服務端人員為主），由於他們的核心技能棧不在前端，所以他們總是在尋找前端界面的快速開發方案，比如老牌的BootStrap，而我們的 layui 是為了讓人們在這一條路線上有更多（或者說更好）的選擇。因此我覺得，需要有人去做這件事並且堅持下去，為著這一群體，直到他們不再需要她，然後在路邊樹立一塊碑碣，上面寫著：「layui-過往的雷鋒UI」，便揮一揮衣袖，繼續前行，也算是功德圓滿。但在這之前，我認為 layui 仍會是一個不錯的伴侶，目前日均 2w的獨立訪客就是一個證明。
當然，相比過往的UI，layui 的確還有很大的提升空間，也的確還不能稱之為「產品級」方案，但它仍在野蠻生長，我相信離成熟並不會太遙遠。
而至於作者「閑心」，也就是我咯。我從業前端六年，功力平平，在技術選型上追求實用、簡單，不屬於前端圈大雅之堂，自認為是三流前端猿。如果 layui 非出自於我，可能我也會有100種理由去無視它。現如今，我終日紮根在小眾圈中，「忽悠」 「 小白 」（別打我，這不是我說的，請參考其它回答）！因為我善良得一B，為人又熱情，對妹紙程序媛更是提供免費上門服務，所以可愛的「小白們」親切地將我稱之為「心姐」，當然我並不拒絕這種高級讚揚，儘管它顛倒了性別。
其實意義並不是特別大哈~要實現這種模塊話 webpack 可能20來行配置，並且你這個框架模塊化了，但是在一個產品稍大一點 layui 自己的實現就顯得有點多餘了~如果僅僅是實現常見 ui 層面的東西也不需要返璞歸真這樣的說法，寫個庫返回一個全局變數就可以了。
我還是擔心有人說我說的太簡單，比如你要 lazy load 對應的 css 和皮膚這種，都是花不到太多代碼的哈~
還有就是太小的項目不太需要模塊化的~大點的才需要，比如 require.js 就是配置一種 AMD 組織的方式，不用的話也可以，你需要怎麼做呢？當然，懶的特性可能你可以看下 seajs，雖然過時了，也值得學習的。
1. 調整 script 引入的順序，這個你是要保持的吧
2. 隔離作用域的閉包你要吧？然後實現一個塊的代碼，然後給一個共有的變數，返回到全局，如果你不想污染過重，就定義一個，命名空間按層級定義。
3. css 怎麼辦呢？還能怎麼辦，掛 head 頂部唄，然後要懶執行就 js load 一下…
4. 開發不僅僅 ui，ui 與數據之間的關係你是要處理的，就連最簡單的 button 點擊你可能都要有綁定數據的傳遞：比如開發一個彈框，彈框內要發請求，利用的是綁定的 id。有好幾種做法，這裡不細緻列出，只是打個比方。
不過我依然覺得賢心前輩這個付出有價值：
1. 體現編碼上，可以帶來純粹的思考，並不是說需要複雜的工具來體現，當然就如我上面說的，其實並不需要太複雜的配置和工具就能做
2. 給了一個小項目的選擇，對於小號的也許 layui 一套還是不錯的，乾淨的白白胖胖的庫
3. 提供了一個學習的例子，我看過源碼，挺乾淨的吧，賢心也說了，主要給服務端的小夥伴用，不用管前端的配置相關的東西
4. 至少乾淨的產出了，有文檔有論壇，也有早一批用戶，也挺實用的呀~
最後，工具只是給了你選擇，所以你不必太排斥，懂得在平衡和完美之間做抉擇才是一個好的程序員。作為LayUI 的忠實用戶，我非常喜歡LayUI .我們公司是一個為傳統行業服務的IT公司，並不需要太複雜的頁面，簡單實用，一直都是我的追求組件的準則。
LayUI 對我這個C#程序員，上手非常簡單，幾行代碼，幾句話，我就能熟練使用了LayUI 的彈窗，我要的就是這麼簡單。可能要被大家嘲笑我司到現在還得支持IE8.我都沒用啥vue.js等，一直到現在還在用老掉牙的jQuery .
有時候一味的追求新技術，反而會迷失自己，我有個前端同事，之前天天跟我安利啥vue，angularjs,等前端框架，，而後我對他說，你的js學好了嗎。他無言以對，我就讓他去看JavaScript權威指南，沒到一個星期，他徹底放棄啥啥框架，開始瘋狂痴迷於原生的js寫東西。導致他現在寫的js代碼，我都看不懂，媽的，這狗日的。（我司的後台程序員對程序幾乎都是一手包辦，從前端後後端）。但是我和他都有一個統一的愛好，沒事就去看LayUI。畢竟太好用了。
在這裡謝謝 @賢心
某二線城市，還處於求生存的網路創業公司。
利益相關：
花了半天時間根據layui大致弄出一個後台管理頁面，直接扔給後台的同事先用了。
從layer到layui
很方便，而且上手極快，我不懂什麼是規範化，畢竟項目小，時間緊，錢不多，人不夠。
layui的用戶定位本來就不是為了TAb或者你們這些「牛逼」的公司準備的。
說實話，貴公司如果用到layui，還用各位幹嘛？？？
所以，我覺得，這道題，不適合你們來回答，因為你們不是需求者，只是旁觀者。
如果有一天你們能像 @賢心 一樣，
能為我們這些在你們看來如同門外漢，不屑同行的開發者做一個比layui更牛叉的框架時，
我也會在別人只看缺點不看優點瞎BB時做出正確的立場判斷。
以上，初出茅廬，不懂謙讓，望各位看官見諒。
@顧軼靈
前輩若是能跳槽到其他公司真的不要再百度待了，一年前的事件，
如何看待「每一個入職百度的員工都會被釘在互聯網的恥辱柱上」這句話？ - 知乎
雖有偏激，與虎謀皮，且行珍重。
最後，感謝layui的作者，可能您的技術不是最棒的，
但卻有很多和我一樣的人在使用您的作品，祝平安喜樂。
不是很符合現在前端的發展趨勢，但是只要有一部分人覺得有用、好用，能從中學到東西，就還是有意義的
1）Layui是應需求而生，目標用戶非常明確服務端程序員。
作為服務端人員一枚，在和前端同學求助的時候，大部分情況都是很不情願支持，要支持的話就要用webpack什麼的。你說我們一個後台程序這點需求用的著用這麼大的殺器嗎？無非是菜單，列表，卡片，彈框，數據聯動這幾個需求而已，如果非要服務端同學自己鼓搗，時間給足也不是不可以的。可大部分情況下這個時間是不允許的，把業務搞出來才是最終目的。這個時候用的BootStrap和Layui的聯合使用，簡直perfect。所以Layui能收到服務端同學的支持就是必然。
2）滿足服務端程序員的需求，這個洞察力就不是一般人能達到的。
大部分程序員同學還在為炫技感到興奮的時候，人家閑心同學看到的是更深層次的業務需求，從這個層面上看就比別的同學高出多少倍。目前大部分前端大牛都在搞移動前端框架，如果再搞一個類似的框架估計很難脫穎而出，不如反其道而行。
純個人看法
支持layui的作者，實用即可，有應用場景即可。
最近在改一個傳統的不得了的網站，jquery，純過程化編碼。要加些新頁面和功能，Bootstrap用不了，因為原先的模板代碼中有很多class命名與Bootstrap的互相衝突，要麼把原先網站的代碼改一遍，不能保證無bug，要麼覆蓋一些Bootstrap默認的樣式規則。
這種情況下，選擇了layui，學習成本不高，上手很快，樣式還不錯，很省時地解決了問題。
難道非得加一堆webpack、npm、mvvm，重新搞個網站？能節約成本是價值體現的一大重點。
我覺得吧，都在說服務端同學做CMS系統開發簡單什麼的。。。
難道都沒玩過antd嗎。。。
我之前是做傳統電信系統的，記得以前做功能的時候，一般都是一個人前端後端都做的，後來到互聯網公司了，大家開始搞前後端分離了，前端專心做前端，後端專心做後端，最開始的時候還能讀懂前端的代碼，後來隨著前端技術的突飛猛進，就不再能看懂了，對我這個後端程序員來說要做個界面只能老老實實用easyui，bootstrap，最近才開始用layui，發現確實很不錯，學習成本低，開發成本也低，對我來說確實是個福音，給賢心點100個贊~
這年頭做個破網頁也產生鄙視鏈了嗎？
我覺得閑心做的ok.
所謂的經典模塊化，沒什麼優勢，模塊化一個主要問題是請求數過多，貌似沒有得到解決。
粗略看了看插件也不是很齊全，感覺距離產品級還差一截。作者很有閑心
我是做後端開發的，也跟著經歷幾代前端的變遷，這些變遷都是往好的方向去走的，現在有很多前端沒經歷過IE6的那個年代，這是件好事，最早前的各種標準（算是最早的前端框架），到慢慢有bootstrap這些框架出來，後端的開發人員現在很容易上手調試修改，現在又有了MVVM，前後端的工作基本上沒有太多干擾的地方，前端開發現在有webpack這真是個好的東西，不用去再一直造輪子咯，自己也可以選擇做一個跑車的部件出來，也可以用別人跑車的部件咯，不能因為webpack對於小白來說有點難理解就放棄，webpack是真心好用，多花點心思肯定能學會的，layer滿足閑心自己的定位設想我個人是很支持的，但要等到layer成為一輛跑車的時候，webpack的大夥已經開始造飛機咯。有人評價存在即有價值，那是必然的，但當你花了大半年用layer做了項目後，發現滿世界都是react,vue,angular，你做項目招不到人維護或者你無法再找到另一份使用layer的工作時候，你又得重新開始學慣用webpack,學習react,vue,angular，這或許就是上了這條賊船，就必須這樣堅持學下去。layer作為個人興趣，想多學點，個人完全支持的， @閑心 既然決定了layer2.0，那就繼續努力吧，但離layer完整版還有好遙遠的路，加油咯！
最起碼我寫不出來這一套代碼，為賢心點贊
說說起源吧，我是一名後端開發者，走java路線，16年的時候，前端大發展，迫於無奈學了angularjs1.5，然後慢慢入坑，追到現在的angular5.0，vue，reacte。
然後有一天我跳槽了，維護一個項目時有人用的layui，然後改bug的時候，查layui的文檔，與閑心待過同一個公司，可惜的是我入職的時候他已經離職了，第一次看到他的名字是在一個前端分頁組件中，赫然寫著author: by @閑心 ，順便感受了下他的代碼，不看不知道，一看瞬間覺得這是個骨骼清奇，對代碼有深度追求的前端高手，後來又在別的同事口中聽說，他目前在自己定製自己的前端插件產品，看到現在的LayUI，也是深表讚歎。
在如今浮躁的前端行情，能夠遺世獨立，保留自己心中的那一份純真，我覺得這已經是非常難能可貴的事了，希望他能繼續保持初心，繼續產出高效，好用的前端組件！
總有人覺得簡單便是low
既然是如何評價, 那麼就要容得下批評, 如果說批評的不對, 請用事實和你的觀點去反擊, 玩戴帽子的把戲和人身攻擊有意思嗎? 看回答, 還以為前端把你們怎麼滴了似的.
評價一個前端框架, 一幫人喊著讓前端閉嘴, 佩服 佩服.
如果說要做模塊化, 又不想使用webpack等打包工具, 那麼完全可以使用諸如AMD之類的模塊規範
首先, AMD規範是JS社區公認的模塊標準, 應用的範圍廣, 基本上前端常用的庫都做了對AMD的支持.
第二, AMD規範有大量成熟的模塊載入器(Require.js, System.js), 可以實現瀏覽器級別的模塊載入,使用上並不會比layui的模塊載入器複雜.
layui做了一套不與任何標準兼容的方案, 帶來的負面影響有兩個:
- 很難將layui整合到現有的項目中
- 如果一個全新的項目, 從開始時就按照layui的標準來開發, 那麼當你需要在項目中引入其他庫時, 必須進行手動的包裝, 使其能夠被layui的模塊載入器載入, 具體的例子可以參見layui中jQuery是如何變成layui模塊的.
當然, 你可以直接使用script標籤直接引入, 但是你使用這種方式的話, 模塊化的意義何在呢?
很明顯, 這樣會增加開發成本, 不是正與作者提出的簡單, 高效背道而馳嗎?
關於這個問題我必須說幾句。
1、lay ui面向的是後端開發人員，前端就別在這裡瞎比比；
2、後端人員不喜歡寫前端代碼，layui簡單易用，我們只需要模仿寫就可以寫出特效和樣式，讓後端的人專註邏輯開發；
3、謝謝layui開發者。 @賢心
推薦閱讀：
※axure既然能畫高保真模型，為什麼不技術上優化代碼，直接用於前端？
※前端頁面如何做到和設計稿一比一完美實現？
※自學前端四個月怎麼樣才能找到一個實習？
※css3的字體大小單位[rem]到底好在哪？
※怎樣做一個漂亮的 GitHub Pages 首頁？
TAG:前端開發 |