我们先看几个网站：
编码（）
团队合作（）
云9（）
注意这些网站的相似之处，即在浏览器中，它们在客户端做了“应该”做的事情。 它们的界面切换非常流畅，响应速度非常快，与传统网页有着明显的区别。 这些是什么？ 这是一个单页 Web 应用程序。
所谓单页面应用是指将多种功能集成在一个页面上，甚至整个系统只有一个页面，所有业务功能都是其子模块，通过特定的方法链接到主界面。 它是AJAX技术的进一步升华，它最大限度地发挥了AJAX的无刷新机制，因此可以打造媲美桌面程序的流畅用户体验。
虽然单页应用我们并不陌生，但是很多人都写过ExtJS项目extjs网站模板，用它实现的系统自然也是单页应用，也有人用jQuery或者其他框架实现过类似的东西。 单页应用可以使用各种JS框架来实现，甚至可以不使用框架。 这只是一个概念。 有些框架适合开发这样的系统，如果使用它们，可以获得很多便利。
开发框架
ExtJS堪称典型的第一代单页面应用框架。 它封装了各种UI组件。 用户主要使用JavaScript来完成整个后端部分，甚至包括布局。 随着功能逐渐减少，ExtJS的体积也逐渐缩小。 虽然用于内部系统的开发，但有时会变得繁琐，更不用说开发上述运行在互联网上的系统了。
由于jQuery专注于DOM操作，其插件体系比较松散，因此它比ExtJS系统更适合开发运行在网段上的单页面系统。 整个解决方案将相对轻量且灵活。
但由于 jQuery 主要面向底层操作，因此缺乏对代码组织的约束。 如何在代码扩展时控制各个模块的内聚性，以及如何在模块之间正确地传输和共享数据，成为了一项具有挑战性的任务。
为了解决单页应用规模缩小时的代码逻辑问题，出现了很多MV*框架。 他们的基本思想是在JS层创建模块分层和通信机制。 有的是MVC，有的是MVP，还有的是MVVM，但几乎都对这个模型进行了变异，以适应后端开发的特点。
此类框架包括 Backbone、Knockout、AngularJS、Avalon 等。
组件化
后端的这种分层框架促进了代码的组件化。 所谓组件化，更多的是指传统Web产品中的UI组件，但毕竟组件是一个广义的概念。 UI组件在传统Web产品中占有很大的比例。 比率高的原因是其长度不够。 随着客户端代码比例的减少，相当一部分业务逻辑也在后端，这就导致了很多非界面组件的出现。
分层带来的好处之一就是每一层的职责更加具体，这样可以通过单元测试来覆盖，保证其质量。 传统UI层测试最麻烦的问题就是UI层和逻辑混在一起。 例如，DOM在远程请求的反弹中经常被修改。 当引入分层时，这些东西可以单独测试，然后通过场景测试。 保证全流程。
代码隔离
与传统的基于页面的网站的开发相比，在实现单页面应用的过程中有一些值得特别注意的地方。
从单页面应用的特点来看，它比页面类型的网站更依赖JavaScript。 由于页面的单页性，各个子功能的JavaScript代码都聚集在同一个范围内，因此出现了代码的隔离性和模块化。 很重要。
在单页面应用程序中，页面模板的使用非常常见。 很多框架都有外部特定的模板，有些框架需要引入第三方模板。 这些模板是界面片段，我们可以将它们与 JavaScript 模块进行比较，后者是另一种类型的组件。
模板也有隔离的需要。 不隔离模板会导致什么问题？ 模板之间的冲突主要存在于id属性上。 如果一个模板包含固定的id，那么在批量渲染时，会导致同一个页面的范围内出现多个具有相同id的元素，导致结果不可预知。 因此，我们需要避免在模板中使用 id。 如果需要访问DOM，应该通过其他选择器来完成。 如果单页应用组件化程度很高，很可能整个应用都没有使用任何元素id。
代码合并和加载策略
人们对单页面系统加载时间的容忍度与网页系统的加载时间不同。 如果他们愿意为购物页面的加载等待3秒，那么他们可能愿意为单页应用的首次加载等待5-10秒，但在此之后，各种功能的使用应该是相对顺利的，并且所有子功能页面尽量在1-2秒内切换成功，否则会感觉系统很慢。
从这个特性来看，我们可以在第一次加载时放置更多的公共函数，以减少每次加载的负载。 有的网站甚至把所有的界面和逻辑都放到首页去加载，而且每次业务界面切换时，只产生数据请求，所以它的响应速度非常快。 比如青云的控制台就是这么做的。
一般在单页应用中，不需要像网站产品那样在html前面加载js以避免文件加载阻塞渲染，因为它的界面基本都是动态生成的。
功能切换时，不仅会产生数据请求，还需要渲染界面。 这个新渲染的界面组件通常是一个界面模板。 它从何而来？ 来源不外乎两种，一种是即时请求，通过类似AJAX的请求数据来获取，另一种是外部放置在主界面的各个位置，比如脚本标签或者不可见的文本区域，前者是在切换中function 时间速度有优势，但增加了主页的负担。
在传统的页面型网站中，页面之间是相互隔离的。 因此，如果页面之间存在可重用的代码，通常会将其提取到单独的文件中，并且可能需要根据每个页面的需要进行合并。 。 在单页面应用中，如果代码总量不大，可以整体打包，一次性加载到首页。 如果足够大，可以在运行时加载。 装载的细度可以做大一些，不同块之间没有间隙。 重复部分。
路由和状态管理
我们一开始听说的一些在线应用程序管理路由，有些则没有。
管理路由的目的是什么？ 就是为了降低用户的导航成本。 例如，我们有一个在多次点击导航菜单后呈现的功能。 如果用户想把这个功能地址分享给其他人，该怎么做呢？
传统的基于页面的产品不存在这个问题，因为它们是基于页面的，有时，服务器端路由会处理所有这些。 而在单页面应用中，这就成为一个问题，因为我们只有一个页面，界面上的各种功能块都是动态生成的。 所以我们需要通过路由管理来实现这样的功能。
具体做法是，将产品功能定义为若干个状态，每个状态映射到对应的路由，然后通过pushState等机制，动态解析路由来匹配功能接口。
有了路由，我们的单页产品就可以向前和向后移动，就像在不同页面之间一样。
虽然在Web产品之外早已有路由管理的技术方案，但在AdobeFlex中，诸如TabNavigator甚至下拉框的选中状态都会映射到url，因为它也是单“页面”产品模型，需要面对同样的问题。
当产品状态复杂到一定程度时，路由就变得很难应用，因为状态管理很麻烦。 例如，我们一开始演示的c9.io在线IDE无法将状态映射到url。
缓存和本地存储
在单页应用的运行机制中，缓存是一个非常重要的环节。
因为这类系统的后端部分几乎都是静态文件，所以它可以有机会利用浏览器的缓存机制，并且比如动态加载的界面模板，还可以做一些自定义的缓存机制。 请求中直接获取缓存版本，提高加载速度。
甚至，已经出现了一些解决方案来缓存 JavaScript 代码，同时动态加载它们。 例如AddyOsmani的basket.js使用HTML5localStorage来缓存js和css文件。
在单页产品中，业务代码常常需要与本地存储打交道，以存储一些临时数据。 您可以使用localStorage或localStorageDB来简化您自己的业务代码。
服务器通讯
传统的Web产品一般使用JSONP或AJAX与服务器通信，但很大一部分单页Web应用程序使用WebSocket等实时通信方式。
与传统的基于HTTP的通信机制相比，WebSocket具有很大的优势。 它可以让服务器非常方便地使用反向推送，后端只响应确实形成业务数据的混乱extjs网站模板，减少了一遍又一遍无意义的AJAX协程。
由于 WebSocket 仅在更高级的浏览器上支持，因此有一些库提供了不同浏览器中的兼容性解决方案，例如 socket.io，在不支持 WebSocket 的浏览器上会降级为使用 AJAX 或 JSONP 等方法，完全透明并兼容业务代码。
内存管理
传统网页通常不需要考虑显存的管理，因为用户的停留时间比较短，虽然一次显存泄漏可能会通过刷新页面等操作很快被冲走，但单页面应用则不同。 它的用户可能会整天打开它。 为此，我们需要更加小心DOM操作、网络连接等部分。
风格规划
在单页面应用中，由于页面集成度较高，所有页面都聚集在同一个范围内，样式规划也很重要。
风格规划主要有几个方面：
基本样式的分离
这主要包括重置浏览器样式、设置全局字体、基本布局约定和响应式支持。
组件样式的定义
规划有两个层面，第一个是各种界面组件及其子元素的样式，第二个是一些装饰风格。 组件样式应尽量减少相互依赖，并且每个组件的样式允许冗余。
堆垛顺序管理
传统网页的特点是元素多、层次少，单页应用则有些不同。
在单页面应用中，需要提前规划好各个UI组件的堆叠顺序，即z-index。 例如，我们可能有各种弹出对话框和浮动层，它们可能组合成各种堆叠状态。 新对话框的 z-index 需要高于旧对话框，以确保其前面被覆盖。 这些都需要我们对那些可能的覆盖物进行规划，那么如何规划呢？
了解通信知识的人应该知道，不同的通信方式定义了不同的频段。 在一些国家，还定义了空域的使用。 我们也可以用同样的方法进行预分割，不同类型的组件的z-index落入各自的区间，防止它们发生碰撞。
单页应用的产品形态
我们一开始就提到，有很多新型的Web产品是使用单页面应用方法构建的，但实际上，这样的产品只存在于Web上。 点击Chrome商店，我们会发现很多离线应用程序，这类产品可以称得上是单页应用程序的亮点。
不仅是各种浏览器插件，还可以使用像node-webkit这样的shell平台，我们可以利用Web技术来构建本地应用程序。 产品的主要部分始终是我们熟悉的单页应用程序。
单页应用程序的受欢迎程度正在逐渐下降。 如果你关注一些初创的互联网公司，你会发现他们的产品模式很大一部分都是单页的。 这些模式能够给用户带来流畅的体验，并且在开发阶段需要较高水平的JavaScript技能。
在单页面应用程序开发过程中，前端和后端自然是分离的，并以API作为两侧的边界。 后端充当服务的消费者，前端充当服务的提供者。 在这种模式下，后端会推动前端的服务。 当前端不再负责模板渲染和页面输出时，它可以更加专注于提供的API的实现。 前端API不再需要针对每一端进行区分。
部署模式变更
在当今时代，我们已经可以看到一种产品的出现，那就是“无前端”Web应用程序。 这是什么东西？ 基于这些理念，你的产品很可能只需要自己编译静态网页，在某个BaaS（Backend as a Service）云平台上定制服务器API和云存储，集成该平台提供的SDK，通过AJAX处理即可等方式，实现注册认证、社交、消息推送、实时通讯、云存储等功能。
当我们观察这些模型时，我们会发现前端和后端的部署已经完全分离，后端代码完全静态，这意味着它们可以放在CDN上，访问也可以将大大加速，而服务器托管在 BaaS 云上。 开发人员也不必担心有关部署的冗长细节。
假设你是一名创业者，你正在做的是一个实时协作的单页产品。 您可以在云平台上快速定制前端服务，将大部分宝贵的时间花在产品本身的开发上。
单页应用程序的缺点
单页应用最根本的缺陷就是不利于SEO。 由于大部分界面是动态生成的，搜索引擎很难对其进行索引。
单页产品带来的挑战
一个产品想要单页，首先要适合单页表单。 其次，在这个过程中，开发模式会发生一些变化，对开发技能也会有一些要求。
开发人员的JavaScript技能必须过关，同时需要对组件化和设计模式有了解。 他面对的不再是一个简单的页面，而是一个运行在浏览器环境中的桌面软件。
【今日陌陌公众号推荐↓】
