Web开发技术的演变

来源：互联网发布：base64 json 图片编辑：程序博客网时间：2024/06/05 09:26

web发展了几十年，这期间，技术千变万化，很多技术都被淘汰了，我们并没有完整的经历过这个历史。下面介绍各项技术的革新。

前后端不分
最初的web开发比较简单，开发者操控web服务器（经常还是他自己的服务器），有时候他还会写一些html代码放在指定的文件下。当发送html请求时，这些页面会出现。
这里写图片描述

以上返回的是静态内容，倘若查看网站的访问量或者放访问者填写包含姓名和邮箱的表单？可看到此模式的局限性。于是就出现了以下模式：
这里写图片描述
它可以在web服务器端运行一小段代码，并且能文件系统或数据进行交互。但是这样的模式有以下几点缺点。

1.CUI伸缩性不太好，每个请求都需要分配一个进程。2.直接使用文件系统或专精变量，并不太安全。

直至2005年，出现了Java Server Pages(JSP)，微软的ASP，以及PHP，这个局面才得到改观。
这里写图片描述

我们知道servlet是java编写的服务器端程序，可以方便的处理http请求和返回，可以把html文本当做字符返回。

public class HelloWorldServlet extends HttpServlet {    @Override    public void doGet(HttpServletRequest req, HttpServletResponse resp)        throws ServletException, IOException {        resp.setContentType("text/html");        PrintWriter out = resp.getWriter();        out.println("<html><head><title>Hello World Sample</title></head>");        out.println("<body><h1>Hello World Title<h1><h2>" +new Date().toLocaleString() + "</h2></body></html>");        out.flush();    }}

但是以上技术也存在以下缺点。

1.可维护性不好，UI和业务逻辑耦合性很强。2.难以要求开发者同时静态前后端。

后端MVC
以上解决方案存在的致命问题值逻辑混乱。
解决方案是采用MVC，把业务逻辑抽离到 Controller 中，让 View 层专注于显示 UI。MVC是开发所有软件所涉及的基本划分

M主要负责数据与模型，V主要负责显示C主要负责交互与业务

对于后端的MVC来说，如下：

M主要是指数据库，文件等V主要是指包括HTML模板，HTML的组装，其它的动态UI显示技术C是一样的，但是一般的象HTTP请求都包括了路由请求，很多HTTP模式化的业务都抽象成了对应的专用软件，比如web server, session 服务器， 队列。C当然包括业务逻辑。而业务逻辑本身就有很多种。包括搜索引擎，机器学习等，都可以归于业务逻辑。

在前端开发领域也有类似的技术，比如JSP，在写JSP的时候，我们更关心页面样式，因此代码看起来像html，只不过在<% %> 代码块中可以调用 Java 函数:

<HTML><HEAD><TITLE>JSP测试页面---HelloWorld!</TITLE></HEAD><BODY><%    out.println("<h1>Hello World!</h1>");%></BODY></HTML>

JSP相当于view层，它从model中获取数据，Controller 作为直接和客户端接触的模块，负责解析请求，数据校验，路由分发，结果返回等等逻辑。路由分发是指根据请求路径的不同，调用不同的 Model 和 View 提供服务。

使用MVC框架后，前端开发者负责写JSP，后端开发者负责写controller和model,但也存在以下问题

1.业务逻辑并没有完全严格区分，JSP中往往混入业务代码。2.前端开发者还得熟悉后端语言，学习和沟通成本大。

从一定程度上来说，JSP可以看作是HTML模板的雏形，HTML 大体上肩负了两个任务: 页面框架和内容描述。所谓的 HTML 模板是指利用一种结构化的语法，表示出 HTML 的框架，同时把具体数据抽离出来。
比如 <p>111</p> 表示一个段落，其中内容为 “111”。如果用模板来表示，可以写作 <p>Content</p> 。我们只要知道:

数据 + 模板 = HTML 源码

比如在 Controller 层，可以这样调用:

// 这里没有指定模板的名称，是因为使用了依赖倒置的思想，在配置文件中绑定了 Controller 对应的 Viewreturn res.view({title: "111"});

模板中的代码如下:

<h1><%= Content%></h1>

其实我们可以发现，这其实采用了 Sails.js + EJS 开发。前者是基于 JavaScript 的服务端应用程序，后者是基于 HTML 语法的模板，另一种风格的模板是 Jade。

由此可以看到，它相对于JSP的优势在于，利用工具强行禁止前端开发者在视图层写业务逻辑，前端开发者只需要关心 UI 实现并确定 HTML 中的变量。而后端开发者只要传入参数即可获取 HTML 格式的字符串。

模板开发的另一个好处是前后端可以同步开发。双方约定一个数据格式，前端就可以模拟出假数据并用来自测，后端也可以用生成的数据与假数据对比进行测试。同时，这个约定的数据格式扮演了契约和文档的作用，规范了双方的数据交流形式，从而节省交流的时间成本。

AJAX 与前端 MVC
当时，web服务器多半返回的是整个页面或者文档，直到ajax的出现（2005年）。AJAX 的全称是 Asynchronous Javascript And XML，即 “异步 JavaScript 和 XML”。它并非一个框架，而是一种编程思想。它利用 JavaScript 异步发起请求，结果以 XML 格式返回，随后 JavaScript 可以根据返回结果局部操作 DOM。

AJAX 最大的优点是不用重新加载全部数据，而是只要获取改动的内容即可。
服务器端返回的仍然是HTML，但浏览器上的代码能把这HTML片段内嵌到当前页面中。也就是说web应用的响应可以更快，这时我们真正用web应用取代了web页面。
这里写图片描述

得益于 AJAX 的提出，HTML 在前端渲染变成了可能。我们可以下载一个空壳 HTML 文件和一个 JavaScript 脚本，然后在 JavaScript 脚本中获取数据，为 DOM 添加节点。

在这种情况下，前后端的分工非常清晰，前后端的关键协作点是 Ajax 接口。看起来是如此美妙，但回过头来看看的话，这与 JSP 时代区别不大。

在2007到2010年期间，涌现了3种开发潮流：

第一个是智能手机和移动应用潮流。通常情况下，许多应用程序同时有web和移动应用两种版本。尽管如此，服务端仍然返回的是HTML页面，而不是其它移动应用可以识别。因此，你需要返回的是结构化数据来取代HTML。第二个开发潮流是jQuery。这是一个非常流行的javascript库，能够很容易构建动态、美妙的web应用，甚至是AJAX！第三个潮流是Node.js的发布。这是第一次能让你用JavaScript开发高性能的服务端程序，进而可能结束“客户端开发者”要知道HTML/JavaScript，“服务端开发者”要知道.NET/C#/Ruby这样的噩梦。

这里写图片描述

这是一种不错的架构，但是用jQuery容易写出像意大利面似的代码，我们以一种规定的方式从服务端获取数据，再对客户端的HTML页面进行包装。因此出现了许多简化客户端开发的框架，比如Backbone，Ember，react，vue等。
这里写图片描述

<!DOCTYPE html><html><head>  <script src="../build/react.js"></script>  <script src="../build/react-dom.js"></script>  <script src="../build/browser.min.js"></script></head><body>  <div id="example"></div>  <script type="text/babel">    var LikeButton = React.createClass({       getInitialState: function() {         return {liked: false};       },       handleClick: function(event) {         this.setState({liked: !this.state.liked});       },       render: function() {         var text = this.state.liked ? 'like' : 'haven\'t liked';         return (          <p onClick={this.handleClick}>            You {text} this. Click to toggle.          </p>        );       }     });     ReactDOM.render(      <LikeButton />,       document.getElementById('example')     );  </script></body></html>

这段代码不用完全读懂，你只要意识到，引入 React.js 这个框架后，我们就可以脱离 HTML 编程了。所有的逻辑都写在 <script> 标签块中的 JavaScript 代码中。

我们还创建了一个 LikeButton 组件，它可以拥有自己的方法，管理自己的状态等等。这里举 React 的例子可能略有不妥，因为它其实只是一个 View 层的实现方案，还需要配合 Flux 或 Redux 架构。

这种开发模式和移动端开发非常类似，使用 JavaScript 调用 DOM 接口来绘制视图，使用 JavaScript 来实现业务逻辑，处理数据，发起网络请求等。你完全可以理解为单纯用 JavaScript 在浏览器上开发移动应用，只不过用户下载的是 JavaScript 脚本而非传统静态语言编译后的二进制文件。

使用了前端 MVC 框架后，前后端各司其职，唯一的联系就变成了 API 调用，前端开发者不再依赖后端环境，HTML 和 JavaScript 都可以放在 CDN 服务器上。这就是我们常说的 前后端分离 的基本概念，即前端负责展现，后端负责数据输出。

前后端分离的缺点
前后端并非完美，也存在一些缺点。如：

1.不利于SEO。搜索引擎的工作原理是访问每个网页，然后分析 HTML 中的标签和关键字并做记录。一个纯异步的网页，HTML 几乎是空壳子，而偏偏关键的数据都是动态下发的，这就影响了搜索引擎爬虫的工作过程，他们会认为该网页什么都没有，即使记录下来的也是非关键数据。2.性能不够。从上文中 React 的示范代码可以看出，HTML 文件非常小，很快就被打开。但是页面的渲染逻辑直到 JavaScript 文件被下载后才能开始执行，这就会导致一段时间的白屏。

Node.js
以上介绍了后端的MVC架构，HTML模板，前端MVC架构等多种方案，但结局并不是很完美。

我们过分强调物理层上的前后端分离，忽略了两者天然存在一定的耦合。实际上，前端开发者不仅关注 View 的实现，还应该负责一部分 Controller 中的逻辑，后端开发者则应该关心数据获取与处理，以及一些跨终端的业务逻辑。

如果页面渲染在后端实现，会导致前端开发者依赖后端实现和开发环境，后端开发者被迫熟悉前端逻辑(此时不是调用 API 而是直接生成数据并套用模板，这就要求把获取的数据转换成模板需要的数据)。

如果页面渲染全部放在前端，业务逻辑就会太靠前，从而导致不能复用。这种做法似乎有些矫枉过正了。

页面渲染不管是放在前端还是后端都不合适。其实这很好理解，页面渲染涉及数据逻辑和 UI，他们理应分别由前后端开发者分别负责，单独交给任何一方都显得不合适。

如果让前端工程师写后端代码，问题是不是就解决了。随着 Node.js 的兴起，JavaScript 开始有能力运行在服务端。这意味着可以有一种新的研发模式。
![通过 Node，Web Server 层也是 JavaScript 代码，这意味着部分代码可前后复用，需要 SEO 的场景可以在服务端同步渲染，由于异步请求太多导致的性能问题也可以通过服务端来缓解。前一种模式的不足，通过这种模式几乎都能完美解决掉。
这里写图片描述

在这种研发模式下，前后端的职责很清晰。对前端来说，两个 UI 层各司其职：

1、Front-end UI layer 处理浏览器层的展现逻辑。通过 CSS 渲染样式，通过 JavaScript 添加交互功能，HTML 的生成也可以放在这层，具体看应用场景。　　2、Back-end UI layer 处理路由、模板、数据获取、cookie 等。通过路由，前端终于可以自主把控 URL Design，这样无论是单页面应用还是多页面应用，前端都可以自由调控。后端也终于可以摆脱对展现的强关注，转而可以专心于业务逻辑层的开发。

通过 Node，Web Server 层也是 JavaScript 代码，这意味着部分代码可前后复用，需要 SEO 的场景可以在服务端同步渲染，由于异步请求太多导致的性能问题也可以通过服务端来缓解。前一种模式的不足，通过这种模式几乎都能完美解决掉。

与 JSP 模式相比，全栈模式看起来是一种回归，也的确是一种向原始开发模式的回归，不过是一种螺旋上升式的回归。

以上为web开发技术的演变过程，至于未来会变成什么样，还是值得期待。

阅读全文

0 0