zimo-article
zimo-article copied to clipboard
laizimo
:books:博客——源于实践，乐于分享，欢迎Star~
# 前言 > 富文本编辑器，是写文章的利器。对于一个网站来说，好的富文本编辑器更是锦上添花 > 本篇为移动端富文本实践篇的前言篇，文章主要介绍了现状，项目起因，以及接下来篇章的主要内容概要。如果你对这个话题，或者这个项目感兴趣，不妨先访问一下[github项目](https://github.com/nowandfurure/richeditor)。如果你看了之后，表示喜欢，那么，请动动你的小手点一下Star，表示对我们的支持。同时，如果你对项目的使用有任何疑问，或者建议，可以在issues里面给我们提出你宝贵的意见。我们也将不断丰富与完善整个项目，打造出一个优质的富文本项目。[github项目地址](https://github.com/nowandfurure/richeditor) # 正文 每个项目都有初衷，也同样会有目标。本来实践篇的文章都是上来就是干，直接丢代码。但是，本篇只分析一下，在项目初期的考量。只有清楚现有的项目中的不足，才能够优化它们的不足，打造出一款优质的项目。那么，我们首先要来清楚一下富文本编辑器的现状。 **现状概述：** 现在市面上，好的富文本编辑器都得数不胜数。强大如ueditor，功能齐全，被广泛运用；小如Pell，整体大小才不到1kb，风格单一，简约。但是这些富文本编辑器大多数是针对PC端的，移动端的却有点少，而且不精。项目不多的原因，就是移动端其实在这方面需求并不多，而且这一方面的产品少。唯一只有简书和知乎等产品上的富文本编辑器，小而精，风格统一，简约。尤其是，像简书的移动端富文本编辑器，体验良好，在图片等处理上面，下了很大的功夫。可是，由于是其公司产品，并未有开源的。现在移动端的流量逐渐增加，文章的产出不断增加，移动端的富文本编辑器需求也会不断增加。或许，某个晚上，你就会躺在床上，使用手机码字，写心得和感悟呢。 **项目初衷：** 在今年的五月份，我们一起接手了一个外包项目。其中，就需要使用到移动端的富文本编辑器，主要是让用户来描述自己的需求。可是，在github上面，真正移动端的富文本编辑器并没有太多，而且大多都没有图片处理的部分。自从那一次项目之后，我们粗涉富文本编辑器，里面的坑是一个接着一个。后来，我与我安卓的朋友萌生了一个自己开发一个类似于简书等优质的移动端富文本应用的想法。这个项目的目的是打造一个功能基本齐全的，可配置不同主题风格的富文本编辑器。 目前，整个项目已被放到github网站上面，版本属于v1.0版，后续还会进行不断的优化。[github项目地址](https://github.com/nowandfurure/richeditor) **内容概要：** 或许，真正做富文本开发的人员并不多，网上也并未找到比较详尽的开发方案等，大多数时候都是自己摸着石头过河。同时，也总结了一下自己在开发过程中的一些经验，下面的文章是接下来篇幅内容的一个概要： 1. [移动端富文本实践篇(一)](https://github.com/laizimo/zimo-article/issues/32)：富文本开发之前的一些基础知识普及，以及实践中的大致应用。 2. [移动端富文本实践篇(二)](https://github.com/laizimo/zimo-article/issues/42): 本篇的内容，主要是讲述一些dom元素的事件的监听情况，以及一些安全措施 3. [移动端富文本实践篇(三)](https://github.com/laizimo/zimo-article/issues/33)：本篇内容主要是讲一下文章中文字部分的处理，如'bold'、'italic'、'blockqueto'、'h1'等，以及分割行的插入和链接的插入和修改等模块的代码分析。 # 总结 本节并没有太多的干货，更多的是我们做项目的初衷。现在github社区上面，开源项目千千万万，我们更应该明确项目的目标与初衷，才能在一众项目中脱颖而出。相信，并且希望我们能够一同学习，一同进步。 > 最后，如果你对我写的有疑问，可以与我讨论。如果我写的有错误，欢迎指正。你喜欢我的博客，请给我关注Star~呦。大家一起总结一起进步。欢迎关注我的[github博客](https://github.com/laizimo/zimo-article)。同时也希望你关注我们的项目，[github项目地址](https://github.com/nowandfurure/richeditor)，谢谢支持
# 前言 临近2017的尾声，总是希望来盘点一下这一年中前端的发展。到目前为止，前端的井喷期也快临近尾声了。并不像几年前一样，总是会有层出不穷的新东西迸发出来。同时，前端技术也慢慢的趋于稳固，自成一套体系。 # 正文 我们何处说起？自然是离不开那三驾马车。 ## 三驾马车 自从2015年，react的问世，开始了三驾马车时代的先河。同时，jQuery也逐渐让出了其霸主的地位。后续的，angular开始了大型的改版，似乎想要追逐react的步伐。两种完全不同思路的体现，在前端开发的技术栈中发光发亮。同时，Vue就像一匹黑马一样，一路披荆斩棘，快速地进步着。 因此，从2017年开始，3架马车可以说是并驾齐驱。似乎需要看些对比数据，来表示它们目前的现状。(来自国外的数据)  可以看到react的深紫色是最多的，表示用户对于react还是十分满意的。虽然，早前的React收到了协议的影响，但是，这似乎并不影响它在开发者心目当中的地位。另外，react如此受欢迎的另一个重要原因就应该是React Native了吧。今年以来，React Native一直以两周一次的小版本更迭周期，迅速发展着。或许，2018年将会迎来最重大的正式版本1.0。(这个还是值得期待的。) 对于大多数开发者而言，学习了React的时候，对于它们学习React Native是有直接性质的帮助的，所以一般的国外开发者不会拒绝学习React这个框架的。 介绍完，React的情况，我们或许可以回望一下Angular的情况吧。 Angular可以说是一个最早问世的MVVM的框架。2009年，angular像一枚重磅炸弹一样，震撼了前端的开发者们。当时，W3C似乎还未推出正式的Web Component标准。React和Vue也还在襁褓之中安眠。可想而知，之后的几年Angular一直影响着后续前端的发展。但是，Angular有着许许多多的问题，也使得它在后续的框架之争中，处于下风。2016年9月正式推出的angular2，将angular引领向了另一种形式——以HTML为中心的框架。一套完整的体现，其中加入了TypeScript+RxJS等组合，可想而知，一套内容的学习成本相当之高，与React以JS为中心的思想完全不同。不过似乎这一次Google将框架的定位目标换成了企业，国内外在使用这套框架的往往是银行、证券类企业。不过，它的发展还是被看好的，毕竟它的背后可都是一群Google的顶尖开发工程师呢！！ 最后，我们来了解一下三驾马车中的黑马——Vue。 从第一张图中，虽然React一直处于领导地位，但是，Vue2的使用，也将于其他两个框架持平快了。毕竟，在国内的前端环境中，Vue可以说是非常受欢迎的。(据说印度开发前端，会用Angular，中国人开发前端，会用Vue)不得不说的是，Vue与Weex的结合，虽然体验不及RN，但是有着阿里的技术支持，也将有希望突破吧。 ## PWA 如果在国外，你今年听到的热词一定会有PWA这个东西。前不久，Safari已经开始支持PWA了，那么也就意味着PWA的时代不会太远了。当然，国内实践PWA的公司也不占少数，例如饿了么、阿里等。从去年开始，对其有所耳闻，到今年Google开发者大会上的现场演示，相信更多的开发者对于这门技术的狂热。对于国内开发者而言，唯一不好的优势应该就是文档了。因为目前来说，大部分的文档都是以英文的形式存在于GitHub或者国外书籍中的。翻译过来的书，也不会这么快的速度问世，所以目前研究PWA的中文资料少之又少。 不过相信，它的发展在之后的一两年的是强而有力的。 ## 国内的小程序 今年，在国内会被称为“小程序年”。从1月份开始，微信正式将公测了小程序。继而在7月份开始，支付宝也推出了相应的小程序。在国内，这样子的重大消息是不容忽视的。两大巨头之争，推动的是无与伦比的流量红利。基于小程序的开发，也将成为国内的前端的一大重点。将原用的整体化的内容，逐步分割成一个个小的模块，将至放入到微信这个大环境中去分享，最后起到一个引流的效果。回到技术的成面，小程序或许会有着与PWA一样的思想，将之前在移动端难以为继的Web端，放入到自家应用中，来确保它的长久与稳定。更多的是说，这两者起到了异曲同工的效果。同样的，这项技术，将在2018年持续发展下去，同时，也会有更多的前端投入到这项开发中去。 ## styled-components...
回顾半年
# 前言 今年是2017年，也是我大学以来最为繁忙的一年，可能是因为大三了吧。由于实习，每天留给我整理博客的时间减少了。我不想自己每天在无知（不知道一天干了点什么的状态）度过，并且将博客移步到了github上面。因为心中有个梦想，希望自己能够在今年完成一项star的收集任务。对于我而言，工业级的架构谈不上，系统化的层级实现不了，nb的类库写不出来，也只能在这里为每位看官留下一笔好的财富（喜欢的话，给我加star哦）。 ### 前端疲劳 今天先来讲一讲我眼中认为的前端疲劳，其实，每天的我都是这样的感觉（累）——并不是心累，而是眼睛累。我真的感觉每天都能在medium上面看到和学到很多的东西，但是，看完之后，就忘记了。 这几年的前端处于井喷的状态，三足鼎立（angular5-beta、react、vue）、打包工具（webpack3和rollup）、（typescript、JavaScript、es6、es7和最近的es8）、性能优化、自动化测试、h5技术、RN、PWA、（css、less、sass、stylus）。看着这么多的东西，第一感觉就是厉害（6666！），但是还是得学，面试得问，项目得用。 ### 如何解决javascript疲劳 其实，每个人都会说，前端你必须得掌握html、css、JavaScript（这三个是基础）。但是，谁都知道，谁都明白，让人的感觉就是白讲。其实，我想表达的是一个方向。接触前端到现在，其实，很多时候前端不一定会都使用框架。回想一下，自己当初学习前端那份初衷在哪里——为了去实现设计师交付给你的那份设计稿，同时也为了交付给用户一个体验良好的产品。其实，前端还有很多其他的东西可以玩，像canvas、svg、webGL、three.js。就像是阿里这样的大公司，还是需要那些做活动界面的前端，或许他们并不会框架，但是他们对于css的掌握，页面的性能，动画的了解一定是一级棒的。每个人找准自己的方向，才是对前端的真正发展。 曾经有个面试官是这么问我的： 你是喜欢css还是js？ 我回答了js。（结果他在之后的面试中问了大部分的问题，而css的部分只是简略了解了一下而已） 我似乎有些佩服这位面试官，因为他懂得区分侧重点。似乎道理也是这么一个道理，平时都在用js、用框架的人，对于css的了解会很深吗？了解css的继承和模块吗？ 往往应对疲劳的方法就是，找准自己的侧重点，然后开始进行深入的学习，才能成为真正的工程师。
# 前言 > 排序算法可能是你学编程第一个学习的算法，还记得冒泡吗？ 当然，排序和查找两类算法是面试的热门选项。如果你是一个会写快排的程序猿，面试官在比较你和一个连快排都不会写的人的时候，会优先选择你的。那么，前端需要会排序吗？答案是毋庸置疑的，必须会。现在的前端对计算机基础要求越来越高了，如果连排序这些算法都不会，那么发展前景就有限了。本篇将会总结一下，在前端的一些排序算法。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的[github博客](https://github.com/laizimo/zimo-article) # 正文 首先，我们可以先来看一下js自身的排序算法sort() ### Array.sort 相信每个使用js的都用过这个函数，但是，这个函数本身有些优点和缺点。我们可以通过一个例子来看一下它的功能： ```javascript const arr = [1, 20, 10, 30, 22, 11, 55, 24, 31, 88, 12, 100, 50]; console.log(arr.sort()); //[...
JS事件循环
> 涉及到多个异步事件执行的时候，大家会不会产生思考！执行顺序，还和原来一样么？还是有什么固定的规则，让我们去判断！今天我们就来了解一下Event Loop的概念。 在聊起这个概念之前，我们先来听一段JavaScript语言的自述。 ### 浏览器为什么选择了我 众所周知，JavaScript是一门单线程的语言。为什么浏览器会去选择它呢！原因就是——**简单**。在浏览器端，复杂的UI环境会限制多线程语言的开发。例如： 一个线程在操作一个DOM元素的时候，另一个线程需要去删除这个DOM元素。这种情况下，我们就需要进行状态的同步。可怕的是，浏览器往往不止去操作一个DOM元素！所以，为了避免开发中处理这种复杂的情况，单线程语言不失为一种好的解决方案。 但是，单线程也会有它的缺陷——**同步阻塞**。如图所示：  CPU在进行一个I/O操作的时候，需要去请求数据，期间需要等待数据返回之后，才能够继续执行下面的任务。这个等待期，就阻塞了其他任务的执行。因此，JavaScript在执行过程中，将任务分成了**同步任务**和**异步任务**，来解决类似的情况。 ### 同步/异步 每个线程都有一个执行栈，会根据**先进后出**的顺序来执行线程中的任务，所有的同步任务，都会被放到这个执行栈中，我们可以来看一段代码： ```javascript function fun1(){ return 'hello hip-hop'; } function fun2(){ return fun1(); } function fun3(){ console.log(fun2()); }...
# 前言 这篇文章的目的是讲解二倍图和三倍图使用时的问题的。之前在开发过程中，总是会遇到一些加粗的图案，无法使用css语法来实现效果。因此，只能够添加图片来展示。但是，单纯的添加图片，会导致图片在部分手机上面看上去模糊不清。因此，我们往往会使用到二倍图和三倍图。同时，还有其外在的原理需要我们去明确。 # 正文 使用了图片，最主要关注的就是**图片的展示效果**和**优化问题**。虽然，在这个需求中，似乎并没有体现的这么重要。但是，优化问题也是需要做的(每解决一个问题，就是在为一堵墙添砖加瓦，加固)。 ### 图片展示效果 展示效果，通常来说，就是整个屏幕的清晰度。整体屏幕的清晰度主要和三个因素有关系： 1. 图片本身像素点是否精细 2. 屏幕的分辨率 3. 屏幕大小 如果是图片本身的问题，那自然不需要多进行优化，直接换图就可以了；而其他的两个因素，我们就需要来好好聊聊了。 屏幕分辨率，即设备分辨率，设备的物理像素。图片大小，从侧面反映，就是图片像素点的多少。熟悉图像处理的人，都知道图片是由一个个的像素点组成的，而像素点中就包含了图片的信息，再由我们经常使用的rgb值进行表示。当然，这只是其中的一个方式。 了解了图片和分辨率，我们可以思考一个问题：一张1080*1920的图片，可以在PC端正常的展示，但是，手机上为啥也可以如此的清晰？毕竟，手机尺寸是远远小于PC的尺寸的。还有何种方式来增加屏幕的分辨率呢？ 所以，这其中掺杂着另一个变量——屏幕密度(PPI)。 ### 屏幕密度 通常来说，尺寸越大的屏幕，分辨率往往也会越高。这样，显示出来的图片也会越来越大，就像06年那种老式的台式机一样。 通过固定屏幕尺寸的话，我们可以通过屏幕密度来增加分辨率。屏幕密度，顾名思义，就是与像素点相关的单位。具体介绍是每英寸中的单位像素点数，即为屏幕密度。一般而言，屏幕密度超过300PPI的话，人眼已经无法辨识出颗粒感了，我们可以通过以下两张图片进行对比一下：  同样的，自从屏幕密度增加之后，我们就可以在手机上看到大分辨率的东西了。但是，由于屏幕尺寸的问题，所以本身很大的图片，在高密度屏中，显示的非常之小，无法达到人为想要的效果。所以，接下来，苹果推出的Retina屏幕才真正解决了这个问题。 ### Retina屏 在谈论Retina屏之前，我们需要来看看，作为前端开发，我们在CSS中使用的px单位代表着什么？CSS像素是一个抽象概念，设备无关像素，简称"DIPS"，device-independent像素。主要使用在浏览器上，来度量页面中元素的长度。 在标准情况下一个css像素对应着一个设备像素。 但是，回到Retina屏幕来说，情况就发生了一些变化。我们之前说，在小屏幕高密度的情况下，一张正常的图片会变得很小，影响着用户体验。Retina屏，在使用中，往往也被称为“双密度屏”。它将原先在标准屏幕下展示的200x300的盒子，展示称为400x600的盒子，保持了相同的物理尺寸。如图所示：...
# 前言 博客停更已经一阵子了，原因林林总总，从毕业到搬家，人生踏入了另一段旅程。今天我们的话题聊一聊区块链。这是我与我毕设相关的主题。大家对于区块链的争议，似乎一直存在。币圈那些陈谷子的事情，影响着区块链的发展。目前，众多区块链团队中，真正在研究区块链应用场景的，少之又少，同样能让区块链应用落地，也需要时间。但是，区块链技术的出现，可以说是一个金融领域和互联网领域的一个里程碑。下面我们来聊聊区块链技术吧。如果你喜欢我的文章，欢迎评论，欢迎Star~[github博客](https://github.com/laizimo/zimo-article) # 正文 其实，早在比特币大火之前，我就听说过区块链(看过一篇公众号讲述区块链与人才链之间的相关性)。当初，对于区块链的理解，并没有特别深刻，同时也毫不在意。在经济社会中，资本已经能够推动技术的发展了。直到比特币大火时，才对区块链技术感到一丝兴趣。 看过比特币的白皮书，发现区块链技术是比特币的一个基础。同时，毕业设计选择的主题也是与区块链相关的方向，所以，在此聊聊区块链。 简单来说，区块链就是一个分布式的账本，或者说分布式的数据库。这个数据库可以同步到节点网络中的每个节点。用阮一峰老师博客中的一张图来形容，如图：  这种图中，我们可以看到，之所以说是去中心化，是因为在整个节点网络中，每个节点都是参与者，每个节点都能够进行数据处理的操作，并没有一个统一的中心化服务器来进行业务处理。然后，每个节点处理的结果会被传播到整个网络中去，来同步全部的网络。 区块链的英文比较有意思，叫做blockchain。我们可以将blockchain拆分开来看就是block+chain(块+链)。所以，我们可以先来了解一下区块的内容。 ### 区块 区块是什么？区块就是一个类似于数据库的东西，用来记录数据的地方。所以，每次系统写入数据时，都会创建区块。 下面，我们来看一下一副区块的实例图，如下：  这里开头有个Previous Hash就是用来记录上一个区块的Hash值的。这样就可以上一个区块和下一个区块连接起来。 同时，它也记录了区块的时间和区块内部的Data。Hash值，就是一种加密后得出来的字符串。Hash是一种单向加密，现实中很少出现Hash碰撞的事件。一般而言，Hash值的破解只能使用只能使用彩虹表等手段才能达到。其本身的安全性就是相对一般的加密方法要高的。我们会接触到的Hash加密有MD5加密、SHA128和SHA256。目前而言，SHA256是很难破解的。 说了这么多Hash相关的内容，回过头来说一下Block。我们可以来看一下，实际的一些Block表内容，如图：  这是一个测试网络的区块列表，我们可以看到它的block ID就是一个hash值。同时，它具备高度等特殊字段，来记录整个区块的内容大小。 了解了区块之后，我们来看一下区块链的形成。 ### 链的形成 拿比特币举例，交易比特币的过程就是，区块形成的过程。区块的建立，就像账本的数据一样，有了数据就有了区块。同样的，生成区块的过程会产生一定的奖励。下面生成的区块会连接上一个区块的hash，这样可以保证整个区块链的不可更改性。如图所示：  如果黑客修改了第51块的内容，那么他就必须修改52块中51的Hash值。同时，修改了52的内容，导致了52本身的Hash值发生了变化。所以，这就导致了一系列的连锁反应。同时，区块链会往整个网络广播整个过程。这样，网络节点中的每个节点都会收到改变，改变自身的区块内容。 这样的设计，可以保证整个网络中的内容没有办法被外力而改变。这也说明整个网络是安全的。那么什么是51%的攻击呢？...
# 前言 > 对于一个影子杀手而言，总能杀人于无形。前端也有影子杀手，它总是防不胜防地危害着你的网站 本篇打算介绍一些前端的影子杀手们——XSS和CSRF。或许，你对它恨之入骨；又或者，你运用的得心应手。恨之入骨，可能是因为你的网站被它搞得苦不堪言；得心应手，可能是因为你从事这项工作，每天都在和此类问题打交道。那我们今天就来了解它，防御它。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的[github博客](https://github.com/laizimo/zimo-article) # 正文 > 注：在开始正文之前，先声明一下，所有的实验环境均为本地搭建——DVWA。 影子杀手们，由来已久，几乎伴随着整个互联网的发展。历史的潮流，总是值得去考究，去深思的。可能在十年之前，这些问题层出不穷；随着开发者安全意识的提高，总是多多少少可以避免的。那么，我们就先来看看，今天的第一位主角——XSS。 ## 第一位主角——XSS > 记得在学校的时候，玩过CTF，应对类似于XSS等网络漏洞，总是会有固定的套路。今天我们也来了解了解这些套路。 ### 概述 XSS的全名叫做Cross-site Scripting。不知你可否会有个疑问，老外都喜欢将英文缩写，但是为什么这个缩写却是XSS呢？因为只能怪它来的晚咯，被css抢先一步^_^。不过没关系，并不阻碍我们记忆它。 XSS是一种代码注入类攻击，它允许攻击者在其他人的电脑上面执行恶意的脚本代码。往往XSS并不需要攻击者去直接攻击受害者的浏览器。攻击者可以利用网站的漏洞，将这一段恶意代码提交。然后，通过网站去传递给受害者，同时窃取受害者的信息等。 我们可以先看一个简单的例子： 或许，你会好奇，我应该怎么去运用网站的漏洞，那我们先来看一张图：  这是一个评论框，然后我们可以在其中输入：  然后，你提交这条信息，如果该网站没有做防护(例如：过滤)，那么，你所在的页面会跳出如下画面：  看了这个信息，或许你已经意识到了它的危害。因为如果可以这样子随意的运行js脚本，对于你客户端的信息(例如：cookie)将统统被窃取。 回到我们的话题，在看到xss的基本效果之后，你会认为JavaScript是危险的吗？ 其实不然，真正的JavaScript是运行在比较严格的环境下面，并不会对操作系统或者其他应用造成伤害。不信的话，你可以打开控制台，在里面随意尝试，你会发现你并没有造成任何危害。那么，我们所谓的XSS的严重性，是吹的吗？ 那就更加不是了。首先，我们要申明的是——何为恶意代码？恶意代码的叫法，并不是因为它本身是有危害的，而是它的意图是对使用者有害的。我们可以来看看，何为对使用者有害？例子：...
# 前言 > 之前，几篇文章我们了解到了一定的基础知识，如果你还未曾看过，可以点击[这个链接](https://github.com/laizimo/zimo-article/issues/31)观看。 本篇内容主要是讲一下文章中文字部分的处理，如'bold'、'italic'、'blockqueto'、'h1'等，以及分割行的插入和链接的插入和修改等模块的代码分析。那么接下来，我们就源码开始，对于我们上述所概述的知识点进行分析。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的[github博客](https://github.com/laizimo/zimo-article) # 正文 从这里开始我们就会根据源码来对每个模块的实现，进行深入的分析和探讨。 ### 字体 首先，我们可以来看一下加粗，斜体和删除线的实现。我们先来看一下，源码： ```javascript commandSet: ['bold', 'italic', 'strikethrough', 'redo', 'undo'], exec: function(command){ const _self = this; if(_self.commandSet.indexOf(command) !== -1){ document.execCommand(command, false, null);...
# 前言 > 前端框架的变迁，体系架构的完善，使得我们只知道框架，却不明白它背后的道理。我们应该抱着一颗好奇心，在探索框架模式的变迁过程中，体会前人的一些理解和思考 本篇将讲述的是前端框架变化过程中的一些思考，前端框架模式的变化：从无到有，从MVC(Flux或者Redux)->MVP->MVVM。这段变化的过程，会让人不断琢磨，每次的变化，都是一次大的进步。现在在前端的框架都是MVVM的模式，还有像Flux和Redux之类的MVC变种——独特的单向数据流框架。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的[github博客](https://github.com/laizimo/zimo-article/issues) # 正文 其实，这些框架模式我们平时都会有所接触。它遵循着将整体应用的功能块进行分离的原则，对开发者开发软件进行一定的规范，以保持系统的稳定以及可维护性。 讲述前端框架变迁的过程中，我们可以通过梳理最近几十年的前端发展时间线，来深入分析前端的从无到有，从有到优的过程。 ## 最初的时代 最初的时代，应该是web1.0时代吧。当时，开发者们并没有前端的概念。开发一个应用，或许只要5个人的小团队，就能够很快的配置出可运行的环境。而开发的语言使用的也是最初的JSP、ASP和PHP。拿JSP举例的话，当时系统的整体架构图可能是这样子的：  > 记得在学校的时候，最早搭建系统就是使用的这种架构。 这种架构的好处是简单快捷。使用Eclipse+tomcat就可以之间把程序跑起来，以及jsp的强大功能，足够满足小应用的开发。 但是，同样缺点也非常明显： 1. **业务体系增大，调试困难**：随着业务体系的增大，后台service也会逐步膨胀，大致需要建设一个开发服务器进行存放，这会导致一个问题就是前端无法在本地进行调试，每次进行修改之后，都必须上传到开发服务器进行测试（况且开发服务器可能本身就不稳定）。 2. **JSP代码难以维护**：或许人少的时候，学JSP挺简单的。但是，一旦团队人数增多，JSP内参杂的业务逻辑也会逐渐增加，这会导致的是JSP本身难以维护。 为了让开发更加的便捷，代码变得更加的可维护，同时使得前后端的职责加以分离。这时，我们或许会考虑改变一下开发模式，将后端MVC化，而前端的展示则以模板的形式进行嵌套。典型的框架就是Spring、Structs。整体的框架，如图所示：  使用这样子的架构，复杂度被降低了，职责也会比较清晰。这个时代被称为后端的MVC时代。这个时候，前后端开始形成了一定的分离。前端只需要在本地编写好相应的页面，然后交给后端开发的人，让他们可以根据模板进行一个嵌套。这是前端只完成了后端开发中的view层内容。淘宝的早期使用的就是这种模式。现在仍有小部分创业型的公司会使用这种方式进行开发，主要是节约用人成本。 但是，同样的这种模式存在着一些： 1. **前端页面开发效率不高**：其实，早期的时候根本也没啥前端开发工程师，有的只是页面仔。更多公司可能也有后端的人使用js在写页面的。因此，问题就暴露了出来，前端所做出来的页面需要放到后端环境去运行，使得前端开发的效率并不是特别之高，因为对于后端环境的依赖程度比较大。 2. **前后端职责不清**：由于前端并未做太多的工作，以至于后端的开发体量比较庞大。就拿路由管理来举例子，本来路由管理可以由前端开发的人员来进行开发和管理。但是，使用这种架构时，后端需要去维护一个庞大的路由表，增加了后端的开发量。 ##...