# 开场白
从两个问题开始：
（1）我相信很多人都听过 脚本（script） 这个词，在场有哪位愿意解释一下脚本的定义是什么没？
在百度百科上是这么解释的:
脚本（
script）是一种批处理文件的延伸，一段纯文本保存的程序，由一条条文字命令集合而成
通俗的说，脚本就是为了完成某个功能动作而编写的某一些命令语句的集合，这个功能一般都比较简单，比较单一。当这个功能越来越复杂，越来越庞大的时候，我们更趋向于把这些命令集合称作一段程序，一个系统，而不是一个脚本。
（2）script是脚本的意思，JavaScript是Java脚本吗？JavaScript和Java是什么关系？
有没有前端小伙伴知道答案？我们埋个伏笔。
# 分享目的
本文内容部分来自网络，不涉及太多技术，专注讲前端故事，所有人都能听得懂，希望
- 对非软件开发小伙伴，能对前端有一个初步印象，知道前端是什么
- 对非前端小伙伴，能了解前端的现状是怎么样的，与前端合作的时候，怎么去更好的分工
- 对前端小伙伴，能更关注一些技术的背后文化，对前端技术更加感兴趣，如有意愿自己去了解它就更好了
前端是什么
秉着知其所以然的态度，去google一些，结果并没有什么解释，从常识讲，相信大多数后端小伙伴都会说，前端就是HTML + CSS + JavaScript，用来写静态页的，这可能是早期的观念，对于现在的前端格局，可能就不太够用了。
说的笼统一些，前端其实是一门用来实现页面效果展示及用户交互的运行在浏览器环境上的编程技术。以前的前端，在现在看来称为模板页面显得更加贴切。即模板工程师开发完成模板页面后，服务端工程师通过嵌套引入并修改页面上变量来完成页面渲染与展示，而现在的前端，除了原有功能外，还涉及了路由，模块，交互，SEO，状态管理，异步，打包编译，及各样工程化的框架等等。
是不是感觉还是不懂？没关系，往下看
# 前端的成长历程
正如你所知，互联网本身就是一个比较年轻的行业，而前端，从真正被认可到现在，其实也就是近十年的时间。作为前端最为关键的一门技术：JavaScript，演变过程最为让人惊叹
前端发展历程
1. JS诞生 - 浏览器之战（1995年）
浏览器战争大致可以分为3场，分别是：
| 网景浏览器 | PK | IE浏览器 |
|---|---|---|
| IE浏览器 | PK | Firefox浏览器 |
| IE浏览器 | PK | Chrome浏览器 |
自互联网诞生以来，人们对Web的需求日益强烈，那个时候，大多数因特网用户都使用速度仅为28.8kbit/s的“猫”（调制解调器）上网，但网页复杂性和大小不断增加，为了完成一个简单的表单验证频繁的想服务器交换数据，是对用户等待的耐心极大的挑战。于是当时最为盛行的NetScape Navigator（网景公司）决定开发一种客户端语言，用来处理这种简单的验证问题。在职的布兰登·艾奇（Brendan Eich）开始计划于1995年2月发布的网景浏览器2中加入一种名为LiveScript的脚本语言。当时参与开发的还有sun公司。在网景2正式发布前夕，为了搭上媒体热炒的Java的顺风车，于是临时把LiveScript改名为JavaScript，JavaScript由此而生。这个极其乌龙的名字，就是来的这么随意~
由于JavaScript1.0获得了极大的成功，NetScape随即在网景中又发布了JavaScript1.1，关注度一度升高的网景招来了微软的眼红，决定对当时自己的产品IE投入更多的资源，于是第一场大战拉开了序幕。微软投入了近两千人的团队资源，去PK当时已在门槛内的投入几十人资源的网景，当时技术保护并不强，微软的反编译及研发力度大，在网景浏览器3发布不久后，微软在IE3中发布了JScript（当时两个版本的JS），但因为过于着急Bug无数。为了避开IE浏览器上的使用，开发者们又研发出了一个有用的新技术：浏览器嗅探技术，即Navigation.UserAgent，也就是所谓的UA，用于识别当前用户运行在什么样的操作系统及浏览器之下。比较搞笑的是，IE又不要脸的研发了UA伪装，继续逼迫用户使用~，最终IE获胜，网景被美国在线（AOL）收购，网景的失败主要是因为没有遵循当时的ECMAScript规范而被开发者们所摒弃。IE等市场份额峰值达96%之高。
第二场大战主要对手是IE与火狐，同时也有许多不同引擎的其他浏览器，出现市场格局分裂，各占一部分江山。火狐大家都知道，但可能不知道他们的开发者，其实就是被AOL收购的网景那批人，它们在被收购之前创建了Mozilla社区。IE作为当时的独裁者并不遵循W3C标准，造成了当时存在一个理论标准和一个事实标准的格局，也就造成了开发者需要各种hack技术才能兼容好自己的应用的难题。2004年火狐首次发布，由遵循W3C的FF和Opera为首的阵营对IE产生了巨大冲击，蚕食 市场至25%，IE跌至65%以下，由于不同标准，也催生了许多前端框架，其中JQuery凭借强大的选择器技术几乎成为所有网站的标配。
第三次大战是新一轮的竞争，2008年，谷歌以新颖友好的设计交互，高性能，高速度访问效率冲破阻碍刮占大量市场份额，已经受到质疑和被兼容问题饱受折磨的开发者们再一次感受到如沐浴春风的开发感受，有好的视图交互也被广大吃螃蟹的网民所喜爱而推崇。目前为止，谷歌占领超6层市场，微软最终服输谷歌，选择了chrome内核和开源引擎chromium重建了Edge，而拥有良好过往但已成为弃儿的IE依旧占市场份额近12%始终高于Edge近一倍让微软久久骑虎难下，浏览器大战落下帷幕。
自此以后，谷歌领航浏览器市场，奉劝各位依据，谷歌很好用，来用谷歌吧~~
2. 婴儿阶段 - 前端模板（1995 - <2005）
Web刚兴起时，前端还离不开后端，这时候并不叫前端工程师，而是模板工程师，许多HTML开发者也并不是专业的程序员，而是一些美工，他们负责编写页面模板，后端工程师们负责读取模板，替换出变量，渲染生产最终用户界面。这个阶段广大互联网从业者谁也不敢相信，有一天会有一批人，以HTML+CSS+Javascript当做谋生手段。在那个时候，前端工程师（模板工程师）有一个别的称呼，叫：美工页面仔。
1995年后，PHP问世，后端主导的Web应用程序开始诞生，随后，以火热的Java为服务端的JSP被研发，ASP也出现了，动态网页开始广泛的进入人们的视野。此时所谓的前端代码在项目中也只不过是后端的一部分，是盛行的MVC框架中的View(视图)层。MVC的框架模式，也决定了这必将是个重后端，轻前端的势态。
3. 少年阶段 - Ajax出现（2004） - 第一次爆炸
之前阶段，用户界面如果想要获取后台数据，就要刷新整个页面，造成页面频频刷新，用户看到页面就一直在闪动。
2004年，Ajax技术诞生，随后谷歌公司在2004年和2005年先后发布了 Gmail 和 Google Map 这两款应用，由于Ajax的异步特性，无需等待后台请求回来即可提前渲染页面，不需要刷新就可以使得前台与服务端进行网络通讯，无数开发者和用户为此欢呼。
2005年2月杰西发布了《Ajax：一种Web应用程序开发的新方法》，Ajax开始进入广大开发者视野，Ajax盛行，越来越多的项目使用Ajax动态获取数据。
前后端的格局模式，从模板页面读取替换出变量的模式，逐渐过渡到前端开发页面，通过Ajax与后端接口交互获取数据的模式，这个剧变，人们开始意识到前端的重要性，JS开始不仅仅是一种“玩具性，脚本性”的技术，前端开始变得复杂，前端工程师也因此正式申请了“身份证”，摆脱了“美工页面仔”身份，逐渐有人成为了专业的前端工程师。
4. 青年阶段 - Node.js出现（2009） - 第二次爆炸
其实在1994年的时候，网景公司第一次提出LiveScript（后来更名为JavaScript）时，还提出了另一个技术：LiveWire，它是最早的服务端JavaScript，但因为Java，PHP，.net等的服务端技术风靡，LivaWire逐渐式微。
2008年同样由Chrome发布的JavaScript引擎V8执行的高效性引起了Ryan Dahl（瑞安·达尔）注意，Ryan利用V8引擎打造了基于事件循环的异步I/O框架，也就是 Node.js
2010年1月，NPM 作为Node.js的包管理系统首次发布，模块化规范及技术也开始盛行，借助NPM使用CommonJs规范开发的包使得一处编写处处调用的成为了可能，同时也能提供给其他人使用，目前我司大前端也有相应的产品输出。
Node.js的出现吸引了很多前端开发人员开始用JS开发服务端代码，JavaScript从此从前端渗入后端，创造了在服务端的无限可能，填补了LiveWire没有完成的遗憾，它正式的将JavaScript推向了全栈技术的道路。让前端开发者，无需学习那些对于前端来说很奇怪的后端技术也能成为全栈开发的可能。
从理论上来说，Node.js应该能解决所有其他后端语言能做的事情，但往往不希望这么做，前端开发者们更希望用它来解决服务端UI层的问题，如用户输入信息加密解密等，而对于数据存储，业务数据治理还是由更为专业的后端同学统一管理更为安全和高效。
NodeJs的推动，使得JavaScript的地位水涨船高，开始真正的分流技术市场，开始变得炙手可热，甚至一度挑战已经风靡十几年的Java的地位，布兰登·艾奇当时更名LiveScript的时候，怎么也没想到，这个为了蹭一下Java热度的JavaScript，居然开始较劲和撼动Java的地位。
5. 壮年阶段 - 架构、工程化及SPA
Node.Js出现后，NPM包管理器的成员也急速扩大。同时冒出的海量的模块，路由，状态管理，数据库，后端MVC框架都有了。技术之间总是相互刺激相互借鉴相互扶持。前端有了生成视图的能力，读写数据的能力，处理数据的能力后，缺乏一种更好的组织代码的能力，业界高手们当然也深知到了这一点。
在现代主流框架之前，JQuery几乎是统领了JS框架界，但随着Web快速发展，以及用户越来越挑剔，JQuery的事件驱动已经不能满足追求极致与高性能的用户口味，更新颖的架构模式渴望被研发。
于此同时前端另一条线的HTML5也在业界引起轩然大波，相比原生Android和IOS，H5（Web App）的优势也逐渐凸显，以前在 C/S 中实现的桌面软件功能组件迁移到了前端，之前只在后端有的 MV* 框架在前端也逐渐被使用起来。以Backbone为首的第一批火起来的框架，就是使用的纯正的MVC模型，同期谷歌的Angular先后架构了MVC和MVVM两种架构模式，微软的Knockout（KO），苹果的Ember则使用的MVVM模式。于2014年7月，尤雨溪的Vue框架问世，这套用于构建用户界面的渐进式框架，由于入手简单，数据驱动的高效性，完整的生态系统及支持各种类库而深受人们喜爱，当然我司现在绝大多数的前端项目也均使用的Vue来搭建
各类框架发布时间及受喜爱程度
这些大公司介入框架的研发，一下子使得杂乱的前端技术变得稳定下来，毕竟大家都迷信大公司。但使用框架也有个问题，并不是谁都会从0到1搭建框架架构。因此，为了让开发者们快速入手框架开发，提供一个构建工具已迫在眉睫。他们将后端的开发经验挪用过来，用Node.js开发了一套CLI（简称脚手架），里面包含了脚手架生成，打包脚本，语法风格检测，环境变量插入，代码复杂度检测，代码提交时自动跑单元测试，图片与JS压缩等功能。ESLint，JSLint，JSHint、CSSLint、HTMLLint等就是这时候出现的。
CLI的出现，极大的节约了开发者们了解框架的入手难度，也加速了前后端分离的进程，于此同时带动了上百种 工程化 构建工具的出现，其中就有最终胜出留下的广为人知的Grunt、Gulp、Webpack等。单页面应用（SPA）技术也在同期被挖掘出来，单页面应用通过路由功能推动了按需加载的完美实现，用户查阅网站的哪个页面，前端就加载哪个页面，用户使用那些功能，就加载哪些功能，将带宽资源消耗降低到最低。
CLI和工程化把前端项目从一个个HTML页面转而变成一个工程化的整体的项目，把DIV+CSS的编写模式变成模板化渲染，把优秀的模块包通过模块化标准导入到项目中直接使用，把前端三技术构建成一个整体，同时完成项目编译打包压缩等防盗功能，语法检测等项目增值功能。前端步入Web应用的阶段
至此，前端的定位已经不再是一个页面模板，而是一个视图与数据完整的，工程化且具有设计性的，自身独立的项目，无需依附于后端项目而存在。正因为这些特性，越来越多的开发者愿意将前后端项目分离，各司其职，各咎其责。
6. 大前端
组件化与付永华，前端与原生更加统一和谐...
# 前后端分离下，如何合作
1. 各司其职
前后端的交互，是基于HTTP+JSON的形式，后端专注于提供数据，更重要的是维护系统架构的稳定，保证数据的安全。前端人员专注于交互，快速响应用户需求及UI的变化。
2. 前后端分离的意义
（1）彻底解放前端，不再依附于后端存在
（2）提高工作效率，明确分工，基于对接口负责的原则，各方更能做好自己熟悉的领域，保证系统架构稳定，系统数据安全及良好的用户体验。
（3）并行任务，缩短项目开发周期同时，增强前后端预期效果。
（4）性能提升。通过前端路由配置，实现页面按需加载，减少首屏资源，提升交互体验
（5）产品中台化，前端产品组件化。后端实现一套服务，前端便可迅速进行二次开发推出新产品，提高产品可扩展能力和可维护能力，也促进往大前端模式发展
3. 前后端分离如何合作
（1）评审阶段：产品评审时：产品经理与前后端进行需求评审核对，各自理解清楚自己的业务量以及联调的工作量，评估开发时间。测试用例评审时：产品，测试及开发针对需求再一次核对是否理解一致，避免错误工作及推翻重做。
（2）准备阶段：前后端核对需求中需要联调的部分，前端提出接口理解，与后端进行接口设计的口头确认
（3）接口定义阶段：后端根据准备阶段汇总设计出详细的接口及数据格式，并编写出接口文档，双方根据文档讨论是否合理，确认文档后，模拟mock数据样例。
（4）开发阶段：双方并行开发，如过程中遇到需要新增或调整的字段或接口，短沟通重复步骤3。
（5）联调阶段：双方工作完成，前端接入真实数据，查看页面效果。如有疑问重复步骤3知道联调完成。
（6）提测阶段：项目提测，测试人员根据测试问题的特性，将Bug反馈给响应的某一方，如不确认，随便找一方让其帮忙确认，直至没有Bug
（7）UAT及发布阶段：前后端均不参与UAT与发布环境，如遇到问题，在测试环境复现问题并排查解决，重复步骤6，直到问题解决，再次由QA或运维升级至UAT。
网友评论