关于jQuery和Vue两者技术架构的比较分析报告

发表于 | 分类于

关于jQuery和Vue两者技术架构的比较分析报告

jQuery

jQuery已经过时了。略做点补充：Zepto也是过时货了。还有Underscore/Lodash等，也是过时了。但是过时不代表你就一定不可以再用，或者要从现有项目中清除抛弃掉。项目维护和管理本身是另一回事情，并不是完全由技术因素决定的。看一下前两点，1. 新的DOM标准（借鉴jQuery）加入了许多新的方法，覆盖了绝大部分use cases；2. 目前主流浏览器的兼容性已经大幅提高，且因为都是Evergreen browsers了，所以以后也不太会出现严重的兼容性问题了；此外新标准比以往要更详尽清晰，出现不一致和bug的机率也小了；实际上这前两点也不是一蹴而就的，而是一直在改进。比如原生querySelector API普及之后，才出现了Zepto。只不过这两年发展加速，以至于Zepto还没取代jQuery，就要一起过时了。（贺师俊hax）

jQuery的核心价值

  1. 发扬光大了$和CSS选择器的天才idea（尽管都不是发明者）
  2. 处理浏览器的兼容性问题和各种bug
  3. 链式调用为核心的DSL（此为jQuery独创）
  4. 基于jQuery的生态（大量插件，各种工具如IDE也对其有良好支持）

jQuery的劣势

  1. 完整的jQuery体积太大。对于一些比较小的项目确实可以做到快速开发，但是现在的jQuery太臃肿了，有很多用不到的功能。所以现在有了很多精简jQuery的项目。另外就是全DOM操作，钩子往往会依赖标签，如果依赖jQuery来搭建页面的话（比如后台输出json，然后jQuery loop一个列表出来），维护上会有困难。如果一改页面结构，很多依赖标签的选择器，一改起来js那块就得跟着大改。还有就是jQuery的代码改起来不容易，如果真有项目特殊需求，要改一下jQuery代码来用就显得很麻烦。
  2. 不能向后兼容。每一个新版本不能兼容早期的版本。举例来说，有些新版本不再支持某些selector，新版jQuery却没有保留对它们的支持，而只是简单的将其移除。这可能会影响到开发者已经编写好的代码或插件。
  3. 对数据的处理有很多不便利的地方，容易导致高耦合度。

jQuery的适用场景

在过去的前端开发中，jQuery几乎会出现在任何大大小小的项目中，不论是类MS，还是电商，还是各类门户网站，都少不了jQuery的身影，可以说在之前的前端开发中，jQuery更是一种“标准”。

Vue

讲Vue之前就讲MVVM吧（Vue的架构模式就是MVVM）

引言

2008年，V8 引擎随 Chrome 浏览器横空出世，JavaScript 这门通用的 Web 脚本语言的执行效率得到质的提升。 V8 引擎的出现，注定是 JavaScript 发展史上一个光辉的里程碑。它的出现，让当时研究高性能服务器开发、长时间一筹莫展的 Ryan Dahl 有了新的、合适的选择，不久，在2009年的柏林的 JSConf 大会上，基于 JavaScript 的服务端项目 Node.js 正式对外发布。Node.js 的发布，不仅为开发者带来了一个高性能的服务器，还很大程度上推动了前端的工程化，带来了前端的大繁荣。与此同时，因为 JavaScript 执行效率的巨大提升，越来越多的业务逻辑开始在浏览器端实现，前端逻辑越来越重，前端架构随之提上日程。于是，我们谈论的主角，MVVM 模式，走进了 Web 前端的架构设计中。

概念

MVVM 模式，顾名思义即 Model-View-ViewModel 模式。它萌芽于2005年微软推出的基于 Windows 的用户界面框架 WPF ，前端最早的 MVVM 框架 knockout在2010年发布。当前最流行了MVVM 框架 Vue 的2.0版本在2016年5月发布。

一句话总结 Web 前端 MVVM：操作数据，就是操作视图，就是操作 DOM（所以无须操作 DOM ）。

无须操作 DOM ！借助 MVVM 框架，开发者只需完成包含 声明绑定 的视图模板，编写 ViewModel 中业务数据变更逻辑，View 层则完全实现了自动化。这将极大的降低前端应用的操作复杂度、极大提升应用的开发效率。MVVM 最标志性的特性就是 数据绑定 ，MVVM 的核心理念就是通过 声明式的数据绑定 来实现 View 层和其他层的分离。完全解耦 View 层这种理念，也使得 Web 前端的单元测试用例编写变得更容易。

MVVM，说到底还是一种分层架构。它的分层如下：

  • Model: 域模型，用于持久化
  • View: 作为视图模板存在
  • ViewModel: 作为视图的模型，为视图服务

Model 层

Model 层，对应数据层的域模型，它主要做域模型的同步。通过 Ajax/fetch 等 API 完成客户端和服务端业务 Model 的同步。在层间关系里，它主要用于抽象出 ViewModel 中视图的 Model。

View 层

View 层，作为视图模板存在，在 MVVM 里，整个 View 是一个动态模板。除了定义结构、布局外，它展示的是 ViewModel 层的数据和状态。View 层不负责处理状态，View 层做的是 数据绑定的声明、 指令的声明、 事件绑定的声明。

ViewModel 层

ViewModel 层把 View 需要的层数据暴露，并对 View 层的 数据绑定声明、 指令声明、 事件绑定声明 负责，也就是处理 View 层的具体业务逻辑。ViewModel 底层会做好绑定属性的监听。当 ViewModel 中数据变化，View 层会得到更新；而当 View 中声明了数据的双向绑定（通常是表单元素），框架也会监听 View 层（表单）值的变化。一旦值变化，View 层绑定的 ViewModel 中的数据也会得到自动更新。

前端 MVVM 图示

mvvm

如图所示，在前端 MVVM 框架中，往往没有清晰、独立的 Model 层。在实际业务开发中，我们通常按 Web Component 规范来组件化的开发应用，Model 层的域模型往往分散在在一个或几个 Component 的 ViewModel 层，而 ViewModel 层也会引入一些 View 层相关的中间状态，目的就是为了更好的为 View 层服务。

开发者在 View 层的视图模板中声明 数据绑定、 事件绑定 后，在 ViewModel 中进行业务逻辑的 数据 处理。事件触发后，ViewModel 中 数据 变更， View 层自动更新。因为 MVVM 框架的引入，开发者只需关注业务逻辑、完成数据抽象、聚焦数据，MVVM 的视图引擎会帮你搞定 View。因为数据驱动，一切变得更加简单。

MVVM框架的工作(优势)

不可置否，MVVM 框架极大的提升了应用的开发效率。It’s amazing！But，MVVM 框架到底做了什么？

  • 视图引擎

视图引擎：我是视图引擎，我为 View 层作为视图模板提供强力支持，开发者，你们不需要操作 DOM ，丢给我来做！

  • 数据存取器

数据存取器：我是数据存取器，我可以通过 Object.defineProperty() API 轻松定义，或通过自行封装存取函数的方式曲线完成。我的内部往往封装了 发布/订阅模式，以此来完成对数据的监听、数据变更时通知更新。我是 数据绑定 实现的基础。

  • 组件机制

组件机制：我是组件机制。有追求的开发者往往希望按照面向未来的组件标准 － Web Components 的方式开发，我是为了满足你的追求而生。MVVM 框架提供组件的定义、继承、生命周期、组件间通信机制，为开发者面向未来开发点亮明灯。

  • more…

劣势

MVVM架构型模式的兴起，实现了前后端真正的职责分离，在提高开发效率的同时，也存在一些不足之处。

  1. 比如说SEO：网站的前后分离架构越来越得到开发者们的喜爱与认可， 后端只提供数据接口、业务逻辑与持久化服务，而视图、控制与渲染则交给前端。 因此，越来越多的网站从后端渲染变成了前端渲染，而由此带来的直接问题就是各大搜索引擎爬虫对于前端渲染的页面（ 动态内容 ）还无法比较完善的爬取，这就导致了网站的内容无法被搜索引擎收录，直接影响网站流量与曝光度。但是，在如今的Vue中可以使用服务端渲染或者预渲染（SSR or Prerendering）来解决seo的问题，更有SSR开源框架Nuxt的支持。所以，MVVM是应时代产物，在逐步变得更加完善。
  2. 在兼容性方面，Vue由于数据操作API方法的选择的原因，所以并没有做到兼容IE8及其以下版本。

适用场景

可以说前后端分离随着趋势已经形成一种标准，MVVM设计模式的开发框架（Vue）适用任何场景的开发（低版本IE除外）。

总结

jQuery是直接来操作DOM的，凭借简化后的API直接和DOM对话（优异的兼容性）；
Vue是直接来操作数据的，拿数据说话。