看电商发展过程中，前端技术的演进

一、何为电商
所谓电商，即电子商务，就是指通过使用电子类工具，围绕着商品交易进行的一系列活动。既然是交易，那就离不开交易的三个过程。
交易的第一个过程，就是商品信息的交换，卖方通过一定的渠道让商品信息扩散出去，而买方也通过一些方式能够获取到这些商品信息。无论是集市上的吆喝，还是店铺门口的广告，亦或是当今电商网站的网址，做的事本质上都是一样的，就是传达交易的信息。
交易的第二个过程，就是协议的达成，这个阶段里买卖双方通过谈判来确定商品的质量、数量和价钱，当然最核心的内容也还是价钱。这个过程在传统的交易过程中有可能会占用一些时间用来讨价还价，但是放在电子商务里，这个过程一般都比较短暂，甚至由于明码标价，这个过程都可以省略。
交易的最后一个过程，就是我们交易达成的阶段，我们经过上一阶段的协商，如果能够达成一个双方都认同的结果，那么接下来就是要进行交换了，这里大部分是以钱异物，当然也不排除有以物易物的可能。
我们这篇文章，就是要借着电商的发展过程中，结合交易的三部曲，来聊一聊相应前端技术都有了哪些发展。

二、互联网出现以前
电商的出现会比互联网来的更早，那个年代虽然已经有了计算机，但对交易过程有更大帮助的却是出现比较早的电话、传真等电子工具。电子商务这个事最最核心的东西就是信息的交换，在没有互联网的年代，计算机还没有传达信息的能力，只能用做计算和存储数据的介质。
这个年代的电子商务是很有限制的，第一个限制来自于通信的成本，当时电话和传真都很少民用，费用也比较高，所以电子商务绝大部分是以公对公的形式存在。而第二个限制来自于通信的方式，无论电话还是传真所做的数据通信都是1对1的，这也就意味着如果你想达成交易，那么就要先找到交易对手，当时的电子设备并不能对寻找交易伙伴有太大的帮助。
在这个没有互联网的时代，web和浏览器都还没出现，web前端也就更不会有了。

三、刀耕火种的年代
1994年中国被批准加入互联网，经过一年多的研究测试阶段，在1995年，中国的互联网终于走向了民间，这个互联网发展中的里程碑，也可以算作是电商发展中一个关键的时间节点。随着互联网出现的还有电子邮件和浏览器，这两种工具的配合，使得电子商务变得成本更低，效果更好。同时也因为互联网的民用，电子商务的市场获得了一次爆炸性的增长。当然这个时候的爆炸可能也就是从100人的规模增长到1万人规模的样子，和现在的电商市场规模还是没法比的。
这个年代最重要的事件是浏览器的出现，也标志着web开始发展。在电子商务发展的前期，web技术也只是停留在信息的展示上。更多的公司的网站，也只是用来作为商品信息的载体，然后在网站上放上联系方式，线下完成交易。这种初级的电商能够支持商品交易的第一个过程，也就是商品信息的交换，但最终不能在线完成整个交易过程。无法达成全程电子商务的原因有两个，一个是业务上的原因，当时的在线交易里存在陌生人间交易的信任问题，是先交钱还是先发货，是一个很容易进入死循环的话题；第二是技术问题，当时的互联网技术有限，通过ASP、JSP这类模板语言加上简单的javascript来做一套完整的交易网站，难度还是比较大的。
这个时代里，也没有所谓的前端分支，页面里简单的js语言也就是用来做一下表单验证之类的最简单的事情，当时的开发人员也就随手写上了。

四、全程电子商务时代
在全程电子商务时代之前，因为信息的传达已经没有问题，当时的物流也发展了很多年，所以想要完成电子商务的整个流程，最大的困难就是我们上一章提到的交易的信用问题。
2003年，阿里巴巴公司发布了一款可以算是电商发展过程中里程碑般的产品——支付宝。这个产品最大的意义就是解决了陌生人间交易的信用问题，支付宝通过把买家付款和卖家收款这两个事拆分开来，在中间做了一层代理。买家先把钱支付给支付宝，然后卖家发货，当货物抵达买家。在这个交易模型下，用户仅需要信任支付宝就可以完成交易，当然这个信任也不是一下就建立起来的，总会有人担心，我把钱给了支付宝，他们拿钱跑了怎么办。但经过一部分敢于信任的人的尝试，这个顾虑一点点消失，用户对支付宝的信任感也一点点增强。信任问题解决以后，整个电商流程就变得顺畅了，这样电子商务就进入了全程电子商务时代，这个时代一直持续到现在。
而随着交易流程的打通，从技术角度来说，电商系统的需求就变得复杂了，纯靠当时像ASP、JSP这些模板语言写一个交易网站，程序猿们还是很痛苦的。于是，从这个时候开始，在业务的压迫下，技术也开始进入一个高速发展期。而我们前端的技术分支也开始了从无到有，再到丰富的过程。
当然，我们心里也要有一个概念，那就是技术是工具，它始终要为业务服务的。每一种技术能够发展成熟，肯定是它在业务的某个发展时期解决了一些比较重要的问题，这才能让这种技术得到认可和普及。全程电子商务时代才是前端这个技术分支发展的主要时期，下来我们聊一下这些年电商发展过程中遇到了什么问题？伴随着这些问题的解决，前端技术又都发生了什么样的变化？

4.1 Ajax的应用
最先要说的就是Ajax的出现，在其出现的时期，这个东西绝对是web开发的一大福音。举个例子，设想一下如果没有异步通信的时候，我们填写了一个有20个输入框的表单，又一个个检查了一遍以后，终于有勇气点了一下提交按钮。但是！这时候返回的是一个错误页面，“对不起，您的名字已存在！”。这样我们就又要去重新填那20个字段了，我们还要祈祷着第二次就都能填正确。但是ajax出现后，这就大不一样了，我们可以随时在当前页面和后端做一个验证，来保证只要不是后端出了问题，我们提交过去的值都是合法的。
Ajax这个名称是2005年才有的，在这之前各家浏览器厂商就已经各自用自己的方式实现了异步通讯的机制，这也就有了另外一个问题，兼容性！每个浏览器对Ajax的实现都不一样，但每一个浏览器都有一定的市场份额，这就有点难为程序猿了，尤其当时只把js当做简单的脚本语言的开发人员来说，一下子多了这么多的浏览器要去兼容，简直是灾难！这个问题的解决是从两方面来进行的，第一个是在2006年，W3C终于将Ajax纳入其标准，这就意味着以后的浏览器都要按着统一的方法来实现Ajax。但标准归标准，等标准全部实现还是需要时间的，为了解决当下的问题，就有人或组织封装了一些兼容各种Ajax实现的类库。其中最为有名的就是jQuery，它除了Ajax外，还抹平了其他例如Dom操作等方法的兼容性问题，一度成为最流行的前端类库。

4.2 前后端的划分和分离
Ajax的出现，也带来了另外一个问题，那就是有了Ajax以后，之前用模板语言实现起来的功能变得简单，之前模板语言实现不了的功能现在也能实现了。这样就造成越来越多的逻辑转移到了javascript上，使其变得越来越复杂。
随着js复杂度的增长，原来的开发模式出现了问题，一个程序猿搞定全站变得越来越不靠谱，因此在这个时候就把网站开发这个职位划分成了前端和后端两个职位。但是只划分了前后端的职责范围还是远远不够的，我们在原来的开发模式下，前后端的代码也在一起的。现在既然已经分为前后端两波人在开发了，维护同一套代码就变得不那么方便。项目越复杂，出现你等我，我等你的情况就会越来越多，这样就拖慢了整体团队的节奏。所以为了团队的效率，前后端的代码也要做分离。
前后端的分离方式分为部分分离和全部分离两种，部分分离是只把脚本和样式分离出去，而html模板还留在后端通过jsp，velocity或者freemarker来渲染；另一种就是完全分离，脚本样式以及模板全都放在前端来维护。
部分分离已经很大程度上解决了前后端开发时的协调问题，开发效率也得到了很大程度的提升。但也得承认，这种方式也还是有问题的。当我们要开发html模板的时候，就需要搭起一整套后端的开发环境，或者是找后端同学来协助。
而完全分离一般有两种方案，第一种就是使用velocity这种在nodejs和java下都可以编译的页面模板，在开发时放到前端项目里，但在发布时，会把模板发布到后端的模板目录下，这样，开发时就做到了完全分离。这种方式最大的好处就是线上模板的渲染还是由java来做的，形成的是带有动态数据的html，比较有利于SEO。但这种方式下，前端的开发环境和发布系统的复杂度都相对较高，单纯的前端改动也还是要带着后端一起发布。
第二种完全分离的方式，就是把纯静态的html模板完全放在前端，数据全部通过RESTful接口来进行交互。这样前后端就完全分开了，脱离了后端的模板，而这种方式的系统复杂度也会比第一种完全分离的方式低。但这种方案下，所有的页面数据都是用js渲染的，没有动态模板，不太利于SEO。这个不足我们可以通过做server render或者给蜘蛛做一套定制页面来解决。

4.3 分层架构的出现
随着业务进一步的复杂，我们又开始考虑怎么让一个复杂系统变得可维护，这时候就体现出一个网站架构的作用了。因为后端比前端发展的要早，分层架构这个概念在后端的发展过程中就已经有了，我们最常见的就是MVC结构。这个时候前端也发展到一定的程度上了，也是需要分层架构来让代码变得更加可维护。
分层设计最大的意义就是解耦，如果我们的系统中的各层之间是松散耦合的，当我们要改变其中一个层级的时候，只要保证该层级的接口不变即可，里面的实现方式可以随意变动。其他经常提到的优点，比如易维护、易复用、易扩展，其实说的也都是一个意思。在前端的分层方式上，和后端并不太一样，所以后端的MVC模式并不能完全搬到前端来。前端的分层设计在MVC的基础上又做了进一步的演进，形成了更适合前端的MVV*等方式的分层，来支持前端的逻辑。

4.4 模块化来了
分层架构有一定的解耦效果，但是遇到复杂业务，所有的逻辑就分成三大块显然也是不够的，并且基于javascript语言的特性，如果我们没有对全局变量做管理，变量冲突也是无法避免的。因此我们就有了模块化的处理方案。
由于前端的发展一直处于百花齐放，百家争鸣的状态， 所以在每一种技术或者方案的发展过程中基本都会出现几个分支。我们的模块化方案也未能免俗。模块化中比较有代表性的就是AMD、CMD、CommonJS和es6模块化这几种方案。
AMD 是 RequireJS 在推广过程中的规范化产出，而CMD 是 SeaJS 在推广过程中的规范化产出，这两个模块化方案有些相似，主要的区别是加载和运行的时机不太一样。这两种模块化方案是可以直接在浏览器上运行的，但也有个缺点，就是会将模块化的代码和业务代码掺杂在一起，对于强迫症的同学来说，这并不算一个很好的方案。
而随着nodejs的发展，我们有了对代码做编译的能力。这样原本不能在浏览器上运行的模块化方案，通过编译处理以后，也能正常在浏览器上跑了。这种模块化方案最具代表性的就是CommonJs的模块化方案。由于我们是要编译的，所以大部分处理模块化的代码都可以通过编译的过程追加进去，这样我们只用关心业务逻辑部分就可以了。当然这种方案也不是完美的，这种提前编译打包的方案会把所有引用的代码都打包进去，如果想按需加载就需要再做进一步的处理。总体来说，我还是比较倾向这种模块化方案。
在模块化方案中，还有一种被纳入标准的ES6模块化方案，理论上这种模块化方案也是可以直接运行在浏览器上的，但对浏览器的版本要求比较高。现在也有一种方案，就是通过babel编译，把ES6的语法转换成大部分浏览器可以兼容的旧版本js的语法。但这样的话，ES6的模块化相对CommonJs也就没有多大的优势了。

五、下一个时代
互联网行业的发展总是会受到技术的限制，有很多想做的事可能因为技术原因不能做。但另一方面，业务也总是在促进技术的发展，如果一个事的价值非常大，那么技术通常会进化到可以搞定它的状态。业务和技术的就是这样一个互相促进，阶梯式上升的过程。
电商的下一个时代会是什么样，应该没有人能说的清。但是能看到的像大规模数据的处理、机器学习、智能化推荐和VR展示这些技术已经在路上了，有的也已经有了不错的进展。而对于前端来说，将来也不排除会在这些领域承担下一些责任，尤其像VR这种用于展示的技术还是很有想象空间的。
无论下一个时代会是什么样，但愿我们始终保持一颗好奇心，能以兴趣驱动的方式跟上技术变革的潮流。
转载请注明出处，本文来自慕课网手记，原文地址：http://www.imooc.com/article/18294