前言
首先會做這次記錄，也是因為自己也是第一次去接觸這個框架，以前總是聽說，並沒有去用過。這次出於實習的原因，去學習了一下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/