jQuery 流行的年代，是如何做后台管理系统的页面切换功能的？

[manyfreebug]

jQuery 流行的年代，是如何做后台管理系统的页面切换功能的？

看了一些以前的“左侧侧边栏、右侧内容区域的结构”的项目，似乎有 3 种途径：

1 、借助 iframe
    事件监听左侧侧边栏的菜单，当用户点击某个菜单项时，获取它的 href 属性值，并且将它赋值给右边内容区域的 iframe 元素的 src 属性，这样就可以实现内容页面的切换。
    
2 、借助 Ajax
	监听左侧侧边栏的点击事件，当用户点击某个菜单项时，使用 ajax 请求对应的内容页面，并将返回的数据替换右边内容区域的容器中
    
3 、不借助 js
    直接把侧边栏的菜单写在每一个 html 页面里，如果需要菜单高亮，在每个 html 页面对应的菜单里添加.active 等

这三种方式在点击菜单时，都会网络请求对应的 html 页面，而现在的 vue 、react 等框架，是不需要的。

有网络请求的情况下切换页面时观感上会没那么快，一般会用哪些手段提升体验。

[anguiao]

依稀记得有 pjax 这个东西，不过没有仔细了解过，出来干活的时候已经是 React 、Vue 的时代了。

[alphat]

a href

[manyfreebug]

@alphat 这个属于上面说的第三类：不借助 js ，把菜单写在每一个 html 页面里。

[codehz]

以前的前端开发 ide 如 frontpage 就有提供类似功能，把一个页面的一部分定义为公共组件，一改就一起改不确定底层方案是怎么实现的，我猜可能是同时修改多个文件（

[ql562482472]

服务端渲染（ JSP/freemarker ），还有改写 DOM （ jquery 重新写 Dom 内容）

[skylinewd]

页面跳转加菜单高亮

[neutrino]

就 iframe 好，其他的切来切去有点问题

[kop1989smurf]

做单页面应用，切换的时候只是对应 div 的 show 与 hide 。
当然，代价就是会有 js 变量与类名的全局冲突。

[tairan2006]

单页面的话就 bootstrap + backbone

[815979670]

用 Jquery 的时候 很多项目都是后端混编的 MVC 项目，视图层和现在的前端一样也有继承等各种操作。
之前 MVC 时代，我做的是 PHP 开发，会把菜单部分单独抽出来做一个视图，然后由 layout 视图引入，在菜单视图中就可以实现根据请求的 URL 地址选中不同的菜单

[onice]

2017 年，我实习的时候，就是用的 Jquery 。当时是用的： https://jqueryui.com/

[brust]

iframe

[flyqie]

主要是 1 和 3 。

2 的话有些时候可能会出问题(隔离度不够)，所以用的很少。

[mingl0280]

我以前干

[mingl0280]

我以前给某学校的 IT 打工的时候，他们校内的一些 jq 的系统是直接后端生成一段 html 然后返回给 jq ，jq 直接拿到以后替换掉显示页面内容的节点……

[xbleey]

我现在做的这个项目用的就是 iframe

[roundgis]

Dojo 那時候已經支持組件了

[wellerman]

"有网络请求的情况下切换页面时观感上会没那么快，一般会用哪些手段提升体验。" 快不快不能用感觉，要用 waterfall 的数据来对比。对于后台管理这种没有什么并发量的系统来说，同样的业务，用 react 等现代框架实现一般都慢于用 jQuery 经典技术实现。数据渲染，中间计算的代码越多就会越慢。所以现代框架通常都会有转场动画，让人产生一个流畅的错觉。比如用 jQuery + PHP 实现的管理后台 dcatadmin ，目前还没发现用 React/Vue + PHP/Java 的管理后台能比 dcatadmin 快的。

[DOLLOR]

我参与过的有两种方法。
一种就是 iframe 。
还有一种是后端渲染，拼接 html 里公共部分和各自部分。

[ljrdxs]

后端模板可以拆出共同部分。
其他页面引用它。

[ljrdxs]

“这三种方式在点击菜单时，都会网络请求对应的 html 页面，而现在的 vue 、react 等框架，是不需要的。”
首屏速度慢

[lawler]

老古董来回答一下这个问题。

最早是 1 ，之后是 2 。3 在这个过程中一直被当作辅助方式使用，除非是纯静态页面。
1 的时候，叫做，iframe 嵌入。2 的时候，叫做，无刷新请求或动态刷新。3 是辅助方式，没有具体实现名称。

至于现在前端工程化，只不过是基于方式 2 的延申，并没有革命性的提升。
2 在后期，因为 resf 的流行，多数已经是纯接口操作了，前端根据接口返回动态生成 dom 。除此之外，几乎所有大型项目都封装有统一 dom 组件。与现在的 vue/react 的 template 别无二致。

要说差异，最大的还是细节。现在前端没有细节可言，任何识字的人，在了解基本的 html 知识后都可以照着文档写一个页面出来。而古早的项目，细节到任何一行代码都在产生价值。

[wdssmq]

@lawler 前不久发现 eyoucms 还在用 1 ，后台刷新后需要重新进文章编辑，，虽然可以把相应 iframe 直接打开。。

[Jonney]

用 pjax ，我现在还在用

[Jonney]

我一直认为服务器端渲染才是正道，速度快得一批。客户端渲染是歧途，速度慢得要死。

[lower]

提升体验的话，
感觉就是大量用 Ajax 搞局部刷新：
服务端 mvc 基本就只是做路由，返回一个基本 html 和一堆 js ，js 在客户端加载执行后慢慢拉数据渲染页面😂

[otakustay]

路由有 Backbone 这一类，组件库可以用 ExtJS 重量级，基本和现在区别也不大，只是视图不是声明式的而已

[zjsxwc]

直接 WordPress 、Drupal 做后台。

[cheng6563]

老办法普遍用 iframe 做子页面。不然共享脚本 ID 什么的很容易造成冲突。

[Xusually]

用得最多的就是 1 ，各种流行的 cms 都在用。

[zpf124]

14 、15 年刚开始开发，用的大部分都是
3-服务端渲染完整页面 + 2 - 具体内容页面包含分页情况，或者 tab 切换情况。

iframe 也会使用但一般用的不太多，因为不方便 js 控制元素交互。


后端会存在三个部分 head.jsp , footer.jsp, 以及每个独立内容页。每个内容页有一个 include 指令标签，把 head 和 footer 引入到这个页， 然后后端服务器根据这个指令在实际输出时将三个页面内容合成为一个完整的页面，每次请求都是收到的完整的 html 。

左侧菜单的功能也是如此，就是在上面的基础上多引入一个 left 或者 menu 的页面。

（我记得 nodejs 项目也有类似的功能，在输出静态化页面的时候，就和后端这个做法基本一致，只不过后端这种渲染还允许页面包含变量，当用户请求时再获取数据填充）。

;
然后有些内容页是 head + left + right 的结构，head 部分内容每次访问都需要后端计算获取数据，所以为了这部分页面的性能，right 内容页如果包含分页，那就是用的 ajax 的局部加载技术。jq 有个$.load()方法，可以直接读取后端一个 html 并覆盖到某个容器内，当然也可以用 ajax 获取 json 数据，然后用 foreach 根据 json 数组操作 dom 生成对应元素，这种写法就是对于当时刚火起来的前端渲染的实验了。

[Adelell]

老前端告诉你，最简单的办法是在 index.html 里面写所有右侧内容页面，全部设置 display: none 用 js 根据用户点击控制显示哪一个。上千行的 html 随处可见，除了作者谁都不敢碰。好处是保住了饭碗，坏处是自己维护也累。

[Adelell]

当然，数据是要通过 ajax 从后端 api 拿。

[ETiV]

零几年那会儿搞过 WordPress 、discuz 、vbb ，印象中都是 iframe+后端套模板出内容，ajax 太太太少见了，得是 201 几年后的事儿了

（想到个前不久 Twitter 上看到的段子：PHP 是最早的 serverless 方案，真就是传个文件到 PHP 空间上就能运行了😂）

[leonlu]

可以用路由模式？可以看一下 react router 底层依赖 hisotry 这个 npm 包。点击导航栏触发路由变更，主内容监听路由变化，再做渲染。

主内容的渲染可以是 1. js 加 data ，也就是 spa 模式，也是 react/vue 采用的模式。2. pjax ，后端渲染好 html 直接 innerHtml 一把梭。3. iframe 。 各有优劣，看楼主你的需求了。

[lff0305]

基本上是 3 ，当年不同的浏览器想用 1/2 麻烦死，各种莫名其妙的问题或者限制，尤其是那个 IE6

[echoless]

@mingl0280 htmx 哈哈

[wangxiaoaer]

大体上是第 3 种，也就是后端渲染。后端渲染也是有框架，模版的，不会傻乎乎每个页面复制粘贴重复内容。

[lxrmido]

这已经变成需要考古的问题了吗……还有这几种的：
1 、前端模板引擎（其实就是 2 ）；
2 、配合 nginx 的 shtml 做 virtual include ；
3 、后端模板 include ；

[qiaobeier]

iframe ， 所谓 pjax 只是覆写 dom ，数据事件等等都需要手动再次绑定，和现代框架不是一个概念的东西。

[libook]

jQuery 和现代框架的共同点都是降低开发者操作 DOM 的复杂度，区别在于 jQuery 是让开发者直接操作 DOM ，而现代框架是给开发者一套设计模式，让开发者只需要提供抽象的业务流程和数据流，框架会自动操作 DOM 。也就是说在 jQuery 流行的年代，用 jQuery 开发一个现代风格的网站是基本可行的，只不过部分特性可能需要写更多的代码。

jQuery 流行的时代和现在的需求是有很多区别的：
1. 过去网速普遍慢，2G 网络很多设备才几十 K 的速度，很多地区宽带能到 4Mbit 已经算是比较好的了。jQuery 在 2010 年的时候只有 78KB ，现在单个 JS 文件资源动辄 1M 左右的大小如果到了那个时代会严重拖慢首屏加载时间。所以按需加载+加载动画比单页面 All-in-One 更受欢迎，甚至当时开发者会主动删除依赖库中不需要的代码，以及在字体文件中删除页面上不涉及的字。现在网络快和便宜到可以随时刷短视频和直播了，以前的那些需求自然就不存在了。
2. 过去设备性能普遍较差，所以会尽量避免前端渲染，除了采用后端渲染以外，还流行预渲染，除了必要的交互动画以外，会将数据和页面框架结合渲染成静态的 HTML ，拿空间换计算量。现在设备性能强到前端渲染甚至快于网络请求方案了，而且网站运营方也可以利用前端渲染来节省服务器开销。
3. 过去 Web1.0 时代的目标主要是信息的呈现，现在 Web2.0 时代的目标主要是交互体验，所以现在交互功能更重，单页面应用在这方面的优势更大。

[caiqichang]

postmessage onmessage 封装一个页面间消息传递的工具

[harrozze]

2007 年开发过一个 Google Reader （ RSS 订阅，早就不在了）的复刻版，抄它的界面风格，用的是 2+3 那种方法。除了 jquery 之外，纯手写 html/css/js……iframe 嵌入实在更早之前用的比较广泛，因为没有 AJAX 这东西，想做左右分栏的话，要么用 frameset ，要么 iframe 。

后面说的提升体验的方法通常是用预加载+缓存（列表页），或用摘要 /分页预加载（详情页），看自己怎么控制页面缓存的内存占用了。