单页Web应用：

概念：

Web应用程序：

WEB应用程序一般是B（浏览器）/S（服务器）模式。Web应用程序首先是“应用程序”，和用标准的程序语言，如C、C++等编写出来的程序没有什么本质上的不同。然而Web应用程序又有自己独特的地方，就是它是基于Web的，而不是采用传统方法运行的。换句话说，它是典型的浏览器/服务器架构的产物。

理解了什么是浏览器/服务器架构，就了解了什么是Web应用程序。常见的计数器、留言版、聊天室和论坛BBS等，都是Web应用程序，不过这些应用相对比较简单，而Web应用程序的真正核心主要是对数据库进行处理，管理信息系统（Management Information System,简称MIS）就是这种架构最典型的应用。MIS可以应用于局域网，也可以应用于广域网。基于Internet的MIS系统以其成本低廉、维护简便、覆盖范围广、功能易实现等诸多特性，得到越来越多的应用。

Web app：

WebApp是指基于Web的系统和应用，其作用是向广大的最终用户发布一组复杂的内容和功能。

其实这些服务大多都是Web App。我常常这样问自己“这个程序是否完成了某个任务？”。即便它只完成了某个非常小的任务，那么它也是一个Web App。Google的搜索引擎就是一个Web App，它本质上和电话查询服务没有什么区别。

这样说来，也并非所有的网站都是Web App。如果这个网站并没有执行任何任务，那么它就并不是Web App。

 

单页Web应用：

SPA 是适合放在单个可滚动网页上的 Web 应用程序或网站，它们会动态地加载合适的内容来响应用户操作。它们支持在单个页面上与多个组件进行丰富的交互。

单页Web应用，顾名思义，就是只有一张Web页面的应用。浏览器一开始会加载必需的HTML、CSS和JavaScript，之后所有的操作都在这张页面上完成，这一切都由JavaScript来控制。因此，单页Web应用会包含大量的JavaScript代码，复杂度可想而知，模块化开发和设计的重要性不言而喻。

 

多页 Web 应用程序对比 SPA：

传统 Web 应用程序通常由静态内容组成，用户在页面之间导航时需要加载完整的页面并在客户端与服务器之间传输数据。

由于以一个页面的形式传送到浏览器，所以 SPA 不需要重新加载页面，甚至在客户从应用程序的一部分转移到另一部分时也不需要。

因为 SPA 将数据与数据的表示分开，所以它们可重绘UI 的任何部分，而不需要服务器往返传输来检索 HTML。因此，SPA 提供了更加流畅的用户体验，更快的导航，以及更高效的网络传输。

 

SPA的优势：

1、它提供了更加吸引人的用户体验。单页应用可以做到一举两得：桌面应用的即时性和网站的可移植性和可访问性。

2、单页应用可以和桌面应用一样渲染—单页应用只需要重绘界面上需要变化的部分。相比之下的传统网站，许多用户操作都会重绘整张页面，结果是当浏览器从服务器获取数据时，页面会假死并有“闪烁”现象，然后再重绘页面上的所有东西。如果页面很大，服务器又繁忙，或者网络连接很慢，这种“闪烁”现象会持续好几秒钟甚至是更长时间，用户只得猜测页面什么时候才可以再次使用。与单页应用的快速渲染和即时反馈相比，这是一种很恐怖的体验。

3、单页应用可以拥有和桌面应用一样的响应速度—尽可能地把（临时的）工作数据和处理过程从服务端转移到浏览器端，单页应用由此把响应时间减至最小。单页应用在本地拥有大多数需要决策判断的数据和业务逻辑，因此是很快的。只有数据验证、授权和持久存储必须要放在服务端，原因我们会在第6章到第8章中进行讨论。传统网站的大多数应用逻辑在服务端，对大部分的用户输入的响应，他们必须等待一个“请求/响应/重绘”的循环周期。与接近即时响应的单页应用相比，这需要花费几秒钟的时间。

4、单页应用和网站一样，也是跨平台的。

 

SPA的缺点：

1、SPA还有一些历史遗留问题（大部分是针对HTML5的改进）以及SEO。目前该技术还存在一些争议，但这并不是重点，因为这种类型的体系架构为SAAS Web Apps提供了一个极大的可用性。

2、对搜索引擎不友好，单页应用实际是把视图（View）渲染从Server交给浏览器，Server只提供JSON格式数据，视图和内容都是通过本地JavaScript来组织和渲染。而搜索搜索引擎抓取的内容，需要有完整的HTML和内容，单页应用架构的站点，并不能很好的支持搜索。

 

一个单页面Web应用程序就是一个Web应用程序，但结构不同。其中最重要的是：在第一次请求的时候，所有的标记语言（HTML）就已经传输到客户端，其余的请求都通过REST API获取JSON数据，数据的传输通过Web Socket API或远程过程调用。单页面应用程序可以说是分拆Web技术的最后一步——通过分离(css)内容，改进架构（XML和 XSLT）上的灵活性，调用服务器（AJAX）再到解压应用程序的导航页面结构。因此，这在Web发展中是个历史性的转折点。

单页Web应用程序的结构很简单：首先传递HTML文档框架；然后使用JavaScript修改页面；紧接着再从服务器传递更多数据然后再修改页面，如此循环。从性能的角度看，在现代浏览器中单页面Web App已经能够和普通应用程序相媲美，而且几乎所有的操作系统都支持现代的浏览器。使用HTML+CSS+Javascript编写应用程序，能使更多的人们都加入到程序开发的行列。

这足以说明，在Web设计过程中标志着Web将呈现一种新的趋势，它将一个分离的功能层作为API并将表示层用APP的形式体现出来 (HTML5或Native)：

 

SPA中URL中的#号

单页应用只有一个页面，视图的变化通常是通过路由（route）来驱动，首先，我们先来谈一谈单页应用的URL中的#号，很多采用单元结构网站的URL都出现了这个符号。

#号在浏览器的URL中是一个锚点，在当前页改变#号的参数，页面会跳转到锚点所在的位置，通过JavaScript我们可以获取到#号后的参数：

 

改变#号后的参数，页面并不会重载，于是大多数的单页架构网站，都在URL中采用#号来作为当前视图的URL地址，例如：

 

符号#!，Twitter曾在URL使用这个标识。这个标识是Google提出（AJAX 抓取：网站站长和开发人员指南1）：

因为复杂的单页架构页面，对Google来说抓取比较困难，于是给开发者制定一个规范：

1、网站提交sitemap给Google；

2、Google发现URL里有#!符号，例如example.com/#!/detail/1，于是Google开始抓取example.com/?_escaped_fragment_=/detail/1；

_escaped_fragment_这个参数是Google指定的命名，如果开发者希望把网站内容提交给Google，就必须通过这个参数生成静态页面。

如此以来，就需要Server通过生成静态的内容以便Google抓取。

以下将简单介绍，单页架构，爬虫访问根目录时如果配置Server端的路由。

判断爬虫

当Google访问119.28.4.22/#!/detail/1 时，会自动转化成http://119.28.4.22/?_escaped_fragment_=/detail/1，，以Nginx为例：

 

/api为后台服务的接口，已nodejs为例，代理设置如下：

 

如此，我们便将Google的访问重写到/api这个接口，然后在Server的/api处理请求把静态内容输出即可。

 

Sitemap

Google的这个规范，必须有sitemap支持，因为有可能单页架构的站点，索引页面也是JavaScript渲染的。提交sitemap时，不用关注_escaped_fragment_这个参数名，只提交带哈希符号的URL即可，例如：

 

技术潮流的步伐很快，单页应用，URL哈希处理也没渲染的方式实际上已经流行了很久，在国外很多用户数据较好的情况下，开发者会选择HTML5 History API的pushstate特性开发，在URL中抛弃#!。但是IE6、7等低端浏览器用户情况较多的网站，#能够很好的兼容。关于采用HTML5 History API来架构单页应用的方案，也欢迎讨论。