页面组件化
UI来自elementUI
还记得原先熟练地敲出这样一个HTML文档：
jq时代
这是属于jq的时代，直到后来我的膝盖中了一箭，没错，箭是Angularjs射出的，当然这之间还有一些历程，比如Backbone.js的出现再到Angularjs，从mvc模式到mvvm的过渡，不过这已经是很久之前的事了。
在这里我还是要推荐下我自己建的web前端开发学习群：617327703，群里都是学web前端开发的，如果你正在学习前端 ，小编欢迎你加入，今天分享的这个案例已经上传到群文件，大家都是软件开发党，不定期分享干货（只有前端软件开发相关的），包括我自己整理的一份2018最新的前端进阶资料和高级开发教程，欢迎进阶中和进想深入前端的小伙伴。
现在是SPA（single-Page Web Application）或者MPA（multi-Page Web Application）的时代了，去年最火的莫过于这三个框架了
spa-frame
如果你的项目还没用到这些，那就不妨试试吧
JS模块化
从无模块时代，到萌芽时代，再到CMD/AMD，到现在的ES6标准
JS模块化的简单描述
JS模块化的优点有：
大文件分解功能单一的小文件，便于维护
功能按需加载，增加可复用性
文件异步加载，提高性能
管理文件依赖
减少命名冲突，变量污染
多人协作互不干扰
如果你遇到上述问题，是时候考虑一下使用模块化解决了
CSS 演变
CSS是一个页面的衣服，年代在变化，时尚在流行，从CSS，到CSS3，到Sass/Less/Stylus，到CSS Modules，再到PostCss， 以及CSS in JS，而你或许还光着大膀子，使用着css，为了兼容lowB浏览器，还不敢使用css3，好吧，如果你这样，看我眼神→_→
以一个元素的圆角边框的样式的不同写法
传统的css，在没有css3新加特性的情况下，实现一些特殊的效果，是比较复杂的；而css3本身是很好的，但是由于各大浏览器厂商呀，又得使用hack来兼容多浏览器；
CSS preprocessor技术，如sass，less，stylus等等预先处理css，编辑成我们想要的样式，同时在css中加入了部分js语法，更加方便书写css；
stylus和sass去除了‘{’，‘}’和‘；’，使用缩进来代替层级关系，使css书写更加简便；
postCss不是一个预处理器，而是一个平台，我们可以在上面直接添加我们想要对css文件处理的插件，就可以生成相应的css，比如有了 Autoprefixer，你不再需要担心前缀选择了，有了Stylelint 可以检测css中的错误，使用cssnano压缩css文件等等；
css-modules通过一个随机固定的属性来限制css的样式作用域；
css in js 目前还处于争议阶段，这个改变的就是我们的页面书写习惯了，原先是以html元素为主，后添加样式，而css in js 则正好相反，以带有样式的元素去构建页面，当然css in js 也有不同的实现方式，有style，也有inline-style等等
css命名
总结了以前用到的几种命名方式，根据项目的需求和未来扩展具体使用不同的命名方式或者多种方式的组合
随意命名
随意命名给维护和扩展带来了非常大的不利，也给那些想看你代码的人（同事或者爬客）带来了小小的心理困扰
以功能模块命名
例如：
登录模块：login 里面的元素命名都以login-**这种方式 公共模块： 里面的元素命名都以pub-**这种方式
以功能模块来命名，能清晰明了的知道该样式是起什么作用的，但是代码复用性差
姓氏命名法
姓氏命名法就是以父元素的完整类名为自己的类名前缀，例如：
新闻列表 new --new-list ----new-list-con ------new-list-con-title ------new-list-con-img ------new-list-con-author -------new-list-con-author-portrait -------new-list-con-author-name ----new-list-nature ------new-list-nature-createTime ------new-list-nature-pageView
清晰明了的结构，但是如果层级越深，类名就越长，当然我们也可以简写，或者只取父元素和祖父元素的类名，另一个问题，页面布局调整，就需要调整好多相关样式，而且复用性极差
BEM命名
BEM即Block-Element_Modifier，Block是功能块，Element是元素，Modifier是修饰符
菜单模块.menu.menu-item.menu-item.active / .menu-item_active
BEM是一种很好的规范，我们从名字上就能看出来这个类名的作用，但是也很容易被滥用，很容易会被写成B-E-E-M，类名太长，这样就不合适了
oocss
oocss是把css看成一个单独的css样式，更宽泛的说，本身css就是oocss，因为每一个样式都可以独立出来，不过这样并没什么用，下面是一个按钮的例子：
// 未经处理的css
<button class="btn"></button>
.btn{
display:inline-block;
font-size: 16px;
color: #fff;
line-height: 1.5;
border: 1px solid #ccc;
border-radius: 2em;
background-color: #eee;
}
// oocss处理
<button class="inlineBlock fontSize16 border1 whiteColor grayBgColor submitBtn"></button>
.inlineBlock{
display:inline-block;
}
.fontSize16{
font-size: 16px;
}
.border1{
border: 1px solid #ccc;
}
.whiteColor{
color: #fff;
}
.grayBgColor{
background-color: #ccc;
}
.submitBtn{
line-height: 1.5;
border-radius: 2em;
...
}
oocss的特点是把样式分解为小的样式，通过小的样式之间的组合来渲染元素，这样样式的复用性很强，但是元素上写了太多的类名，也着实不美观
ooscss
ooscss是oocss和scss的组合，接着上面的例子，我们可以这样改进：
// ooscss处理<button class="submitBtn"></button>%inlineBlock{
display:inline-block;}%fontSize16{
font-size: 16px;}%border1{
border: 1px solid #ccc;}%whiteColor{
color: #fff;}%grayBgColor{
background-color: #ccc;}.submitBtn{
@extend %inlineBlock;
@extend %fontSize16;
@extend %border1;
@extend %whiteColor;
@extend %grayBgColor;
line-height: 1.5;
border-radius: 2em;
...}
ooscss通过继承来实现元素类名的减少化，当然实际开发中，也不会出来这么分离的类，因此ooscss对于组件化开发还是比较友好的
布局
布局由原先的Table（原始时代，庆幸没经历过）到Float + Position布局，之后是使用百分比和Rem实现的自适应布局，典型的有Bootstrap；之后是@media实现的响应式布局，到现在流行的Flex布局，以及Grid布局.
Ajax
ajax的出现可以说对前端是一次关键的转折，提出了一种新的开发方式；数据请求的发展也两年由于复杂业务的逻辑实现，使得传统的Ajax使用起来比较繁琐，比如callback hell；因此出现了Promise，可以通过链式调用的方式来实现callback，我以为这样的改进已经最好的了，直到我看见Es6的Generator/yield 和 async/awite，WTF，像写同步代码一样写异步请求，可以这么简洁，其实就是语法糖而已，但是这个糖比较甜(*^▽^*)
打包
就说几个目前使用比较多的工具：
Gulp：基于流的自动化构建工具，相对于百度的Fis，就类似于sublime和ide的区别吧，而对比Grunt，Grunt 运用配置的思想来写打包脚本，Gulp 是用代码方式来写打包脚本，并且代码采用流式的写法，即gulp.task()，对于项目开发还是推荐Gulp，轻量，灵活；随着模块化和SPA应用的项目越来越多，全新的webpack3（webpack2其实刚出世没多久）或许是更好的选择；
Webpack：Webpack 是一个打包工具，能将多个资源模块打包成一个或少数文件；而Gulp/Grunt自动化构建工具并不能把所有模块打包到一起，也不能构建不同模块之间的依赖图，Webpack通过loader 和 plugin可以做一部分 gulp／grunt 能做的事，但是插件还是不如 gulp／grunt 的插件丰富；Webpack最复杂的地方就是配置了，这个多踩几个坑，就好了啦。最近又看到了Parcel，零配置哦，对于新晋小将，抱着观望的态度，为何不去尝试一下呢
状态管理
随着前端从随意化到工程化的演变，其特征更加的表现为：视图组件化、功能模块化与状态管理，或许状态管理你并没有在使用，但是为了以后项目的扩展，还是预留一下接口；在项目比较小的时候，我们经常把一些数据放在localstorage中，其实这就是简单状态共享，而当项目复杂起来之后，再使用localstorage就显得不那么得心应手了，我们就需要引入一个专门管理状态的一个框架，首先这个框架的特点得有：
状态能够被不同组件之间共享。（早期的React中使用Props一层一层地传递或者通过公共父节点来传递。vue使用单向数据流的方式）
状态能够在任意地方被访问和修改
状态的修改应该被记录
有以下几个状态管理的框架，可以应用于项目中：
Flux : 一种前端代码思想， 寸志：图解 Flux
Redux：React的好基友， Read Me · Redux
MobX：Redux的替代者， Introduction | MobX
Vuex：Vue的好基友， 状态管理 — Vue.js
编辑器
我的编辑器改变之路，个人喜好
总结
在前端技术迅速变化的时代，要做的就是，把握现在，拥抱未来。
2018，你需要懂这些了
扫一扫
5236
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
