传统架构 VS 现代前端框架

先回顾下前端的历史:

  1. 早起的页面都是非常简单的,页面主要是浏览内容为主,没有过多的交互,最多就有些表单的提交
  2. 后来随着ajax的出现,引来了web2.0时代我们在网页上可以做更多的,更复杂的操作了,这时候就出现了一些库(谈不上框架吧)如针对DOM操作和数据请求的jquery,还有就是面向数据处理的Underscore
  3. web产品随着业务需求的增加,导致代码量膨胀,在时间过程中也会发现许多痛点,所以我们不得不开始考虑“框架”的事情了

  4. 我在实践过程中发现传统架构的一些痛点

  5. 没用模板,手工创建大量的HTML标记,然后通过字符串拼接对性能来说是不太好的实践(template string 这种解决方案,但感觉还是好麻烦),代码会变得难以阅读,创建代码量很大的程序,你会发现这是一场灾难。动态class的定义,在实际使用场景中,页面的样式经常是要根据后台传来的数据来渲染(根据后端传来的值显示不同的class)的,若直接用在js代码里用 if else 的逻辑去拼接字符串,这又会是一场灾难。===》可以试着用handlebars.js类似的模板来解决====》所以jquery+template 成了比较初级的架构

  6. 没有组件化,比如说一个header块,每个页面都得共用,所以我也傻乎乎的在每个html界面都加header的html代码
  7. 通过事件驱动,用jquery写代码,编程的思路是很清晰:“通过响应事件,去调用一个函数,你可以在函数内去获取DOM元素,然后改变它(属性,样式)”。入门时候,觉得通过jquery去写个点击事件什么的,非常的方便,但业务需求变复杂了,你会发现功能的确能实现,但是你把很多时间都花在了写DOM操作上
  8. 以前经验不足的时候会定义一些类,然后会对这个类定义一些css(样式),同时又会对这个类定义些点击事件(javascript钩子)。===》元素的表现和功能耦合起来。后来随着页面业务渐渐变复杂,发现样式的class和定义绑定事件的class要做分离,不然维护起来很麻烦【eg. 定义一个class ,引用这个类用media query分别对桌面端和移动端定义了些类,又对这个class绑定的事件,这时候如果有一个需求是对移动端定制一个事件,问题就出现了,这个class不好删,因为删了就没样式了,又不好改事件,因为改了桌面端事件也变了。】 有人会说可以在DOM标签上定义事件用onclick之类的属性,但onlick上的function必须是全局变量,这样代码不能模块化(而且这也不符合w3c指定的web标准---结构(html),样式(css),行为(js) 分离)

  9. 我对框架的一些看法

​ 框架就是把一些重复的代码抽象出来,让我们可以集中精力去解决业务上的逻辑,而不是各种琐碎的细节。

最近体验了下Vue.js ,针对上面四点我发现这个框架都有相应的处理方案

  1. 数据绑定的句法配合使用条件渲染 v-if, template v-if ,v-show, 这类指令可以很快的把模板写出来,而且是html格式的,很容易阅读,逻辑清晰。
  2. 官方推荐的脚手架用vue-cli 搭建一个 webpack+ vue-loader,组件化使得整个网站逻辑很清晰,而且组件容易被复用。
  3. vue.js给我最大的体验是两种编程方式的不同:事件驱动 VS 数据驱动 。事件驱动让我觉得不舒服的地方,上面第三条已经说了,Vue提供了数据绑定功能,写好模板之后,我们就可以把经历都放在对数据的处理上,几乎不用写DOM操作,发现代码改起来效率比之前高很多。
  4. vue推荐的是在html标签上 ,用v-on 属性来进行事件绑定,这种方式看似违反了传统理念“separation of concern”。所有的vue.js事件都严格的绑定在当前的viewModel上,它不会导致全局函数的污染。 我感受到的好处是:1.省去了在js上绑定事件的代码,代码更加简洁. 2.使得class都是用于描述样式,v-on属性用来绑定事件,元素的表现和功能完全解耦

我觉得框架的终极目标: 代码复用,提高开发效率。代码模块化,提高可阅读行,维护方便。既然它现在能解决我的一些痛点,那我就拥抱它!

以下是我用vue.js+本地json文件(自己的朋友圈数据)做成的移动端网页

http://qiankaijie.com:8080/book.html#!/book