有 网友 提到 ：
“复杂的页面，一个页面加载的模块多，各种异步请求，页面渲染，jquery链式编程操作dom数过于频繁。现在的前台越来越复杂，逻辑臃肿。”
哎， 所以 我说， 要改成用 同步调用 。
什么是 同步调用， 就是 后端代码 里 调用 数据库 那样 。
如若不然， 还沉浸 在 “回调” 带来的 光辉的技术感 里的 话， 回调地狱 无法解决 。
现在 大家 都 以 “回调” 为荣， 以 “异步” 为荣， 以此 为 潮流， 以此 为 高效， 以此 为 进步， 以此 为 先进 。
这是 错误 的 。
前端 Js 里采用 AJAX 异步回调 的 方式 是 被迫 的， 事实上 当年 前端 Js 开发人员 很羡慕 其它语言 比如 Java C# 这样 可以 同步调用数据库 。
而 Js 没有这个能力 。
这大概是因为 Javascript 是 单线程 模型 吧 ！ 不能 Sleep() ， 也不能 Wait() 。
我强调一点， 程序员 要对 程序 有 控制感 。
太多的 回调 把 程序 切割 的 支离破碎， 这样的 代码 是 病态 的 代码 。
当然大家可能会说 “异步回调 提升了效率 …… 某某框架 是 回调 的 架构， 所以 速度 如何如何 的快， 可以支持 多大多大 的 并发量 ……”，
对此 我不想多说， 我今天在 QQ 群 里说了很多 。
总之， 且 不论 “异步回调” 是否 真的 提升了 效率， 我想引用 大家经常 引用的 一句话 “代码是写给人看的”，
还有 一句话 是 “能用硬件解决的事不要让软件来解决”，
还有一句话 是 “硬件是最廉价的”，
说了 那么多效率， 有没考虑一下 “代码是写给人看的” 好伐 ？！
而且 异步回调 是否真的能带来 效率 提升 这个 还 值得怀疑， 我只是觉得， 把 架构 搞得 很复杂， 效率 肯定 好不到哪去 。
关于 异步回调 是否能 提升性能， 可以参考 《后线程时代 的 应用程序 架构》 https://www.cnblogs.com/KSongKing/p/10228842.html
不过 Js 现在 学 C# ， 搞了个 await 关键字， 看起来能实现一个 “伪同步”， 至少 代码 不再是 异步回调， 是 顺序 的 。
还行， 这问题就先过了吧 。
接下来要说 第二个问题， 就是 页面 模型， 或者说 页面开发架构， 或者说 页面控件模型， 或者说 页面控件架构 。
业界 已经被 各种 “前端框架” 荼毒多年 。
前端界 已经被 各种 “前端框架” 荼毒多年 。
这是 现实， 也是 事实 。
可以看看我写的 jlet https://www.cnblogs.com/KSongKing/p/9455238.html，
jlet 是一个 简单 的 前端 Js 库， 重要的是 提出了 “库” 的 思想， 为 前端架构 指出了一个 方向 。
我不赞同 MVVM ， MVVM 同样是一种 过度封装 的 思想，
我认为 好的做法是， 提供 一个一个 封装 好的 控件， 用 代码 调用 控件 的 属性 和 方法 。
不要 用 各种 “UI 框架” 来 绑架 开发方式，
也 不要 用 MVVM 等方式 把 控制逻辑 绑架 到 控件 里，
程序 就是 程序，
程序员 应该 对 程序 有 控制感，
过度 的 控制反转 会 使 程序员 极大 的 丧失 对 程序 的 控制感 。
少搞框架， 少搞声明式 。
jQuery 和 一些 前端框架 会用 “声明式” 的 方式 来 做 用户输入校验， 比如 通过 Html 标签 或者 控件 的 属性 来 声明 这个 控件（如文本框） 要 作 什么样的 输入校验（如 数字格式、日期格式） ， 然后 在 点击按钮 或者 Form 提交 的 时候， 由 框架 统一校验 。
这种方式， 看起来 高端， 维护的时候 蛋疼 。
好的方式 应该是， 提供一些 Util 方法， 如 Util.CheckNumber(), Util.CheckDate() ，
然后 在 按钮点击 事件函数 里 直接写 if 代码判断， 如：
if ( ! Util.CheckNumber( …… ))
{
Util.Alert("xx 应 输入 数字 。");
return;
}
这种做法， 看起来代码多了， 但 简单直接， 清楚明了， 尤其 有利于 维护 。
我在 《Web-Business-Application-Solution》 https://www.cnblogs.com/KSongKing/p/9455047.html 中 提出过：
“
少搞一点 封装， 少搞一点 控制反转（Ioc）， 少搞一点 AOP， 少搞一些 “声明式”。
不要隐藏太多代码，让 代码 回归 代码。
是 找回 80 年代 写 Basic 的 那种感觉 的 时候了。 ^ ^
”