关于ecarayPC端的前端架构分享

[hehongwei44]

我觉得技术架构选项主要通过项目类型、兼容性、团队水平这三点作为参考。从目前来看，公司项目的主要类型为管理系统，其次是功能简单的官网和移动端。特别是管理系统包含了大量业务处理，所以目前代码主要是处理表单和数据为主，而大量的表单和数据处理并不是JQuery的强项，可以考虑使用MVVM这类框架来处理，然后是兼容性，兼容性这块，目前的需求是IE8+，所以现在流行的VUE、Angular2等框架都不适用。基于这几点，管理系统技术选项这块就选择了LESS+knockout+requirejs+gulp+pagejs+jquery这样的技术栈。（PS:公司目前以前实现前后端分离，且SEO方面不予考虑）。下面就谈谈这个技术栈的优缺点。

CSS预处理介绍（LESS）

LESS是什么？

Less 是一门 CSS 预处理语言，它扩展了 CSS 语言，增加了变量、Mixin、函数等特性，使 CSS 更易维护和扩展。除了LESS之外，还有其他的预处理语言，比如：SASS、SCSS、Stylus，只所以选择LESS,是因为LESS更容易上手。

LESS的优缺点

1. 结构清晰，便于扩展。对于模块很多的应用特别是单页 app，经常需要用 selector 来划分不同模块的 CSS 的 scope。如果满眼望去全 是 .module .action .list a, .module .action .list a:hover 很难直观地理解样式应用的范围；而写成

.module {
　.action {
　　a, a:hover {
　　　//styles
　　}
　}
}
//other modules

这样要清晰得多。这样可维护性必然会高很多，举个例子：如果要改变样式的应用范围，增加一个适用的 action，只需把 .action 改成 .action, .action2 即可，而纯 CSS 就悲剧了，要修改每个相关 rule set 的 selector。
2. 可以方便地屏蔽浏览器私有语法差异。这个不用多说，封装对浏览器语法差异的重复处理，减少无意义的机械劳动。
3. 可以轻松实现多重继承。

.box {
　display: block;
}
.thick-bordered {
　border: 5px solid black;
}
.notice {
　.box;
　.thick-bordered;
}

这样无论父类有什么改动子类都会同步更新。有人说这个在 HTML 中把 class 写成 "notice box thick-bordered" 就好了，但是这样增加了HTML 与样式的耦合，如果模板中有多个 .notice 在修改时就难免做重复劳动，同时除了修改过的 CSS 文件外，客户端缓存的 HTML 模板也需要重新下载。在 LESS 中，如果利用 mixin 来作继承在编译后都无需生成无用的父类样式代码。
4. 完全兼容 CSS 代码，可以方便地应用到老项目中。LESS 只是在 CSS 语法上做了扩展，所以老的 CSS 代码也可以与 LESS 代码一同编译。

LESS的缺点：

1. 须要编译。无论是放在客户端还是服务器端，都是一种额外的花销。
2. 作者更新不够活跃，对社区的力量使用不足。作者对 GitHub 上的 pull request 基本置之不理，他解释说是 GitHub 上的通知让他看不过来 所以基本都无视了。所以使用中遇到的一些问题可能官方代码得不到及时的更新。

作者：顾轶灵
链接：https://www.zhihu.com/question/20259365/answer/14520148

前端路由介绍(page.js)

前端路由的作用

在web开发中，“route”是指根据url分配到对应的处理程序。本质上和后端路由没有什么不同。前端路由应用场景更多用在单页应用上, 也就是SPA。

前端路由的优点

1. 当浏览器读取到其中一个注册到前端路由中的 URL 请求时，比如 http://www.this-is-a-spa.com/a 时，可以触发预先写好的事件 A，所以当访问到这个 URL 后就可以直接触发到事件。在编写的时候可以用 Event A 来触发事件，而可以不用 addEventListener("click", ...) 这种写法，当项目逻辑比较复杂的时候，这种组织方式比写一大堆事件注册要好很多.（当然上 SPA 一般都用到了框架，这种方式只是一种选择）
2. 用户可以收藏 http://www.this-is-a-spa.com/a 至收藏夹，打开后直接触发 /a 的事件（然后就自动加载数据或是什么别的事情），而没有做前端路由的 SPA 则达不到这样的效果，其 URL 从头到尾都是不变的.
   3.最大的有点我觉得是通过路由组织的代码更容易维护和修改。有后台的开发经验的同学对路由熟悉不过了，通常对代码问题的定位都是从路由开始，然后找到路由相对应的动作（Action）,前端亦是如此，同时前端路由的引入，类MVC的分层的结构也变得更清晰了。

前端路由的缺点

感觉没什么缺点，硬要说一个的话，那么就是学习成品增加了。

JavaScript文件和模块加载器（RequireJS）

RequireJS的作用

随着网站功能逐渐丰富，网页中的js也变得越来越复杂和臃肿，原有通过script标签来导入一个个的js文件这种方式已经不能满足现在互联网开发模式，我们需要团队协作、模块复用、单元测试等等一系列复杂的需求。

RequireJS是一个非常小巧的JavaScript模块载入框架，是AMD规范最好的实现者之一。最新版本的RequireJS压缩后只有14K，堪称非常轻量。它还同时可以和其他的框架协同工作，使用RequireJS必将使您的前端代码质量得以提升。他显著的作用有以下两点

1. 一是模块化，写功能按照模块来写，JS 文件也分割出来存放。
2. 二是性能，以前一大坨，按需加载只需要一大坨里面的一部分。

RequireJS的优点

1. 防止js加载阻塞页面渲染

2. 使用程序调用的方式加载js，防出现如下丑陋的场景

   <script type="text/javascript" src="a.js"></script>
   <script type="text/javascript" src="b.js"></script>
   <script type="text/javascript" src="c.js"></script>
   <script type="text/javascript" src="d.js"></script>
   <script type="text/javascript" src="e.js"></script>
   <script type="text/javascript" src="f.js"></script>
   <script type="text/javascript" src="g.js"></script>
   <script type="text/javascript" src="h.js"></script>
   <script type="text/javascript" src="i.js"></script>
   <script type="text/javascript" src="j.js"></script>
   

3. 作用域隔离，避免污染全局作用域。

RequireJS的缺点

学习成本比较高，通过r.js产生后的代码只有一个入口。

MVVM框架介绍(knockout)

knockout介绍

在web开发中，“route”是指根据url分配到对应的处理程序。本质上和后端路由没有什么不同。前端路由应用场景更多用在单页应用上, 也就是SPA。

knockout优点

1. 简化代码
2. 减少重复
3. 强制规范
4. 集中精神编写业务逻辑
5. 易于扩充
6. 数据触发事件
7. 面向数据编程
8. 代码容易维护，结构分层清晰

knockout缺点

学习成本增加，文档大部分是英文，英文不好的学习起来比较懵逼

gulp和Jquery的选择

下面简要介绍gulp和Jquery，毕竟它们不是SPA的重要组成成分。

gulp这个构建工具用来实现脚本的压缩、合并、LESS预编译、添加MD5版本戳等功能。

Jquery可能是前端开发人员最熟悉的技术栈之一了。在SPA中主要扮演的角色是提供辅助的函数，实现一些特效动画，并且通过改造原因的插件，使其和knockout很好的合作。

脚手架介绍

开源地址：https://github.com/hehongwei44/ecaray-quick-start

[hehongwei44]

上面介绍的是管理平台的技术栈。官网由于业务比较简单，而且考虑SEO，所以SPA不是明智的选择，还是传统的后台输出页面比较好，官网的技术栈可以考虑：FIS3+Jquery+LESS.

移动端的业务也不是很复杂。技术栈可以考虑：zepto+路由+less+gulp,参考项目可以借鉴：https://github.com/weui/weui/blob/master/gulpfile.js

[hehongwei44]

一篇关于前端模块化的文章：seajs/seajs#547