### 后台前端项目的开发
>[danger] 从后台前端项目的演变过程看单页的发展
我们先看最基本的网页页面工作模式
点击链接跳转新页面
每次都会重新请求一个文档,再次渲染
基本98%的网页是属于这种形式的
这种现状让人有很多不满
1. 网络差的时候点击链接,加载新页面慢,甚至出现卡住,白屏的情况
2. 浪费不必要的带宽,大部分页面都有公用部分,头部,导航栏,菜单栏,尾部都是相同的,每次重新渲染一次让人感觉浪费,不值得,尤其让有偏执狂,强迫症,处女座,完美主义者的人抓狂受不了。
所以我们好改变!
但是改变是痛苦的
会有所割舍,和负面的东西
[PJAX](https://my.oschina.net/sub/blog/123447)是我们做出改变的第一步
但不可避免的会有一些问题
比如对于SEO不友好,关于这点,什么网站适合使用单页类技术,什么网站还是以传统的方式比较好,已经讨论过了[前端技术选型分析](http://www.kancloud.cn/xiak/quanduan/280137),这里就不讨论了。
讨论的结果是,大部分常规网站不适合向单页靠拢,而webapp类型的适合
好了,不扯远了。
回到我们的后台前端项目
后台页面的特点是主要是功能性操作,数据的管理的
所以不太注重页面灵活,外观,并且是内部使用的,所以也不需要SEO
基于这些原因,其实很早就有人在后台项目中使用过类WEBAPP技术了,对,你没听错,在webapp概念还没诞生时,人们就在后台项目中尝试过类似的开发方式了。
因为人们很早就注意到,后台结构往往都不叫简单,都差不多
顶部
左侧导航/菜单栏
右侧内容区
工作的方式:顶部和左侧的内容一般在使用过程中都不会变,操作一般都在内容区
你想到了什么?
没错就是框架
```
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<title>title</title>
<link rel="icon" href="/v1/images/ico.ico" type="image/x-icon" />
<style></style>
</head>
<frameset id="bg" style="background:url(/v1/images/ad_bg.jpg)" rows="65,*" scrolling="yes" norsesize="nosesize" marginwidth="0" marginheight="20px" frameborder="0">
<frame src="/v1/can/index.php?a=top" scrolling="yes" norsesize="nosesize" marginwidth="0" marginheight="20px" frameborder="0" name="top" />
<frameset cols="210,*" scrolling="yes" norsesize="nosesize" marginwidth="0" marginheight="0" frameborder="0">
<frame src="/v1/can/index.php?a=z" scrolling="yes" norsesize="nosesize" marginwidth="0" marginheight="0" frameborder="0" name="z" />
<frame name="iframe_a" src="/v1/can/index.php?a=d" scrolling="yes" norsesize="nosesize" marginwidth="0" marginheight="0" frameborder="0" />
</frameset>
</frameset>
<noframes></noframes>
</html>
```
这是一个基本,经典的后台页面结构
无刷新,操作页面,顶部,左侧不需要每次渲染,点击不同的功能菜单,内容区加载页面,这不就是"单页"吗。
这还比较简陋,没有url的状态管理,毕竟那时候还没有HTML5嘛,现在看起来,这种方法虽然比较拙劣,但也是前进路上的一次尝试,一次突破,而这种突破尝试,最早就是在后台项目中出现的,所以这篇文章开头就说到**“从后台项目看单页的演变”**。
这种使用内联框架的形式后来出现很多演变,比如只使用一个框架做内容区域,甚至模拟多选项卡,比如H+等等,但技术都是相同,那就是使用框架。
但这种方式毛病也多,比如使用框架不够灵活,多框架是管理复杂,容易出错,尤其是在前端发展如此之快,单页技术成熟的今天,就更久过时了,现在完全可以不使用框架了,比如 [zui](http://zui.sexy/) [vuethink](http://vuethink.com/)等新型框架,这些技术完全可以在后台项目中完全的应用,无所忌惮,无所顾虑的,大胆的应用,因为没有什么坏处了,后台项目只要灵活,不需要考虑SEO了。
**使用这些新型框架来开发后台前端项目,将大大提升开发和使用效率,不会再多获取不必要的东西了,浪费了,这也满足了有偏执狂,强迫症,处女座,完美主义者的人了。**
这种方式开发、维护的复杂度都会大大降低,单页对开发人员的要求更高,因为整个单页就是个webapp,各种组件组成的,而这种其实每个页面都是独立分离的,所以复杂度就达达降低了。
虽然还有很长的路要走,但我相信,只要不断超越自己,改变自己,相信改变是件美好的事,未来就会更好。
[美团外卖前端可视化界面组装平台 —— 乐高](https://tech.meituan.com/waimai-lego.html)
[Bootstrap可视化布局系统](http://www.bootcss.com/p/layoutit/#)
> 可以先用布局把界面搭建起来
* * * * *
update time: 2018-5-17 17:26:41
- 开始
- 微信小程序
- 获取用户信息
- 记录
- HTML
- HTML5
- 文档根节点
- 你真的了解script标签吗?
- 文档结构
- 已经落后的技术
- form表单
- html实体
- CSS
- css优先级 & 设计模式
- 如何编写高效的 CSS 选择符
- 笔记
- 小计
- flex布局
- 细节体验
- Flex
- Grid
- tailwindcss
- JavaScript
- javascript物语
- js函数定义
- js中的数组对象
- js的json解析
- js中数组的操作
- js事件冒泡
- js中的判断
- js语句声明会提前
- cookie操作
- 关于javascript你要知道的
- 关于innerHTML的试验
- js引擎与GUI引擎是互斥的
- 如何安全的修改对象
- 当渲染引擎遇上强迫症
- 不要使用连相等
- 修改数组-对象
- 算法-函数
- 事件探析
- 事件循环
- js事件循环中的上下文和作用域的经典问题
- Promise
- 最佳实践
- 页面遮罩加载效果
- 网站静态文件之思考
- 图片加载问题
- 路由及转场解决方案
- web app
- 写一个页面路由转场的管理工具
- 谈编程
- 技术/思想的斗争
- 前端技术选型分析
- 我想放点html模板代码
- 开发自适应网页
- 后台前端项目的开发
- 网站PC版和移动版的模板方案
- 前后端分离
- 淘宝前后端分离
- 前后端分离的思考与实践(一)
- 前后端分离的思考与实践(二)
- 前后端分离的思考与实践(三)
- 前后端分离的思考与实践(四)
- 前后端分离的思考与实践(五)
- 前后端分离的思考与实践(六)
- 动画
- 开发小技巧
- Axios
- 屏幕适配
- 理论基础
- 思考
- flexible.js原理
- 实验
- rem的坑,为什么要设置成百分比,为什么又是62.5%
- 为什么以一个标准适配的,其它宽度也能同等适配
- 自适应、响应式、弹性布局、屏幕适配
- 适配:都用百分比?
- 番外篇
- 给你看看0.5px长什么样?
- 用事实证明viewport scale缩放不会改变rem元素的大小
- 为什么PC端页面缩放不会影响rem元素
- 究竟以哪个为设备独立像素
- PC到移动端初试
- 深入理解px
- 响应式之栅格系统
- 深入理解px(二)
- 一篇搞定移动端适配
- flex版栅格布局
- 其他
- 浏览器加载初探
- 警惕你的开发工具
- JS模块化
- webpack
- 打包原理
- 异步加载
- gulp
- 命名规范
- 接口开发
- sea.js学习
- require.js学习
- react学习
- react笔记
- vue学习
- vue3
- 工具、技巧
- 临时笔记
- 怎么维护好开源项目
- 待办
- 对前端MVV*C框架的思考
- jquery问题
- 临时
- 好文
- 节流防抖