前后端分离，前端一定要用 NVVM 之类的,比如 vue/react 东西吗？

[youcanwin8099]

做 web 后台管理程序(CRM 之类的），用 jquery+bootstrap 能否一样做到前后端分离？

就是不让后台的 java 接口来输出 html+jquery+bootstrap,而是前端 html+jquery+bootstrap+css 读取后台 java 接口。

有这种类型的、比较典型的、也比较流行的框架吗？

纠正下：1) 一定要用 MVVVM 吗？ 2)是做 OA+工作流。

[onfuns]

前后端分离意思就是前端干前端的活，后端干后端的活，调接口时才会交集。至于前端你想要什么技术栈就用什么技术栈，不想用三大框架，用 js api 自己一点一点敲没人管，关键要是工作上就得考虑技术栈了，工作是要提高效率的，怎么快就要怎么来！

[alertZ]

我以前做前后端分离是使用 ng 来做，后面就从简直接使用 JQ 的 ajax 来实现接口调用，然后在配合 webpack 降低文件大小和提高代码复用率

[youcanwin8099]

@onfuns 用 js api 就一定会一点一点敲，从而比三大框架效率低吗？那 jquery+bootstrap 听上去也很有名啊！

[youcanwin8099]

@alertZ 什么是 ng ？ node js?

[kaiki]

试试 art-template ？

[alertZ]

@youcanwin8099 ng:angular 。与 vue 和 react 同名的另外一个框架。

[youcanwin8099]

@alertZ ,你后面”后面就从简直接使用 JQ 的 ajax 来实现接口调用“，那是否已经不用 angular 呢？如果不用，怎么还要搞什么 webpack?

[aogu555]

不是的，之前接手过一个老的 jq 项目，前端部分用基于 jq 的 layui，ajax 请求到数据后主要依赖模板引擎来渲染数据，虽然是前后端分离，但是个人认为效率是远不如现在的 vue/react 高的，生态方面也完全比不上，大人，时代变了。

[NotFamous]

前后端分离跟用什么技术栈没关系的, 在前端来说就是写好 HTML/CSS/JS, 后端写好接口(用来返回数据), 然后前端要展示数据或者执行操作的时候就调用接口用来获取数据或者执行操作.
相应地, 举个我们公司.Net 的例子~前后端不分离的就是那种后端返回一个 View(页面文件是 cshtml )的吧,,,纯粹只是一种例子, 毕竟我对后端不熟悉

[gz911122]

不一定要用 vue 之类的, 你想用啥用啥...

前后端分离只是从返回 html 变成了通过 api 交互而已

[agdhole]

是的，jQuery 效率会低一万倍

[GDC]

@youcanwin8099 webpack 和 angularjs 都是可以单独使用，或者搭配其它使用的，并不是缺了 angular 就用不了 webpack

[onfuns]

@youcanwin8099 jquery 是封装的三方库啊，方式千千万，自己私底下搞搞想用什么就用什么咯，但是公司级的要综合考虑，比如要是传统企业比如面向 zf 单位的，用 react/vue 也行不通啊，人家还有 ie789 呢，所以要看实际场景了。jquery+bootstrap 这种现在国内少了点，一般外包在用，因为模板多啊。

[huijiewei]

不用 mvvm 是跟自己过不去吗

[ugu]

jquery+ bootstrap 最大的问题就是操作 dom 繁琐且性能低下，不然数据驱动试图的概念出来干啥？可以这么说，没有 mvvm 降低操作 dom 的成本，前端实现富应用根本不现实，例如你用原生 js 去写一个复杂交互的应用试试，前期实现成本和后期维护成本够你喝一壶的

[ipwx]

你可以不用这些框架，但是用了以后，你会感觉，“真香”

[angmieee]

怎么都可以，但是你确定确定要用 jQ 操作 dom 吗？

[JerryCha]

真的勇士，敢于抛弃一切框架手操 DOM 、手撸 XMLHttpRequest

[red2dog]

看业务场景。

[biguokang]

理论上，不用 mvvm 框架和 webpack 打包工具，纯原生手撸 js 你也能前后端分离，只是，写起来艹蛋，维护起来也艹蛋，结构组织起来也艹蛋。。。。。


为什么艹蛋呢，因为你需要不断地手动创建、修改、删除 dom 节点，如果项目极小那还没所谓，要是项目大起来，你会哭的。

比如说你用 jquery 来 ajax 后端的数据，渲染在前端，那么你要做的就是把数据 ajax 过来，然后你在某个 dom 节点上创建一个 dom 节点，然后用 innerText （我不是很熟 jq，我只会原生）把数据插进去。。。。哦，你是一个列表数据，那就根据数据的长度，循环创建多个 dom 节点然后一个个把数据插进去。。。哦你还涉及条件渲染，那就需要判断哪些节点需要插哪些不需要，什么你还需要给一个个节点绑定一个 click 事件？慢慢来吧。。。。

如果是用 mvvm 框架，只需要在 template 的某个节点搞个双向绑定，把 ajax 来的数据赋给对应的 data，然后就 ok 了他会自己渲染了。。。

mvvn 的好处就是不需要你去一个个操作 dom 节点，因为操作 dom 节点的工作交给了虚拟 dom 去处理，你需要做的只是对着框架的 api 做各种操作而已，工作起来效率也会很高。


举个例子，b 站前端就是用 vue 写的，但是你试试不用框架直接手撸 jq 去搞，不是写不出来，而是工作量会很大很大维护起来很麻烦很麻烦

[fanxingyu9555666]

@ugu 不懂就别瞎说，很丢人

[galikeoy]

@ugu #15 ‘jquery+ bootstrap 最大的问题就是操作 dom 繁琐且性能低下’ 张口就来性能低下

[hbolive]

可以做到，而且页面效率也并不低，这是目前不是主流方式，所以有时候代码可能会繁琐一点，其实个人推荐：layui，后端人员可能更喜欢一点。。

[ugu]

@fanxingyu9555666 很丢人吗？我只是说出我的理解，如果你觉得不好，请 show 出你的理解，ok ？

[ugu]

@galikeoy 操作 dom 基本上会造成回流或重绘，这不叫性能低下？那为什么框架层面会尽量降低操作 dom 的次数？

[SilentDepth]

首先摆正一个观点：狭义上前端搞什么东西都离不开 HTML+JS+CSS 的本质。不管你用什么工具什么框架，最终都是在折腾这仨货。这个道理引申出来就是，你用 jQuery 还是 Vue，在 **可能的产出** 上完全一样。

谁说徒手木架不能盖大楼呢？

但是，摩天大楼徒手盖是要承担很大风险的，这个风险最终会表现为多种问题，比如盖的很慢，或者盖不坚固。工具和框架的意义就是让你能够更快速和 /或更安全地盖楼。Vue 和 React 就是市面上流行的两个盖楼工具 /框架（看你从哪个视角理解），MVVM 则是盖楼的一套方法论。

回到实际的问题。用 jQuery 开发 Web 应用完全没问题，但除非是有历史包袱，现在这个时代实在没有继续用 jQuery 开发应用的理由（补丁脚本之类的另说）。或者话说的重一些，jQuery 已经被时代淘汰了。前后分离的关键就是接口层定义，然后前后各自实现视图层和业务层。只要做到这一点，用什么技术栈都是前后分离。

[SilentDepth]

@ugu #25 要辩证地看待问题。用 jQuery 不一定就要背负 DOM 性能负担。jQuery 是一个工具库，不是视图层框架，使用效果如何很大程度上取决于使用者的用法。我打个比方：我复刻了 VDOM 的各种算法，但涉及 DOM 操作的地方全都用 jQuery 实现，这会不会造成性能低下的问题呢？

[galikeoy]

@ugu #25 可以

[ugu]

@SilentDepth 维护成本呢？是维护数据简单，还是维护散落的 dom 操作逻辑简单？

[Tink]

手写 jquery

[SilentDepth]

@ugu #29 你陷入了一个思维误区。用 jQuery 不表示状态维护一定要绑定到 DOM 操作上。讲道理，JS 应用的状态不就是一个对象嘛，我统一在一个 state 对象上储存和管理状态，计算出最终结果后统一用 jQuery 更新 DOM，哪里复杂了呢。但你说的「维护成本」确实是问题，毕竟 jQuery 没有提供一个应用的逻辑架构，很多逻辑过程需要自己实现。但严谨地说，这不是 jQuery 做不了高性能应用的理由。

[HangoX]

看技术栈，如果没有专业的前端只有后端开发，其实前后端不分离会快很多。如果是前后端分离，前端习惯用什么就什么，自己的事情而已，毕竟调用的只是 api 接口，就算你重构也就是改前端，和后端没啥关系

[ugu]

@SilentDepth 你要这样说，我没什么话讲，那我为什么还用 jQuery 呢，直接原生 js 撸起来不就得了，毕竟 v 站人均尤雨溪水平

[otakustay]

当然可以不用，只不过当熟悉这些框架以后，大概率效率和可维护性是能有效提升的

[SilentDepth]

@ugu #33 你这样就是抬杠了🙁。就事论事，对于简单应用，jQuery 和 Vue 的开发维护成本相差不大（甚至用 jQuery 还省了 axios 的引入成本），用谁都是 OK 的。只不过用 jQuery 没有明显的理由，用 Vue 还能得到不少额外的好处，综合来看 Vue 通常是更好的选择。

「一味地推举 XXX 和一味地抹黑 XXX 是同样的行为。」

[yinzhili]

做了多年后端开发，我个人觉得 jquery 是个好东西，开发简单，很适合逻辑简单的页面。但如果项目规模比较大或历史比较长，那 jquery 相关代码后期的维护成本确实是比较高的。比如一个 div，有哪些地方会对它进行操作，相关代码很可能是分散在各个地方的，查找起来相对比较费劲。

[libasten]

我现在就在这样搞一个 xx 管理系统，因为只会 jquery 操作 dom……

在工作推进过程中，觉得繁琐，但是思路理顺了，也没什么问题。

后面有空，想学学 vue react 之类的东西

[woahishui]

@ugu 怎么会有这种想法，虚拟 dom 怎么会比原来的快呢，不能人云亦云，自己也能做的跟 react 一样高的效率，而且还很简单

[MikeLei]

我之前写了一个在线学习的平台，就是采用 LeyUI+Jquery，后端采用 C# WebAPI 来开发，怎么说呢，开发比较繁琐，那时候还不会 VUE 啥的，但是呢，开发的时候比较自由，不用被 VUE 很多东西给约束，就是拼 Html 代码比较蛋疼，还有前端页面得权限控制不太好做。。也可能是我太菜了。

[lzuntalented]

你对前后端分离的理解让我不知道怎么表达了
你标题有个字母打错了

[yaphets666]

用 mvvm 写一个小时的东西 可能模板或者原生得写一周不止

[newghost]

mvvm 解决的是开发效率问题，有一点性能上的损耗，构建复杂表单比较顺手，一般浏览器兼容差，DOM 动态生成无法 SEO，适合内部应用，管理后台

jQuery 手工操作已经存在的 DOM，操作比较精细，性能好但开发效率低，浏览器兼容较好，各个门户主要还是用这个

[xuanbg]

是的，做前端无论你用传统的 jQuery 还是流行的 VUE 什么的，MVVM 模式都是要搞起来的。一旦开发模板磨合出来了，开发新页面简直就是流水线生产一样高效。

事实上我连古老的 Winform 都搞起了 MVVM 模式。控件拖拖完成一个 View，里面坚决不写一行代码。然后搞一个 ViewModel 类，构造方法里面专门写数据双向绑定的代码，和界面交互的事件绑定，一般都是几个方法实现一下事件触发后的交互逻辑，百十来行代码就搞定。然后再来个 Model 类，就负责构造 ViewModel 和转发数据，通常也就几十行代码完事。

这样分割后最大的好处是代码结构通用化和模板化，一些公共的处理逻辑就可以提取出来，搞几个基类，让业务类去继承一下，就可以少写很多很多的代码。

[vone]

问题 1: > 做 web 后台管理程序(CRM 之类的），用 jquery+bootstrap 能否一样做到前后端分离？
可以做到

问题 2: > 就是不让后台的 java 接口来输出 html+jquery+bootstrap,而是前端 html+jquery+bootstrap+css 读取后台 java 接口。有这种类型的、比较典型的、也比较流行的框架吗？
1 、最小学习成本的应该是直接使用 jQuery+bootstrap 编写业务代码，可以实现所有功能但是有些繁琐；
2 、最经典的应该是 jQuery UI 配合 jquery 生态，可以覆盖 100%的业务场景；
3 、最流行的应该是 Layui，官网 https://www.layui.com/ 。

最后说一下：
1 、如果团队成员中没有专业前端的话，请不要相信楼上吹 MVVM 的人说的哪些话，坚持使用 jQuery 没错。
2 、脱离实际应用场景谈性能及优越性都是耍流氓。

[qqqqqcy]

js ≈ 走路、jq ≈ 骑车、vue/react/ng ≈ 开车

- 如果终点很近，当然是随便怎么过去，滚过去都行

- 如果终点很远，当然开车最快。反对开车的理由实在有点搞笑

问：不会开车，等我考完驾照再来开，我单车都可以来回十趟
答：如果只去很少的次数，当然没必要学新的东西了

问：开车效率低，不如我单车可以选最短路
答：路程短，时间不一定短。小路也不怎么安全

问：单车维护成本低，容易修
答：所以选工具最重要的因素是好修么？

问: 开车烧油，消耗大，不环保
答：如果你真的这么在乎这个，那就慢慢骑车吧，还能锻炼身体。只是等你去一个地方的耗时，人家可能已经来回十躺了

当然了，有些极端情况确实没法开车，比如路太窄、道路禁止机动车出行、乘客晕车等

[love]

作为从 jquery 时代走来的前端，你以为用 jquery 开发会更快，其实不然，用 jquery 不但更慢，代码更不易读，这几年的前端工程化飞速发展，没有正经前端还想回到十年的 jq 。

只有一种情况可以用 jq，就是文档型产品，基本没太复杂交互，如博客什么的

[mscb]

应该先看前端复杂度吧。如果基本没啥交互，那用普通的 jq 效率还是很高的。

[liuy1994g]

这种情况 Vue2 一把梭

[fanxingyu9555666]

@ugu jq 并不比 vue 和 react 慢，如果你 js 功底好，用 jq 写出来的代码性能可以比 react 好，不服来辩

[wanguorui123]

原生就可以实现前后端分离，只是麻不麻烦的区别。

[youcanwin8099]

这个里面，有些是支持这种 jquery+bootstrap+html 做前端的来控制后端的；但是奈何现在几乎没有这样的主流框架来支撑这一观点，我寻遍 github,gitee，都没有! 要么就是 springboot+thymeleaf/jsp，要么就是 vue/ant-d/elmentUI + springboot

[youcanwin8099]

所以感觉自己最终的这种看法，只能归为：少数项目、少数人的私下选择。。。

[akakidz]

还有一个很重要的是维护成本，框架写出来的东西，后续有人拿到项目也比较好上手，我之前维护公司的 jQuery 项目看的很恶心

[dNib9U2o8x]

楼主要的就是前端直接写页面，然后需要数据时候 ajax 请求接口就好了。
楼上各路大神张口闭口就谈性能，大部分的前端开发工作，有多少会遇到性能瓶颈？真遇到了，也可以针对性解决，
至于现在为什么都在用 react/vue 等框架，最主要的原因可`开发效率`，`开发体验`和`维护成本`。

[RRRSSS]

可以不用，所以最最开始是 MVC：Backbone，现在还能听过这个框架的应该都是前端老鸟了。之后才慢慢切到 Anguarl / Vue / React 这种 MVVM 框架的。因为在 GUI 编程方面，数据驱动界面渲染真的很方便，以至于现在都是政治正确的选择了，你看苹果的 SwiftUI，Google 的 Flutter 都是数据驱动。

[visonme]

很多人考虑性能，但是大多数类 CRM,ERP 之类的，对性能的追求并不高。

前后端分离的目的是什么？ 简单点就是分工和效率，JQ+BS 跟 VUE/REACT 对比，肯定后者了。

你说 JQ 能做到前后端分离吗？ 当然了，就是效率低了点而且不易于团队协作，如果用 JQ，最好考虑前端模块化

[HytonightYX]

前后端分离是个项目管理问题，不是技术栈问题

[lewinlan]

这个问题等同于
用汇编写代码可以吗？

[hyyou2010]

磨刀不误砍柴工，学吧，react / vue 任一个。

[sivacohan]

做 CRM 的话，你得考虑一下要不要兼容 IE8 、IE9 。
如果需要兼容的话，还是用 jQuery 吧。

[geying]

从技术上讲用啥都能前后端分离
从项目上讲项目经理叫你用哪种分离你就用哪种分离
从个人角度讲学习成本低使用简单维护方便的方式可以节省自己的时间成本

v 站现在怎么这么多杠精

[shuding]

Next.js: https://nextjs.org

本质上是前端（ React ）框架，但完全支持后端功能（大概是 React + Express 集合体）。在 pages 下面新建一个 /api 目录，里面就可以直接放 Node.js API 接口了。
最有趣的一个优势是：写 TS，前后端可以共享接口的 Typing 。

例子： https://github.com/zeit/next.js/tree/canary/examples/api-routes

[cheng6563]

老早之前用 ext.js 也是前后端分离了

[areless]

说没有 js 框架干不了富应用，操作 dom 会卡的。真想把你们通通扔回二十多年前去九城玩网页版的烧菜做饭狩猎挖矿，前端全 js 实现，ie4.0 流畅。无知

[alertZ]

@youcanwin8099 看项目需求，有时候项目要求单页面开发，我懒得用 webpack 就会使用 angular 。现在用 webpack 也是开发多页面也不是单页面。webpack 可以帮我解决很多事情，比如 CSS 兼容性问题，代码复用，包管理等等。我现在是 webpack+JQ+Bootstrap 来搭配。webpack 作为管理，JQ 作为 ajax，bootstrapUI 。当然你如果想用模板渲染，也有对应的包可以用。

[youcanwin8099]

@alertZ，哦，那你的这个 webpack+JQ+Bootstrap 能否有兴趣和时间 形成一个框架类的东西，放到 gitee 上？

[SilentDepth]

@youcanwin8099 #66 决定用 jQuery 的话，要什么 Webpack，Parcel 多香～

[windychen0]

@youcanwin8099 我觉得你只是单纯的想找个 admin,http://ace.jeka.by/index.html

[Chenamy2017]

没有哪个是必须的，在你用没用这个技术前你最好先去了解这个技术，了解它的优势和不足，选择最适合你的。如果没有了解和尝试就做选择太不客观。说回 VUE/REACT 这些，确实效率很高，谁用谁知道。

[alertZ]

@youcanwin8099 哈哈哈，我技术不高，就不献丑了。

[IsaacYoung]

又开始了吗

[hjdtl]

不一定要用 MVVM 类型框架，也没必要学习这些框架，徒增开发难度。
应该使用 jQuery，方便快捷。

[vivipure]

可以自己封装一个 spa 框架，原理就那样，配上模板引擎和 webpack 。其实也挺方便的

[youcanwin8099]

@SilentDepth ,这个 ACE ADMin(”http://ace.jeka.by/index.html“)以后去了解了。反正我从这个帖子了解到了：用 webpack+jquery+bootstrap 一样可以实现目的，或许更轻量级。这个作为一个有经验的、高阶的前端，他在做项目时，一定会酌情考虑，而不是一味采用时髦技术造成成本飙升，这是一个技术问题，也是人品问题，也是项目管理问题。。。
如果用 webpack+jquery+bootstrap，每次发布前，需要 npm 打包吗？如果要打包，我觉得还是费事。我认为那种打包行为真是一个耗时、带来项目成本飙升的一个重要因素。

[sima675]

这样也能吵起来.....喜欢什么就用什么 只要自己用的舒服

[youcanwin8099]

我之所以这样，是我本人不是一个前端，但是目前卷入了一个项目，然后前端和 PM 用了 ant design vue，但是我我感觉很费事，自己搭建环境跑测试也很费劲，前端开发一个任务花的时间很长，效果也不好，找别的另外一个做过很多年的前端但不懂 MVVM 的接手，我看他也要花很长时间。但是问他们有什么更好的方案，又不说，也不说这个 ant design vue 好，或不是不好。弄得我一个后台架构师一筹莫展。。。

[SilentDepth]

@youcanwin8099 #74
使用 Vue 或 React 不算赶时髦啊。比如 Java 应用开发，用 SpringBoot 怎么就算赶时髦了呢。即便从成本角度去考虑，jQuery 要求使用者手动完成 DOM 树的构建，维护成本反而比 Vue 或 React 高。
现代前端开发基本上都需要发布前构建的（有它的固有需求在，你不能单纯把它看做耗时成本）。如果你不想引入前端构建流程，那用不用 Webpack 区别不大，同时还要注意不要使用 ES6+ 特性（如果你需要支持 IE ）、处理好依赖的引入次序。

[SilentDepth]

@youcanwin8099 #76 术业有专攻，现在的前端自成一个庞大的体系，就跟后端自成一个庞大的体系一样（不然怎么还会有「前端架构师」这么个职位）。「做过很多年的前端……要花很长时间……又不说（更好的方案）」，恕我直言，这同志水平不行。如果这个项目已经用了 Ant Design + Vue，我可以很负责任地告诉你，这个开始没有毛病。接下来，逢山开路遇水架桥，有问题一个个解决便是。这时候改换技术栈反而更有风险。

[chingli]

非前端，借此话题，针对目前手头上的一个项目，大家看看我这种技术选择对不对：

项目需要从后端传递过来一个类似 GeoJSON 或 TopoJSON 格式（其实是完全自定义的格式）的 JSON 文本（很大），在浏览器端生成对应的 JS 对象实例，并据此使用 SVG 技术进行类似地图一样的可视化显示。由于是监控类项目，要借助 WebSocket 保持长连接，该对象实例不能在网页渲染后销毁，而是一直存在，并且根据后续传来的 JSON 文本对其进行更新。如果用 VUE/React 类技术，则浏览器端就会长久有以下三层了：

JS 模型对象 ⇔ 虚拟 DOM ⇔ 真实 DOM

但由于 JS 模型对象的格式是固定的，了解其中各个元素应该对应的 SVG 元素（可建立关联），且从服务器端传来新数据时必须要比较新数据和已有的 JS 模型对象的区别，因此觉得不用虚拟 DOM 会更好。即直接 DIFF 新旧 JS 模型对象，直接根据 JS 模型对象的更新来更新真实的 DOM 。这样省去了虚拟 DOM 层，省去了对虚拟 DOM 的 DIFF，或许能使性能大大增加。

或许对于我这种目标纯粹的单页面应用情况，会经常遇到，如 Google Docs 。不知道我这种不使用 VUE/REACT 类框架的技术选型对不对？

[SilentDepth]

@chingli #79 VDOM 层的内存占用可以忽略（除非是需要锱铢必较的场景）。如果你的 JSON 结构与 DOM 结构对应性很高，为什么不把 diff 的过程交给 VDOM 来完成呢？综合性能很可能比你手写的高。

[qqqqqcy]

@chingli 看描述你这应该就是个大屏展示页？首先是「性能大大增强」，假设你写得完全没有一丝性能浪费，我估计有多大呢，应该是首屏速度从 1.1s 提速到 0.8s 的水平。然后为了这足足 0.3s 的性能，开发复杂度、后期维护复杂度，都会疯狂上升。

如果是偶尔写一两次，并且不怎么更新倒也还好。你说会经常遇到，那就更没理由花时间用落后于主流的技术栈去做一套所谓的高性能逻辑。

虚拟 Dom 的比对和更新也根本不是你想的那么消耗性能。只要按照最佳范例，早就能做到最小单位的监听和更新了，更比如更新 Dom 属性、给 Dom 换位置等操作时，你确定自己一个个改的性能比人家高？而且本身框架帮你处理了一堆乱七八糟的边缘问题。构建工具也全是现成的，一行命令就能跑起来。为啥要用 jq 磨练自己

或者说你这么问自己：花时间研究 jq 好还是花时间研究 vue\react 好？

[shintendo]

@youcanwin8099
我认为那种打包行为真是一个耗时、带来项目成本飙升的一个重要因素
-------
这话让我觉得很困惑，能具体讲讲你为什么觉得这是一个很大的成本吗

[chingli]

@SilentDepth @qqqqqcy 谢谢！

原来是考虑把自己用 JavaScript 生成的模型对象持久化，不过还是得考虑一下是否需要如此。

另外，本来也不打算用 jQuery，而是想着针对我的模型结构自定义编写一个可视化模块。

[SilentDepth]

@shintendo #82 无责任猜测：可能后端是 PHP，没搞过构建工具流

[youcanwin8099]

后端是 java @SilentDepth .

[youcanwin8099]

就是觉得打包，时间长。前端有那么多选择，为啥要打打包啊？！一次打包要 2 分钟以上。看我的另外一个主题： https://www.v2ex.com/t/663223#reply14 。如果这个打包也要很多前端知识和技能，那你说成本飙不飙升啊？！我们曾想找个外包前端做这个项目，以加快开发进度，结果他开口就要 3 万月薪。

[xcstream]

可以
但是 jquery 比较容易注入脚本

[SilentDepth]

@youcanwin8099
我前面说了，现在的前端是个专业活儿，早已不是曾经的「 PHP/Java 开发的附属品」，你要换一个高度来看前端开发。对于现代前端来说，打包构建是很正常的事情，属于必要的学习成本，说成「飙升」真是有点冤枉。谁也没说 Java 需要编译就「成本飙升」了不是？

我推荐 Parcel 也是想提供一个成本不那么高的 Webpack 替代品。

不过，打包耗时 2 分钟？一定是哪里出了问题。

[anguiao]

不用框架的结果，就是最后自己造了一个更垃圾的框架。

[youcanwin8099]

@windychen0 "我觉得你只是单纯的想找个 admin,http://ace.jeka.by/index.html",
看了一下，发现 ACE 的界面好精致、漂亮哦！就是我想要的后台界面！只是项目已经用了 antd-vue,没有时间再去切换它了。还有就是这个 ACE 并没有阐明如何和后台接口做对接，还有 session，token 诸如此类的问题。。。不会高所，一牵扯到会话、后台接口，就要 MVVM 吧！ http://ace.jeka.by/widgets.html

[youcanwin8099]

@windychen0 ,"不要告诉我：一牵扯到：token,会话、后台接口，就要 MVVM 吧！" :(

[windychen0]

@youcanwin8099 没有啊，token 可以用 jwt 插件也可以自己写，反正前后端能匹配的上就行了，本质上就是你个人在向客户发身份证，接口的本质是从后端请求数据，基础是 xhr 四步，jq 里面 ajax 就可以了啊