前端的近代历史,近代变更,这个话题就宛如古代后宫剧-一波三折
简述一下CSS,HTML和ES的历史吧
近代史
时间 | 事件 |
---|---|
1990 | HTML诞生, 随之出现第一个叫Mosaic 的浏览器 |
1994.7 | HTML 2.0 规范发布,网景公司成立,W3C成立 |
1995 | 网景设计出js,JavaScript诞生 |
1996 | css1.0出现,js的诞生后续引发了第一次浏览器大战 |
1997 | W3C推出了HTML3.2,ES1.0,HTML4.0 |
1998 | W3C推出了css2.0,ES2.0 |
1999 | 第一次浏览器大战结束,IE完胜,前端进入梦魇的时期,ES3.0,HTML4.01 |
2001 | CSS3.0 |
2004 | FireFox开启第二次浏览器大战 |
2008 | HTML5.0 |
2011 | ES5.0 |
2015 | ES6.0 |
2017 | 第二次浏览器大战结束,IE落败,FireFox站稳脚,Chrome胜利 |
动态技术
技术上,JavaScript 诞生之后,为了使得 Web 更加充满活力,不再仅限于对DOM样式的更改,以 PHP、JSP、ASP.NET 为代表的动态页面技术相继诞生,但是动态技术仍无法挽救前端的微弱地位。
AJAX
2005年AJAX技术诞生,这种异步相应局部的刷新立刻掀起一阵前端的狂潮,这种革命性的技术,颠覆了用户体验。随着 AJAX 的流行,前端慢慢走向欣欣向荣的局面。
Node.js
Chrome浏览器的V8引擎出现同时促就了基于事件循环的异步 I/O 框架–Node.js的诞生,前端也能写后端的东西,前端的生态系统得到了完善,同时NPM 作为 Node.js 的包管理系统首次发布。让模块化开发有了雏形,前端正式兴起,前后台开始分离
MV* 架构
随着HTML5的火爆,前端慢慢被重视,随之前端逻辑越来越复杂和难以维护,前端引进了后端的架构思想( MV* )
M | Model 数据层 |
---|---|
V | View 视图层 |
随之诞生了设计模式有MVC=>MVP=>MVVM
C | Controller 控制器,业务逻辑,互动:一种是通过 View 接受指令,一种通过Controller 接受指令。 |
---|---|
P | Presenter 提出者,互动:View 与 Model 不发生联系,都通过 Presenter 传递。 |
VM | ViewModel 视图模型,互动:双向绑定(data-binding):View的变动,自动反映在 ViewMod |
MVC
View 传送指令到 Controller
Controller 完成业务逻辑后,要求 Model 改变状态
Model 将新的数据发送到 View,用户得到反馈
优点:
把业务逻辑和展示逻辑分离,模块化程度高。且当应用逻辑需要变更的时候,不需要变更业务逻辑和展示逻辑,只需要Controller换成另外一个Controller就行了(Swappable Controller)。
观察者模式可以做到多视图同时更新。
缺点:
Controller测试困难。因为视图同步操作是由View自己执行,而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候,应用逻辑正确性是无法验证的:Model更新的时候,无法对View的更新操作进行断言。
View无法组件化。View是强依赖特定的Model的,如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的
MVP
各部分之间的通信,都是双向的。
View 与 Model 不发生联系,都通过 Presenter 传递。
View 非常薄,不部署任何业务逻辑,称为"被动视图"(Passive View),即没有任何主动性,而 Presenter非常厚,所有逻辑都部署在那里。
优点:
便于测试。Presenter对View是通过接口进行,在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象,这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中,单元测试的时候就可以完整的测试Presenter应用逻辑的正确性。这里根据上面的例子给出了Presenter的单元测试样例。
View可以进行组件化。在MVP当中,View不依赖Model。这样就可以让View从特定的业务场景中脱离出来,可以说View可以做到对业务完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做到高度可复用的View组件。
缺点:
Presenter中除了应用逻辑以外,还有大量的View->Model,Model->View的手动同步逻辑,造成Presenter比较笨重,维护起来会比较困难。
MVVM
基本和MVP一样,唯一的区别是,它采用双向绑定(data-binding):View的变动,自动反映在 ViewModel,反之亦然。Angular 和 Ember 都采用这种模式。
优点:
提高可维护性。解决了MVP大量的手动View和Model同步的问题,提供双向绑定机制。提高了代码的可维护性。
简化测试。因为同步逻辑是交由Binder做的,View跟着Model同时变更,所以只需要保证Model的正确性,View就正确。大大减少了对View同步更新的测试。
缺点:
过于简单的图形界面不适用,或说牛刀杀鸡。
对于大型的图形应用程序,视图状态较多,ViewModel的构建和维护的成本都会比较高。
数据绑定的声明是指令式地写在View的模版当中的,这些内容是没办法去打断点debug的。