Vue-01-前端背景介绍

Vue:前端体系、前后端分离

1.概述：

vue:一套构建用户界面的渐进式框架，发布于2014.2。Vue 只关注视图层，采用自底向上增量开发的设计。通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件，容易与其它三方库（vue-router:跳转，vue-resource:通信，vuex:管理）或已有项目整合
遵循SOC（Separation of Concerns）关注点分离。不同领域的功能有不同的代码和最小影响的模块构成。

好的架构必须使每个关注点相互分离，也就是说系统中的一个部分发生了变化，不会影响其他部分。即使需要改变，也能够清晰地识别出那些部分需要改变。如果需要扩展架构，影响将会最小化，已经可以工作的每个部分都将继续工作。——Ivar Jacobson(《AOSD中文版》) 作者：清澄秋爽 https://www.bilibili.com/read/cv14710136

Vue可以驱动采用单文件组件和Vue生态系统支持的库开发的复杂单页应用。
视图层：HTML+CSS+JS给用户展示和拉取后台数据。
网络通信：axios
页面跳转：vue-router
状态管理：vuex
Vue-UI：ICE

2.前端三要素

2.1HTML结构层

决定网页的结构和内容

2.2 表现层

css（层叠样式表）：是一门标记语言，非编程语言。不具备任何语法支持。不能自定义变量，不能引用等。只是决定网页的样式。
缺点：

语法不强大，无法嵌套书写，导致模块化开发中需要书写重复的选择器

没有变量和合理的样式复用机制，是的逻辑上相关属性必须以字面量形式重复输出，导致难以维护。

导致增加了许多工作量。后来使用了css预处理器的工具，提供css缺失的复用机制，减少冗余代码提高代码可维护性。
css预处理器定义了一种新的语言，主要是通过用一种专门的编程语言，为css添加一些编程特性，进行web页面样式设计，再通过编译器转换编译生成css文件。
常用CSS预处理器：现有流行库有Sass(Scss)、Less、Stylus等，目前，广泛使用的是 less 和 sass 。
用less来编程，编译后成为css

sass:基于ruby,通过服务器端处理，功能强大，解析效率高。但需要学习ruby语言，入手难度高于less

less:基于node.js,通过客户端处理，使用简单。解析效率低于sass.功能简单。

CSS后处理器：CSS后处理器是对CSS进行处理，并最终生成CSS的预处理器，它属于广义上的CSS预处理器。最典型的例子是CSS压缩工具（如clean-css）。后处理器例如：PostCSS，通常被视为在完成的样式表中根据CSS规范处理CSS，让其更有效；目前最常做的是给CSS属性添加浏览器私有前缀，实现跨浏览器兼容性的问题。

2.3 JS行为

一种弱类型脚本语言，源代码不经过编译（在发到客户端运行之前不需要经过编译），将文本格式和字符代码发送给浏览器解释运行，控制网页行为

Native原生JS开发

原生JS开发，也就是让我们按照【ECMAScript】标准的开发方式，简称是ES,特点是所有浏览器都支持。截止到当前博客发布时间，ES标准逐步添加新特性

问题：开发用es6,线上浏览器用es5,不一致问题。vue的办法是是开发用es6之后用webpack打包为es5
TypeScript微软的标准，是js的超集，添加了可选的静态类型和基于类的面向对象编程，除了具备es特性还纳入了不在标准范围内的特性，是浏览器不直接支持typescript,要编译js后才能被浏览器执行。即TypeScript用来编程，编译后称为js，也用webpack打包。

2.4 JavaScript框架

jQuery:大家熟知的JavaScript框架，优点是简化了DOM操作，缺点是DOM操作太频繁，影响前端性能；在前端眼里使用它仅仅是为了兼容E6、7、8;
Angular:Google收购的前端框架，由一群Java程序员开发，其特点是将后台的MVC模式搬到了前端并增加了模块化开发的理念，与微软合作，采用TypeScript语法开发；对后台程序员友好，对前端程序员不太友好；最大的缺点是版本迭代不合理（如：1代->2代，除了名字，基本就是两个东西；
React:Facebook出品，一款高性能的JS前端框架；特点是提出了新概念【虚拟DOM】用于减少真实DOM操作，在内存中模拟DOM操作（缓存着一些dom元素），有效的提升了前端渲染效率；缺点是使用复杂，因为需要额外学习一门【JS】语言；
vue：一款渐进式JavaScript框架，所谓渐进式就是逐步实现新特性的意思，如实现模块化开发、路由、状态管理等新特性。其特点是综合了Angular(模块化)和React(虚拟DOM)的优点；
Axios:前端通信框架；做ajax.因为Vue的边界很明确，就是为了处理DOM,所以并不具备通信能力，此时就需要额外使用一个通信框架与服务器交互；当然也可以直接选择使用jQuery提供的AJAX通信功能：

2.5 前端UI框架

Ant-Design:阿里巴巴出品，基于React的Ul框架
ElementUl iview、ice:饿了么出品，基于Vue的UI框架
Bootstrap:Twitter推出的一个用于前端开发的开源工具包
AmazeUl:又叫“妹子ui”，一款HTML5跨屏前端框架

2.6 JavaScript构建工具

Babel:JS编译工具，主要用于浏览器不支持的ES新特性，比如用于编译TypeScript个
WebPack:模块打包器，主要作用是打包、压缩、合并及按序加载

2.7 三端统一（bybrid app）

bybrid app混合开发：实现三端统一。pc,android:apk，ios：ipa能够调佣设备底层硬件。打包方式
云打包：HBuild->HBuild。Dcloud出版：api Cloud
本地打包：Cordova(前身PhoneGap)

2.8 前端需要了解的后端技术nodejs（笨重）

nodejs（前端服务器）需要框架和项目管理工具，是一种后台技术，需要框架和项目管理工具，NodeJS框架及项目管理工具如下：
Express:nodejs框架
Koa:Express简化版
NPM：项目综合管理工具，类似于Maven下载包
YARN:NPM的替代方案，类似Maven和Gradle关系

nodejs:前端可以通过nodejs前端服务器，做一些模拟测试，让nodejs返回数据，使前端开发对后端的依赖减小，后端给nodejs通信（留接口）即可。

2.9 基于AJAX带来的SPA时代

2005年A]Ax(Asynchronous JavaScript And XML,异步JavaScript和XML)被正式提出并开始使用cdn作为静态资源存储，在这之前JS都是用来在网页上的SPA(Single Page Application)单页面应用时代。

优点:
- 这种模式下，前后端的分工非常清晰，前后端的关键协作点是AjAX接口。看起来是如此美妙，但可过头来看看的话，这与JSP时代区别不大。复杂度从服务端的JSP里移到了浏览器的JavaScript,测览器端变得很复杂。类似Spring MVC,这个时代开始出现浏览器端的分层架构：

缺点:
- 前后端接口的约定：如果后端的接口不成熟或者后端的业务模型不够稳定，那么前端开发会很痛苦；不少团队也有类似尝试，通过接口规则、接口平台等方式来做。有了和后端一起沉淀的接口规则，还可以用来模拟数据，使得前后端可以在约定接口后实现高效并行开发。
- 前端开发的复杂度控制：SPA应用大多以功能交互型为主，JavaScript代码过十万行很正常。大量JS代码的组织，与View层的绑定等，都不是容易的事情。

2.10 前端为主的mv*时代

优点:

MVC是一个非常好的协作模式，能够有效降低代码的耦合度，从架构上能够让开发者明白代码应该写在哪里。为了让View更纯粹，还可以使Thymeleaf、Freemarker等模板引擎，使模板里无法写入Java代码，让前后端分工更加清晰。

缺点

前端开发重度依赖开发环境，开发效率低，这种架构下，前后端协作有两种模式：

第一种是前端写DEMO,写好后，让后端去套模板。好处是DEMO可以本地开发，很高效。不足是还需要后端套模板，有可能套错，套完后还需要前端确定，来回沟通调整的成本比较大

另一种协作模式是前端负责浏览器端的所有开发和服务器端的Vⅵw层模板开发。好处是UI相关的代码都是前端去写就好，后端不用太关注，不足就是前端开发重度绑定后端环境，环境成为影响前端开发效率的重要因素。

前后端职责纠缠不清：模板引擎功能强大，依旧何以通过拿到的上下文变量来实现各种业务逻辑。这样，只要前端弱势一点，往往就会被后端要求在模板层写出不少业务代码。还有一个很大的灰色地带是Controller,页面路由等功能本应该是前端最关注的，但却是由后端来实现。Contro11er本身与Mode1往往也会纠缠不清，看了让人咬牙的业务代码经常会出现在Contro11er层。这些问题不能全归结于程序员的素养，否则JSP就够了。

对前端发挥的局限性：性能优化如果只在前端做空间非常有限，于是我们经常需要后端合作，但由于后端框架限制，我们很难使用【Comet】、【BigPipe】等技术方案来优化性能。

mcv(同步通信)-阻塞
mvp(异步通信):Presenter-非阻塞
mvvm(异步通信)-非阻塞

为了降低前端开发复杂度，涌现了大量的前端框架
比如：
Angular]S
React
Vue.js
EmberJS等，这些框架总的原则是先按类型分层，比如Templates、ControllersModels,然后再在层内做切分，如下图：

优点

前后端职责很清晰：前端工作在浏览器端，后端工作在服务端。清晰的分工，可以让开发并行，测试数据的模拟不难，前端可以本地开发。后端则可以专注于业务逻辑的处理，输出RESTfu等接口。

前端开发的复杂度可控：前端代码很重，但合理的分层，让前端代码能各司其职。简单如模板特性的选择，就有很多很多讲究。并非越强大越好，限制什么，留下哪些自由，代码应该如何组织。

部署相对独立：可以快速改进产品体验

缺点：

代码不能复用。比如后端依旧需要对数据做各种校验，校验逻辑无法复用浏览器端的代码。如果可
以复用，那么后端的数据校验可以相对简单化。

全异步，对seo不利。还需要服务端做同步渲染的降级方案

性能不是最佳，对于移动互联网环境

spa不能满足需要。存在大量页面应用。url design需要后端配合，前端无法完全掌控给你

前端为主的MV*模式解决了很多很多问题，但如上所述，依旧存在不少不足之处。随着NodeS的兴起，JavaScript开始有能力运行在服务端。这意味着可以有一种新的研发模式：
在这种研发模式下，前后端的职责很清晰。对前端来说，两个Ul层各司其职：

Front-end Ul layer处理浏览器层的展现逻辑。通过CSS渲染样式，通过JavaScript添加交互
功能，HTML的生成也可以放在这层，具体看应用场景。

Back-endUl layer处理路由、模板、数据获取、Cookie等。通过路由，前端终于可以自主把控
URL Design,这样无论是单页面应用还是多页面应用，前端都可以自由调控。后端也终于可以摆
脱对展现的强关注，转而可以专心于业务逻辑层的开发。

通过Node,web Server层也是JavaScript代码，这意味着部分代码可前后复用，需要SEO的场景可以在服务端同步渲染，由于异步请求太多导致的性能问题也可以通过服务端来缓解。前一种模式的不足，通过这种模式几乎都能完美解决掉。
与JSP模式相比，全栈模式看来是一种回归，也的确是一种向原始开发模式的回归，不过是一种螺旋上升式的回归。
基于NodeJS的全栈模式，依旧面临很多挑战：
- 需要前端对服务端编程有更进一步的认识。比如TCP小P等网络知识的掌握。
- NodeJS层与Java层的高效通信。NodeJS模式下，都在服务器端，RESTful HTTP通信未必高效，通过SOAP等方式通信更高效。一切需要在验证中前行。
- 对部署、运维层面的熟练了解，需要更多知识点和实操经验。
- 大量历史遗留问题如何过渡。这可能是最大最大的阻力。