前言
首先會做這次記錄，也是因為自己也是第一次去接觸這個框架，以前總是聽說，並沒有去用過。這次出於實習的原因，去學習了一下Layui這個“面向後端開發者的框架”。其次，此篇記錄僅供參考，畢竟我也不是開發者，所以不能保證文章引用的內容以及自己的理解是否正確，請自行決斷一些內容的正確性。
前段時間看到一個不錯的部落格是個人寫的關於前端面試的還是比較全面基礎的（雖然個人是後端，但是如果有學前端的看到這篇隨筆，可以當做參考一下）
在這裡貼出來：
【GitHub】：https://github.com/WindrunnerMax/EveryDay
【部落格】https://blog.touchczy.top/#/
Layui
官方文件：https://www.layui.com/doc/
官方示例：https://www.layui.com/demo/
Gitee：https://gitee.com/sentsin/layui
GitHub：https://github.com/sentsin/layui
簡介
做總結的時候才發現其實自己要總結的點還是比較少的，因為官方文件已經說的很詳細了，所以在此我想說的是，目前個人用的多的還是像元件這類東西，畢竟現在基本都是封裝之後的東西，而且這些封裝過後的東西也是用的比較多比較爽的，還有就是Gitee上有一個開源模板"Layuimini",個人感覺作為後臺BOSS的模板還是挺不錯的，畢竟大部分人覺得layui比amazeui稍微好看一點點（不過還是出於真心，各有各的好，有的人也覺得amazeui更好看一點，至於官網地址自己可以搜搜看，我放文章後面了）。
像框架、工具這類的東西，感覺直接看官網文件是來的較快而且比較權威的。
【開源倉庫】Layuimini：https://gitee.com/zhongshaofa/layuimini
內容摘抄於官方文件中——入門指南篇
layui（諧音：類 UI) 是一套開源的 Web UI 解決方案，採用自身經典的模組化規範，並遵循原生 HTML/CSS/JS 的開發方式，極易上手，拿來即用。其風格簡約輕盈，而元件優雅豐盈，從原始碼到使用方法的每一處細節都經過精心雕琢，非常適合網頁介面的快速開發。layui 區別於那些基於 MVVM 底層的前端框架，卻並非逆道而行，而是信奉返璞歸真之道。準確地說，它更多是面向後端開發者，你無需涉足前端各種工具，只需面對瀏覽器本身，讓一切你所需要的元素與互動，從這裡信手拈來。
layui 定義為「經典模組化」，並非是自吹她自身有多優秀，而是有意避開當下 JS 社群的主流方案，試圖以儘可能簡單的方式去詮釋高效！她的所謂經典，是在於對返璞歸真的執念，她以當前瀏覽器普通認可的方式去組織模組！我們認為，這恰是符合當下國內絕大多數程式設計師從舊時代過渡到未來新標準的絕佳指引。所以 layui 本身也並不是完全遵循於 AMD 時代，準確地說，她試圖建立自己的模式
//layui 模組的定義（新 js 檔案）
layui.define([mods], function(exports){
//……
exports('mod', api);
});
//layui 模組的使用
layui.use(['mod1', 'mod2'], function(args){
var mod = layui.mod1;
//……
});
沒錯，她具備早前 AMD 的影子，又並非受限於 CommonJS 的那些條條框框，layui 認為這種輕量的組織方式，比WebPack更符合絕大多數場景。所以她堅持採用經典模組化，也正是能讓人避開工具的複雜配置，迴歸簡單，安靜高效地編織原生態的 HTML/CSS/JS。
但是 layui 又並非是 RequireJS 那樣的模組載入器，而是一款 UI 解決方案，與 BootStrap 的不同又在於：layui 糅合了自身對經典模組化的理解。這使得你可以在 layui 組織的框架之內，以更具可維護性的程式碼、去更好的編織豐富的使用者介面
JavaScript模組化開發
早期的Javascript是作為瀏覽器的指令碼語言，使用
標籤直接引入，沒有所謂的模組化。也就是說如果我們需要一個js檔案，我們就加一個
標籤，把需要的js引入進來。這種方式的特點在於：簡單粗暴。
但是當專案越來越大，依賴越來越多時可能就會出現問題，比如邏輯越來越混亂，頁面也越複雜，然後可維護性就變差了，除此之外還存在全域性變數暴露、檔案的引入順序的問題。比如說一個檔案引入另一個檔案，另一個檔案又依賴另一個檔案，那麼這三個載入資料就會很重要，如果第一個沒有載入完，那麼接下來就會出錯。
實際上，在JavaScript的發展歷史上，第一個真正模組化的是nodejs，nodejs就是使用了我們其中的一個模組化標準的規範，它就是common js。
有了這個模組化的概念後，便有了node，node的檔案管理都是基於模組化的；我們可以從另一個角度來看，如果JavaScript想要進軍服務端，在服務端沒有模組化這是一個災難，因此common js社群制定了一個commonjs規範，也就是模組化的規範；有了這個規範之後，node就出現了。
JavaScript引入模組化解決了哪些問題：
避免了全域性汙染
模組複用，提高了開發效率和協作
模組功能單一職能方便維護
解決了檔案依賴順序
模組化的標準（有三個）：
CommonJs
AMD - 非同步模組
CMD - 通用模組
AMD (非同步模組定義Asynchronous Module Definition)格式的最終目的是提供一個當前開發者能使用的模組化Javascript方案。它出自於Dojo用XHR+eval的實踐經驗，這種格式的支持者想在以後的專案中避免忍受過去的這些弱點
AMD是"Asynchronous Module Definition"的縮寫，意思就是"非同步模組定義"。由於不是JavaScript原生支援，使用AMD規範進行頁面開發需要用到對應的庫函式，也就是大名鼎鼎RequireJS，實際上AMD 是 RequireJS 在推廣過程中對模組定義的規範化的產出
它採用非同步方式載入模組，模組的載入不影響它後面語句的執行。所有依賴這個模組的語句，都定義在一個回撥函式中，等到載入完成之後，這個回撥函式才會執行。
RequireJS主要解決兩個問題
多個js檔案可能有依賴關係，被依賴的檔案需要早於依賴它的檔案載入到瀏覽器
js載入的時候瀏覽器會停止頁面渲染，載入檔案越多，頁面失去響應時間越長
CommonJS模組建議指定一個簡單的用於宣告模組伺服器端的API，並且不像AMD那樣嘗試去廣泛的操心諸如io，檔案系統，約定以及更多的一攬子問題。
這種形式為CommonJS所建議--它是一個把目標定在設計，原型化和標準化Javascript API的自願者工作組。迄今為止，他們已經在模組和包方面做出了批覆標準的嘗試
根據CommonJS規範:
1.一個單獨的檔案就是一個模組。每一個模組都是一個單獨的作用域，也就是說，在該模組內部定義的變數，無法被其他模組讀取，除非定義為global物件的屬性。
2.輸出模組變數的最好方法是使用module.exports物件。
3.載入模組使用require方法，該方法讀取一個檔案並執行，返回檔案內部的module.exports物件
CMD 即Common Module Definition通用模組定義，CMD規範是國內發展出來的，就像AMD有個requireJS，CMD有個瀏覽器的實現SeaJS，SeaJS要解決的問題和requireJS一樣，只不過在模組定義方式和模組載入（可以說執行、解析）時機上有所不同
最後可參考這些文章（仔細甄別內容正確性，因為我也是做了個參考，並未保證這些文章百分百正確）：
前端模組化，
談談我的理解-元件化/模組化，
對前端工程化、模組化、元件化開發的理解。
前端框架官方文件
【Vue.js】
https://vuejs.bootcss.com/guide/
https://cn.vuejs.org/
【ElementUI】
https://element-plus.gitee.io/#/zh-CN
【Layui】
https://www.layui.com/
【妹子UI（amazeui）】
http://amazeui.shopxo.net/
【Semantic UI】
https://semantic-ui.com/
【EasyUI】
https://www.jeasyui.net/
【BootStrap】
https://www.bootcss.com/
【Bootstrap視覺化佈局】
https://www.bootcss.com/p/layoutit/