layui框架结构（为何自称经典模块化框架的layui一直被饱受诟病）
layui框架结构（为何自称经典模块化框架的layui一直被饱受诟病）删除和批量删除基本是不需要改的，里面的所有执行方法也不需要改，需要改的只是每个编辑、新增的对话框以及提交的参数，这样相当于节省了80%的前端开发时间，再结合作者前面所说的后台数据接口框架，那么做一个维护的功能简单的增删改查一天做几个是不成问题的。后台框架的代码我再展示一下吧，前面写的文章被大量抄袭模仿，最近发不了类似的文章。权限部分当然如果所有样式什么的创建的时候直接写到库里的话这里就只剩下for循环了，不需要做判断了以上两端代码主要实现数据表格头部菜单条的权限和表格操作的权限
layui自称为“经典模块化”框架，但是一直不受专业前端开发人员的待见，因为他并没有直接按照前端的主流趋势MVVM框架去开发，而且他不是为前端人员而生的，知乎上有个作者“闲心”做了一段总结个人觉得非常到位。大致如下：“layui 的出发点很简单：满足服务端程序员的需求。
因此可以毫不保留地说，layui 并非面向于前端开发者，所以我们在组织形式上毅然采用了几年前的以浏览器为宿主的类AMD模块管理方案。layui 定义为“经典模块化”，绝非是自吹她自身有多优秀，也并非是刻意强调“模块”理念，而是有意避开当下JS社区的主流方案，试图以最简单的方式去诠释高效！她的所谓经典，是在于对返璞归真的执念，她以当前浏览器普通认可的方式去组织模块！ layui 认为这种轻量的组织方式，仍然可以填补 WebPack 以外的场景。所以她坚持采用经典模块化，也正是能让人避开工具的复杂配置，回归到简单而原生态的HTML/CSS/JavaScript！
有人说 layui 的“抱残守旧” 是一项倒退，在去年刚发布时就饱受前端同行的鄙夷，很多人质疑为毛不直接拥抱MVVM？然而事实上，在国内仍有相当一部分群体依旧在采用较传统的前端开发模式（当然主要是以服务端人员为主），由于他们的核心技能栈不在前端，所以他们总是在寻找前端界面的快速开发方案，比如老牌的BootStrap，而我们的 layui 是为了让人们在这一条路线上有更多（或者说更好）的选择。因此我觉得，需要有人去做这件事并且坚持下去，为着这一群体，直到他们不再需要她，然后在路边树立一块碑碣，上面写着：“layui-过往的雷锋UI”，便挥一挥衣袖，继续前行，也算是功德圆满。但在这之前，我认为 layui 仍会是一个不错的伴侣，目前日均 2w的独立访客就是一个证明。”
那么我也简单的用了一下这个框架，个人感觉作为一个非专业的前端开发人员来说，这个框架上手非常之快，基本都不需要阅读文档，完全照抄demo就可以完成，之前也用过vue，相比vue而言这个框架上手实在太快了，如果只是做管理系统，项目周期短、兼容性要求稍高等类似这种短平快的项目完全可以用这个框架，很快就可以完成。除了js框架本身他还有一套与之对应的css，而vue要用element配合，感觉还是很麻烦，给专门做前端的同事可能vue要比layui更好，但是具体还得看项目的实际情况和人员的架构情况吧。
权限部分
当然如果所有样式什么的创建的时候直接写到库里的话这里就只剩下for循环了，不需要做判断了
以上两端代码主要实现数据表格头部菜单条的权限和表格操作的权限
删除和批量删除基本是不需要改的，里面的所有执行方法也不需要改，需要改的只是每个编辑、新增的对话框以及提交的参数，这样相当于节省了80%的前端开发时间，再结合作者前面所说的后台数据接口框架，那么做一个维护的功能简单的增删改查一天做几个是不成问题的。后台框架的代码我再展示一下吧，前面写的文章被大量抄袭模仿，最近发不了类似的文章。
控制层
