coding、teambition、cloud9这几个网站是什么？原来是单页Web应用

让我们先来看几个网站：

coding（）

teambition（）

cloud9（）

留意这些网站的共同之处，可以发现它们在浏览器中执行了本应在客户端完成的功能。界面转换极其顺畅，反馈速度极快，与传统网页有着显著差异，那么它们究竟是什么呢？这便是所谓的单页Web应用。

单页应用，即在一个页面内整合了多样化的功能，甚至整个系统仅由一个页面构成，所有业务功能均作为其子模块，以特定方式附加至主界面之上。这种应用是AJAX技术的深化发展，将AJAX的无刷新特性推向了顶峰，从而实现了与桌面程序相媲美的流畅用户交互体验。

我们对于单页应用并不感到陌生，众多人曾参与过基于ExtJS的项目开发，所构建的系统自然而然地就具备了单页应用的特性；此外，还有不少开发者利用jQuery或其他框架成功实现了类似功能。无论是采用多种JavaScript框架，还是不依赖框架，实现单页应用都是可行的，这仅仅是一种开发理念。某些框架特别适合用于此类系统的开发，若采用这些框架，将能享受到诸多便利。

开发框架

ExtJS被视为首代单页应用框架的典范，其中集成了众多UI组件。用户主要依赖JavaScript来构建前端，这其中包括了布局设计。然而，随着功能的不断丰富，ExtJS的体积也在不断膨胀。即便是在内部系统的开发中，它有时也会显得较为臃肿。更别提那些运行在互联网上的系统了。

jQuery在DOM操作方面具有倾斜，且其插件架构较为松散，因此相较于ExtJS体系，它更适宜用于构建运行于公网的单一页面系统。这样的解决方案整体上会更加轻盈、易于调整。

尽管jQuery主要专注于高层的操作，但在代码结构上却缺乏一定的规范性。面对代码量的迅速增加，如何确保每个模块的紧密性，同时合理地在模块间实现数据的交换与共享，这无疑是一项颇具挑战性的任务。

为了应对单页应用规模扩大所带来的代码逻辑难题，众多MV*框架应运而生，这些框架的核心思想在于在JavaScript层面构建模块化分层及通信机制。其中，有的是采用MVC模式，有的是MVP模式，还有的是MVVM模式，而且，这些模式在应用过程中都进行了相应的调整和演变，以更好地契合前端开发的需求。

这类框架涵盖了诸如Backbone、Knockout、AngularJS以及Avalon等多种类型。

组件化

这些前端分层框架促进了代码的模块化进程，而所谓的模块化，在传统Web产品中，通常涉及UI模块。然而，模块化是一个更为宽泛的概念。传统Web产品中UI模块所占比例较大，这主要是因为其厚度较低。随着客户端代码比例的提升，大量业务逻辑也被转移到前端，进而催生了许多非界面模块的诞生。

分层设计的一大好处在于，每一层的责任都变得更加明确，因此，我们可以对它们进行单元测试，以此确保其质量。在传统的UI层测试中，最令人头疼的问题就是UI层与逻辑层相互交织，例如，经常会在远程请求的回调函数中修改DOM元素。而采用分层设计后，这些问题都可以被单独测试，随后再通过场景测试来确保整个流程的顺畅运行。

代码隔离

相较于开发传统的网页型网站，在构建单页应用的过程中，存在一些尤为关键的要点值得特别注意。

从单页应用的特点出发，这类应用相较于页面型网站，对JavaScript的依赖性更强。同时，由于页面实现单页化，各种子功能的JavaScript代码被集中至同一作用域之中。因此，确保代码的隔离性和模块化变得尤为关键。

在单页应用领域，页面模板的运用相当广泛。众多框架内置了各自的模板，而部分框架则需额外引入第三方模板。这些模板，作为界面组成部分，可以比作JavaScript模块，它们代表了组件的另一种形态。

模板同样需要隔离。若不进行隔离，将引发何种问题？模板之间的冲突主要集中在对id属性的争夺上。若某个模板内含有固定的id，在批量渲染过程中，便可能导致同一页面作用域内出现多个重合的id元素，进而引发难以预料的后果。鉴于此，我们在设计模板时应尽量避免使用id。若确实需要对DOM进行操作，应转而使用其他选择器来实现。在高度组件化的单页应用中，整个应用体系可能根本不涉及任何元素ID的运用。

代码合并与加载策略

人们对单页系统的加载速度接受度与Web页面有所差异，他们或许愿意对购物页面的加载等待长达3秒钟，但对于单页应用的首次启动，他们或许能够接受5至10秒的等待时间，然而在此之后，各项功能的操作应当保持顺畅，所有子功能页面应尽可能在1至2秒内完成切换，若不能达到这一速度，他们可能会觉得该系统运行缓慢。

观察这些特性，我们可将众多公共功能置于初始加载阶段，以此降低每次加载的数据量。部分网站甚至将全部界面与逻辑内容纳入首页加载范畴，在切换业务界面时，仅触发数据请求，故其响应速度极为迅速。以青云的控制台为例，便是如此操作。

在单页应用中，一般不需要像网站型产品那样，为了防止文件加载影响页面渲染，将JavaScript代码放置在HTML文档的尾部进行加载；这是因为单页应用的界面通常是通过动态生成的方式实现的。

在功能切换过程中，不仅会触发数据请求的生成，而且还需对界面进行刷新，所呈现的新界面组件通常是基于模板构建的，那么，这些模板又是从何而来呢？来源主要有两种途径，一种是通过AJAX技术即时获取数据，类似于请求数据的过程；另一种则是将所需内容嵌入到主界面特定位置，例如script标签或隐藏的textarea。后者在功能切换时能展现出更快的速度，但同时也增加了主页面的负担。

在传统的网页型网站上，各个页面之间彼此独立，故而若页面间有可共享的代码，通常会被独立成文件，并且可能需要根据每个页面的具体需求进行整合。而在单页应用中，若代码总量较小，则可一次性打包并在首页加载；若规模较大，则可在运行时进行加载，此时加载的粒度可以相对较大，且各个模块之间并无重复内容。

路由与状态的管理

最初我们接触到的这些网络应用程序中，部分实现了对网络路由的管控功能，而另一些则未涉及此方面。

管理路由的宗旨究竟在何处？其目的在于降低用户在导航过程中的开销。举例来说，我们设计了一个功能，该功能需经过多次导航菜单的点击才能显现。那么，当用户希望将这一功能的地址分享给他人时，他们又该如何操作呢？

传统页面式产品并未遭遇此类困扰，因其运作基于页面单元；而且，有时服务端路由已将所有问题解决。然而，在单页应用领域，这一问题显现出来，因为我们的应用仅包含一个页面，界面上的不同功能模块系动态构建而成。因此，我们必须通过有效管理路由，以实现这些功能。

具体操作是将产品功能细分为多个状态，并将每个状态与对应的路径进行关联，随后利用pushState等机制，对路径进行动态解析，确保其与功能界面保持一致。

安装了路由器后，我们的单页应用便能实现前后导航功能，仿佛在浏览多个页面之间一般。

实际上，在Web产品之外，管理路由的技术方案早已存在。比如在Adobe Flex中，它会把诸如TabNavigator这样的组件，甚至下拉框的选中状态，映射到URL上。这是因为Adobe Flex同样采用单“页面”的产品模式，因而也必须解决相同的问题。

产品一旦变得复杂到一定程度，路由的使用就会变得尤为困难，这是因为状态管理的难度极大。以我们最初演示的c9.io在线IDE为例，它就无法将状态信息映射到相应的URL上。

缓存与本地存储

在单页应用的运作机制中，缓存是一个很重要的环节。

这类系统的前端主要由静态文件构成，因此得以充分利用浏览器的缓存功能。同时，对于动态加载的界面模板，也可以实施自定义的缓存策略。在非首次访问时，系统可以直接从缓存中提取版本，从而有效提升加载效率。

甚至，有方案在动态引入JavaScript脚本时，还会将它们一同进行缓存处理。以Addy Osmani的basket.js为例，该脚本便运用了HTML5的localStorage功能，对JavaScript和CSS文件进行了缓存。

在单一页面的产品开发中，业务逻辑往往需要与本地数据存储进行交互，以保存临时信息。这时，我们可以利用localStorage或localStorageDB等工具来简化我们的业务代码编写过程。

服务端通信

在Web产品的传统应用中，通信多是通过JSONP或AJAX等手段与服务器端进行交互，然而，在单页Web应用领域，WebSocket这一实时通信手段则被广泛采纳。

WebSocket相较于传统依赖HTTP的通讯方式，展现出显著的优势。这种技术使得服务器端能够轻松实现数据的反向推送，而前端只需对实际产生的业务数据进行响应，从而避免了频繁且无谓的AJAX轮询操作。

WebSocket技术仅在某些较为先进的网络浏览器中得到支持，因此，为了确保不同浏览器间的兼容性，一些库函数被开发出来，例如socket.io。这些库能够在不支持WebSocket的浏览器环境中，自动将通信方式降级为AJAX或JSONP等，从而对业务代码的编写和运行保持透明，实现无缝兼容。

内存管理

在传统的Web页面设计中，通常无需过多关注内存管理问题，因为用户停留时间较短，即便出现内存泄漏，也往往能迅速通过刷新页面等方式得到解决。然而，对于单页应用而言，情况则截然不同，用户可能会持续使用一整天，这就要求我们在处理DOM操作、网络连接等方面要特别谨慎。

样式的规划

在单页应用里，由于页面之间高度集成，所有内容都集中在一个作用域内，因此，对样式的规划显得尤为关键。

样式规划主要是几个方面：

基准样式的分离

此部分内容涵盖了浏览器界面风格的调整、整体文字样式的设定、页面布局的基本规则以及适应不同屏幕尺寸的功能。

组件样式的划分

这里涉及两个维度的设计规划，首先是对各类界面组件及其子项的样式进行规范，其次是针对这些样式的修饰性调整。在组件样式的设计上，应尽量降低它们之间的相互依赖性，同时，各个组件的样式设计可以适当保留一定的冗余度。

堆叠次序的管理

传统Web页面拥有众多元素，然而其层次结构相对单一；与之相较，单页应用在这一点上有所区别。

在单页应用中，我们得预先为各类用户界面元素确定其堆叠顺序，即所谓的z-index值。例如，我们会遇到各种弹出式对话框和浮动层，它们可能以不同的组合方式堆叠。新出现的对话框的z-index值必须高于旧的有，这样才能确保其能够覆盖在上方。诸如此类的遮盖问题，我们都需要进行周密的规划。那么，如何进行这样的规划呢？

懂得通信原理的人理应知晓，各种频率范围被指定用于不同的通信手段。在部分国家，空中领域的使用也进行了明确划分。借鉴此方法，我们同样可以事先对频段进行划分，确保各类组件的z-index值各自处于相应区间，从而有效防止它们之间发生冲突。

单页应用的产品形态

起初我们便已指出，市面上涌现了大量新型Web产品，它们采用单页应用技术进行构建。然而，此类产品并非仅限于网络环境。浏览Chrome应用商店，便可发现众多离线应用，这些产品同样体现了单页应用的特点。

除了各类浏览器插件，通过运用node-webkit等封装框架，我们得以利用Web技术打造本地应用程序；在这些产品中，核心部分依然是大家所熟知的单页应用。

单页应用的普及度持续攀升，若您留意过一些新兴的互联网公司，不难发现它们的产品设计中，有很大比例采用了单页应用的形式。这种设计能够为用户带来丝滑的操作感受，但在开发过程中，对JavaScript的掌握程度要求相对较高。

在单页应用的开发流程中，前端与后端之间存在着固有的界限，它们通过API接口来划分各自的职责。前端扮演着服务接受者的角色，而后端则承担着服务供给者的职责。在这种架构下，前端的发展将促进后端服务化的进程。在不再负责模板渲染和页面输出的任务后，后端可以更加集中精力于API功能的实现；同时，随着Web前端和移动终端在地位上的对等，后端API也无需再针对每个终端进行单独的差异化设计。

部署模式的改变

在这个时代，我们目睹了一种新型产品的问世，它被称为“无后端”的Web应用。那么，这究竟是什么呢？依据这一观念，您的产品可能仅需自行构建静态网页，于特定BaaS（后端即服务）云端环境中定制化构建服务端API及云存储方案，并融入该平台所提供的软件开发工具包（SDK），通过AJAX等交互技术与其进行交互，从而实现用户注册认证、社交互动、消息推送、实时通讯以及云存储等多样化功能。

观察这种模式，我们可以发现前后端部署已完全独立，前端代码实现完全静态化，因此可存放在CDN上，访问速度将显著提升；同时，服务端部署于BaaS云平台，开发者无需再关注部署过程中的繁琐细节。

如果你是一位创业人士，你所从事的项目是一款支持实时协作的单页应用程序，该程序允许你于云端迅速构建后端功能，从而将大量珍贵的时间投入到产品的核心开发工作中。

单页应用的缺陷

单页应用存在一个核心不足，那就是它对搜索引擎优化并不友好，原因在于其界面的大部分内容都是动态构建的，这使得搜索引擎难以对其进行有效索引。

产品单页化带来的挑战

产品若追求单页化设计，首要条件便是其本身需与单页形态相契合。再者，在这一转化过程中，开发模式将面临一定的调整，同时对于开发人员的技术能力也有所提升的需求。

开发者在JavaScript方面的能力必须达标，并且应当对组件化以及设计模式有所了解，他所面临的已不再是单纯的网页，而是一个在浏览器中运行的桌面应用程序。

若是您身为一位高级研发工程师或以上级别的技术人员，且供职于互联网或软件行业，敬请添加微信账号dujiang1997，并在交流时告知您的姓名、职务、所属公司以及出示您的名片。我们届时将邀请您加入21CTO社区微信群。

关于21CTO

该平台位居中国互联网技术社交与学习领域的首位。它为首席技术官、技术总监、技术专家、架构师、技术经理、高级研发工程师以及项目经理等专业人士，提供了丰富的学习成长资源、教育培训服务、职业发展机会以及人脉影响力等极具价值的高质量在线教育和社会化平台。