开发网站怎样注册公司,专业搭建网站公司,2015年做网站行不行,设计属于什么行业单页应用是什么#xff1f;
让我们先来看几个网站#xff1a;
coding
teambition
cloud9
注意这几个网站的相同点#xff0c;那就是在浏览器中#xff0c;做了原先“应当”在客户端做的事情。它们的界面切换非常流畅#xff0c;响应很迅速#xff0c;跟传统的网页明…单页应用是什么
让我们先来看几个网站
coding
teambition
cloud9
注意这几个网站的相同点那就是在浏览器中做了原先“应当”在客户端做的事情。它们的界面切换非常流畅响应很迅速跟传统的网页明显不一样它们是什么呢这就是单页Web应用。
所谓单页应用指的是在一个页面上集成多种功能甚至整个系统就只有一个页面所有的业务功能都是它的子模块通过特定的方式挂接到主界面上。它是AJAX技术的进一步升华把AJAX的无刷新机制发挥到极致因此能造就与桌面程序媲美的流畅用户体验。
其实单页应用我们并不陌生很多人写过ExtJS的项目用它实现的系统很天然的就已经是单页的了也有人用jQuery或者其他框架实现过类似的东西。用各种JS框架甚至不用框架都是可以实现单页应用的它只是一种理念。有些框架适用于开发这种系统如果使用它们可以得到很多便利。
开发框架
ExtJS可以称为第一代单页应用框架的典型它封装了各种UI组件用户主要使用JavaScript来完成整个前端部分甚至包括布局。随着功能逐渐增加ExtJS的体积也逐渐增大即使用于内部系统的开发有时候也显得笨重了更不用说开发以上这类运行在互联网上的系统。
jQuery由于偏重DOM操作它的插件体系又比较松散所以比ExtJS这个体系更适合开发在公网运行的单页系统整个解决方案会相对比较轻量、灵活。
但由于jQuery主要面向上层操作它对代码的组织是缺乏约束的。如何在代码急剧膨胀的情况下控制每个模块的内聚性并且适当在模块之间产生数据传递与共享就成为了一种有挑战的事情。
为了解决单页应用规模增大时候的代码逻辑问题出现了不少MV*框架他们的基本思路都是在JS层创建模块分层和通信机制。有的是MVC有的是MVP有的是MVVM而且它们几乎都在这些模式上产生了变异以适应前端开发的特点。
这类框架包括BackboneKnockoutAngularJSAvalon等。
组件化
这些在前端做分层的框架推动了代码的组件化所谓组件化在传统的Web产品中更多的指UI组件但其实组件是一个广泛概念传统Web产品中UI组件占比高的原因是它的厚度不足随着客户端代码比例的增加相当一部分的业务逻辑也前端化由此催生了很多非界面型组件的出现。
分层带来的一个优势是每层的职责更专一了由此可以对其作单元测试的覆盖以保证其质量。传统UI层测试最头疼的问题是UI层和逻辑混杂在一起比如往往会在远程请求的回调中更改DOM当引入分层之后这些东西都可以分别被测试然后再通过场景测试来保证整体流程。
代码隔离
与开发传统页面型网站相比实现单页应用的过程中有一些比较值得特别关注的点。
从单页应用的特点来看它比页面型网站更加依赖于JavaScript而由于页面的单页化各种子功能的JavaScript代码聚集到了同一个作用域所以代码的隔离、模块化变得很重要。
在单页应用中页面模板的使用是很普遍的。很多框架内置了特定的模板也有的框架需要引入第三方的模板。这种模板是界面片段我们可以把它们类比成JavaScript模块它们是另一种类型的组件。
模板也一样有隔离的需要。不隔离模板会造成什么问题呢模板间的冲突主要存在于id属性上如果一个模板中包含固定的id当它被批量渲染的时候会造成同一个页面的作用域中出现多个相同id的元素产生不可预测的后果。因此我们需要在模板中避免使用id如果有对DOM的访问需求应当通过其他选择器来完成。如果一个单页应用的组件化程度非常高很可能整个应用中都没有元素id的使用。
代码合并与加载策略
人们对于单页系统的加载时间容忍度与Web页面不同如果说他们愿意为购物页面的加载等待3秒有可能会愿意为单页应用的首次加载等待5-10秒但在此之后各种功能的使用应当都比较流畅所有子功能页面尽量要在1-2秒时间内切换成功否则他们就会感觉这个系统很慢。
从这些特点来看我们可以把更多的公共功能放到首次加载以减小每次加载的载入量有一些站点甚至把所有的界面和逻辑全部放到首页加载每次业务界面切换的时候只产生数据请求因此它的响应是非常迅速的比如青云的控制台就是这么做的。
通常在单页应用中无需像网站型产品一样为了防止文件加载阻塞渲染把js放到html后面加载因为它的界面基本都是动态生成的。
当切换功能的时候除了产生数据请求还需要渲染界面这个新渲染的界面部件一般是界面模板它从哪里来呢来源无非是两种一种是即时请求像请求数据那样通过AJAX获取过来另一种是内置于主界面的某些位置比如script标签或者不可见的textarea中后者在切换功能的时候速度有优势但是加重了主页面的负担。
在传统的页面型网站中页面之间是互相隔离的因此如果在页面间存在可复用的代码一般是提取成单独的文件并且可能会需要按照每个页面的需求去进行合并。单页应用中如果总的代码量不大可以整体打包一次在首页载入如果大到一定规模再作运行时加载加载的粒度可以搞得比较大不同的块之间没有重复部分。
路由与状态的管理
我们最开始看到的几个在线应用有的是对路由作了管理的有的没有。
管理路由的目的是什么呢是为了能减少用户的导航成本。比如说我们有一个功能经历过多次导航菜单的点击才呈现出来。如果用户想要把这个功能地址分享给别人他怎么才能做到呢
传统的页面型产品是不存在这个问题的因为它就是以页面为单位的也有的时候服务端路由处理了这一切。但是在单页应用中这成为了问题因为我们只有一个页面界面上的各种功能区块是动态生成的。所以我们要通过对路由的管理来实现这样的功能。
具体的做法就是把产品功能划分为若干状态每个状态映射到相应的路由然后通过pushState这样的机制动态解析路由使之与功能界面匹配。
有了路由之后我们的单页面产品就可以前进后退就像是在不同页面之间一样。
其实在Web产品之外早就有了管理路由的技术方案Adobe Flex中就会把比如TabNavigator甚至下拉框的选中状态对应到url上因为它也是单“页面”的产品模式需要面对同样的问题。
当产品状态复杂到一定程度的时候路由又变得很难应用了因为状态的管理极其麻烦比如开始的时候我们演示的c9.io在线IDE它就没法把状态对应到url上。
缓存与本地存储
在单页应用的运作机制中缓存是一个很重要的环节。
由于这类系统的前端部分几乎全是静态文件所以它能够有机会利用浏览器的缓存机制而比如动态加载的界面模板也完全可以做一些自定义的缓存机制在非首次的请求中直接取缓存的版本以加快加载速度。
甚至也出现了一些方案在动态加载JavaScript代码的同时把它们也缓存起来。比如Addy Osmani的这个basket.js就利用了HTML5 localStorage作了js和css文件的缓存。
在单页产品中业务代码也常常会需要跟本地存储打交道存储一些临时数据可以使用localStorage或者localStorageDB来简化自己的业务代码。
服务端通信
传统的Web产品通常使用JSONP或者AJAX这样的方式与服务端通信但在单页Web应用中有很大一部分采用WebSocket这样的实时通讯方式。
WebSocket与传统基于HTTP的通信机制相比有很大的优势。它可以让服务端很便利地使用反向推送前端只响应确实产生业务数据的事件减少一遍又一遍无意义的AJAX轮询。
由于WebSocket只在比较先进的浏览器上被支持有一些库提供了在不同浏览器中的兼容方案比如socket.io它在不支持WebSocket的浏览器上会降级成使用AJAX或JSONP等方式对业务代码完全透明、兼容。
内存管理
传统的Web页面一般是不需要考虑内存的管理的因为用户的停留时间相对少即使出现内存泄漏可能很快就被刷新页面之类的操作冲掉了但单页应用是不同的它的用户很可能会把它开一整天因此我们需要对其中的DOM操作、网络连接等部分格外小心。
样式的规划
在单页应用中因为页面的集成度高所有页面聚集到同一作用域样式的规划也变得重要了。
样式规划主要是几个方面
基准样式的分离
这里面主要包括浏览器样式的重设、全局字体的设置、布局的基本约定和响应式支持。
组件样式的划分
这里面是两个层面的规划首先是各种界面组件及其子元素的样式其次是一些修饰样式。组件样式应当尽量减少互相依赖各组件的样式允许冗余。
堆叠次序的管理
传统Web页面的特点是元素多但是层次少单页应用会有些不同。
在单页应用中需要提前为各种UI组件规划堆叠次序也就是z-index比如说我们可能会有各种弹出对话框浮动层它们可能组合成各种堆叠状态。新的对话框的z-index需要比旧的高才能确保盖在它上面。诸如此类都需要我们对这些可能的遮盖作规划那么怎样去规划呢
了解通信知识的人应当会知道不同的频率段被划分给不同的通信方式使用在一些国家领空的使用也是有划分的我们也可以用同样的方式来预先分段不同类型的组件的z-index落到各自的区间以避免它们的冲突。
单页应用的产品形态
我们在开始的时候提到存在着很多新型Web产品使用单页应用的方式构建但实际上这类产品不仅仅存在于Web上。点开Chrome商店我们会发现很多离线应用这些产品都可以算是单页应用的体现。
除了各种浏览器插件借助node-webkit这样的外壳平台我们可以使用Web技术来构建本地应用产品的主要部分仍然是我们熟悉的单页应用。
单页应用的流行程度正在逐渐增加大家如果关注了一些初创型互联网企业会发现其中很大一部分的产品模式是单页化的。这种模式能带给用户流畅的体验在开发阶段对JavaScript技能水平要求较高。
单页应用开发过程中前后端是天然分离的双方以API为分界。前端作为服务的消费者后端作为服务的提供者。在此模式下前端将会推动后端的服务化。当后端不再承担模板渲染、输出页面这样工作的情况下它可以更专注于所提供的API的实现而在这样的情况下Web前端与各种移动终端的地位对等也逐渐使得后端API不必再为每个端作差异化设计了。
部署模式的改变
在现在这个时代我们已经可以看到一种产品的出现了那就是“无后端”的Web应用。这是一种什么东西呢基于这种理念你的产品很可能只需要自己编写静态Web页面在某种BaaSBackend as a Service云平台上定制服务端API和云存储集成这个平台提供的SDK通过AJAX等方式与之打交道实现注册认证、社交、消息推送、实时通信、云存储等功能。
我们观察一下这种模式会发现前后端的部署已经完全分离了前端代码完全静态化这意味着可以把它们放置到CDN上访问将大大地加速而服务端托管在BaaS云上开发者也不必去关注一些部署方面的繁琐细节。
假设你是一名创业者正在做的是一种实时协同的单页产品可以在云平台上快速定制后端服务把绝大部分宝贵的时间花在开发产品本身上。
单页应用的缺陷
单页应用最根本的缺陷就是不利于SEO因为界面的绝大部分都是动态生成的所以搜索引擎很不容易索引它。
产品单页化带来的挑战
一个产品想要单页化首先是它必须适合单页的形态。其次在这个过程中对开发模式会产生一些变更对开发技能也会有一些要求。
开发者的JavaScript技能必须过关同时需要对组件化、设计模式有所认识他所面对的不再是一个简单的页面而是一个运行在浏览器环境中的桌面软件。
