前后端分离，一定要 vue?

[w292614191]

能找到的资料全是 vue 做前端，难道没有 vue 就不能分离了？我知道 vue 是趋势，但不是必须吧。

我们之前是一个 iframe 结构的 springboot 项目，并没有分离进行，现在有想法看了下全是 vue 做前端。但是我们已经花了好几万买了 miniui 这个 web 控件，功能也满足后台类管理系统。

所以想咨询下是否有：js 之类+spirngboot 实现的前后端分离项目案例。

感谢各位的回复和讨论。
我并不是要 $("#).val(xxx)去操作 dom 之类的。
miniui 也能实现，form.setData(data)来实现 dom 更新，(这里不是打广告)。
只是比较好奇，不用 vue 是如何实现一套完整的管理类系统。

[yingxiangyu]

前端用什么技术都可以吧，没必要限制到 vue，就是 vue 简单上手快，所以推荐的多

[woodensail]

前后端分离也不是前端 MVVX 兴起之后才有的概念啊，以前用 jQuery 的时候不照样前后端分离搞得好好的。

[pianjiao]

前端什么都可以啊 就是 html + js 也行啊 vue 只是更好开发、更方便、省事而已

[ESeanZ]

jQuery 一把梭。 走 ajax

[minglanyu]

"花了好几万买了 miniui 这个 web 控件"

不是很懂

[w292614191]

@minglanyu 就是一个 web 控件。

@ESeanZ
@woodensail
@yingxiangyu
@pianjiao

有例子吗？不是很懂菜单 url 怎么实现的。

[sarices]

如果是公司习惯用什么就什么吧，框架成本很高的

[loading]

jQuery 也可以

[JK9993]

vue 之类的框架有配套的前端路由库，jquery 的话感觉不太需要这个路由管理（也不太了解），对 url 管理要求不高的话可以 nginx 一把梭。

[jswh]

最近又开始些模板了，主要是一些简单页面还要前后分离感觉切来切去太麻烦，反正一次编码很少改动。

[Hoshinokozo]

前后端分离指的是后端提供 Model，View 和 Controller 由前端控制，跟 vue 并没有绝对的关系，vue 只是一个比较新的 View 框架而已，用 VM 取代了 Controller,不用手动操作 DOM 了

[ipwx]

因为 vue/react 这两大框架把前后端分离架构中，很多你用 jQuery 需要自己重新造的轮子给你造了一遍了啊。因此没多少人用 jQuery 做前后端分离不是正常的么。

[wangxiaoaer]

好好理解什么是前后端分离就不会提问的时候起这么找抽的标题了。

1 我们最初做分离是用的 jquery backbone 一把梭。

2 现阶段 vue 占比较多，因为他上手快。

[wangxiaoaer]

@Hoshinokozo 你这解释笑死我了。

后端就没有 Model view 了？？？？ Json 不是 view 吗？

前端就不要 Model 了？？？

[w292614191]

@ipwx 也就是说，如果有一些其他的控件可以实现，道理是一样的。并不是必须 vue 来封装这些轮子。
@wangxiaoaer 用 jquery 的时候，怎么实现的 url 菜单呢？类似 src/user/list.html，然后部署到 nginx，路径就会映射了？然后数据库也这样存储的吗？

[ipwx]

@w292614191 在 Vue 和 React 里面，URL 映射可能是 JS 框架做的而不是后端做的。后端就只有一个页面 route，所有的页面请求都返回同一个 .html。然后提供一堆 JS API。这样可以实现无刷新的页面响应。

再比如双向数据绑定（ HTML 控件用户的输入和你 JS 内部的对象数据双向绑定），全局状态管理。。。总之现代 JS 框架做了好多很复杂的工作，让你写大型复杂页面变得很简单。

而且你还能用各种 JS 的辅助库，进一步提升你的开发效率。更兼有 Webpack 依赖打包，还有 Babel 把最新的 JS 语法转译成主流浏览器能支持的 JS 代码，或者 CSS post-processor。诸如此类的一整套工具链，是 jQuery 时代要花很多人力才能摆平的事情。
----

总而言之用 jQuery 不是不行，而是要花大量经历把现代工具链已经提供给你的东西重新做一遍。当然一个 specific 的项目可能就需要重写一部分东西，但也是不小的工作量了。比如适配各个版本的浏览器、手动双向数据绑定，后端 route 之类的。

[ipwx]

再比如你说的菜单 URL。在很多 Vue 和 React 的 UI 库里面，菜单项和前端 route 的配置是自动绑定的。也就是说你只要管写个菜单，写一堆 Vue 或者 React component，用 route config 把这些 component 组装成你的 web app，菜单自动会根据 route url 来显示不同状态。这在 jQuery 时代需要手动处理。

[Sendya]

2013，14 年那阵子，我还在用 Knockout 做前后分离。 那时候连 Vue 是什么都不知道

[Procumbens]

当然不一定要用 vue （还有 React ）
国内是 vue 较多 但是国外基本都是 React

[w292614191]

@ipwx vue route 好像是映射吧，比如吧 user -> src/user/userList 是这种概念吗？

如果我就是普通的写个超链接指向 src/user/userList，那么部署到 nginx，这样是可以访问的吗？

[wangxiaoaer]

@w292614191 js 有专门的路由库。

[wangxiaoaer]

@w292614191 楼上说的很明白了，但鸡同鸭讲。
你还是先弄明白 js 路过的概念和实现原理再回过头来思考下。

[ipwx]

@w292614191 不对。比如你制定的是 /user/* -> src/user/userList，那么你需要让 nginx 把所有 /user/* 指向 index.html

[ipwx]

后端的源代码文件结构和前端的 URL 可以完全没关系，比如 Python 和现代 PHP 框架。当然，可能楼主你还停留在 PHP4 时代，那么你可能需要补的不仅是现代 JS，还有现代 PHP。

前端也是一样，URL 映射关系只是一组规则，和源代码结构不相干。

[VictorJing94]

这个要点在后端吧

[passerbytiny]

前后端分离有两种：完全分离和 MVC 分离。

如果是前者的情况下讨论前端，那么后端就不用提了，后端只要提供 RESTful 接口即可，是 java、php 还是 asp 都无所谓。这个时候前端当然不一定非要用 vue，还可以是 rectJS、angularJS、extJS 等各种框架。这时候如果不一定非要网页端的话，用 Xamain 做个 UWP/Android/Ios 全套 APP 也不是不可行。但是，只用原生 JS 和 Jquery 是铁定不行的，你要非这样做也能做出来，但那成本可不是一般的高。

如果是后者，本质上是后端的分层开发，并未完全分离。以 springboot 为例，C 和 M 全部在 springboot 之后，即全在后端，这基本上限制了 V 的发挥，此时的 V 只能是 HTML/模板+少量的 JS，这个时候 vue 这种半框架还可以用用，***JS 这种全框架就是一个都不能用的。这时候你用原生 JS/Jquery 是可以的，但是你要项目案例是很难有的，因为 springboot 跟 jquery 不是一个年代的，用 Jquery 的可能再用旧 Spring 甚至 JSP，用 springboot 的再用 vue 或类似半框架。

结论，老老实实学 vue 吧。

[fengbjhqs]

好奇，jQuery MiniUI 需要买吗？

感觉你们想让后端把前端的事情做了？

[minglanyu]

前后端分离是趋势。
不用纠结用什么框架，也不用带着情绪，不懂就去学一下，尝到甜头就真香了。

vue，react，angular 这几种框架只不过是一个开源的前端实现选择，这么受欢迎是有它的道理的。
能用原生 js 写，jquery 写当然也 ok，本质上都是 DOM 解析，CSS 渲染，表格展示数据，表单提交，请求发送，响应处理等等，复杂的重依赖前端的内容就不提了，canvas，node 生态，vue 生态很多内容，讲不完的。

不过也不知道贵司什么样的情况 按需求去选型是最重要的。

vue 项目最终打包出的是个 dist 包，其中包括 html，css，js，dist 包中的文件可以指向你的服务端系统接口，也可以指向你的多个服务端系统接口。

没你想的那么复杂

[minglanyu]

入门 demo 级别的前端 vue+后端 spring boot 项目，随便看看吧： https://github.com/arya-spring-vue

（讲道理在 v 站发出我都不好意思把这入门辣鸡 demo 拿出来，不过还是给你看看吧，兴许有帮助

[w292614191]

@wangxiaoaer 你说的这个 js 路由，更多的是指单页面应用吧，只在一个页面做操作。

如果是 iframe 加载一个业务界面呢？

[w292614191]

@ipwx
@fengbjhqs
前端通做，是后台类系统，并没有特别炫酷的技能。

[sagaxu]

新项目建议都上 vue 或 react，有一大把免费的开源框架可用，扔掉 miniui 算是及时止损。

[wunonglin]

angular 也行

[fengbjhqs]

@w292614191 #31 在不考虑很高的性能，vue/react，大概率比 js 效率高太多了，

[ipwx]

说起管理系统，不试一下 vue-element-admin 么。。。。

[areless]

08 年那阵子的事情，一个一起做项目的突然对我说，你们写前端的怎么不用 js 直接生成 Dom 并且绑定数据，我认为这是一种后端思维，到现在仍然无法接受前端的现状

[ffxrqyzby]

建议从机器码搞起

[liuxey]

miniui 也是个不错的前端框架，不过是上个时代的产物，和 extjs 类似，你们要是用的熟，不换也行，但是人的问题你们要考虑，不然老项目维护、新项目开发找不到人就尴尬了

[cedoo22]

变量一多，没办法 只能上框架。
现在前端要匹配 ios 安卓 各种机型、pc 各种浏览器的兼容性，不同分辨率，全靠 html 和 js 简直要疯。

[ajaxfunction]

页面上涉及到复杂操作计算的时候,例如购物车计算价格，批量删除订单这些等， 用 vue
如果只是单纯的页面偶尔交互 用 jquery

[minglanyu]

中后台系统看下 ant design pro 吧

[ufan0]

Jq 一把梭，外加 Thymeleaf 完美。

[forgottencoast]

@Sendya Knockout，好熟悉，没记错我是 09 年用的，当时就觉得很先进。

[w292614191]

@ipwx 我发现这个连一个完整的 datagrid-tree 都没有，还有手动实现一堆。miniui 支持 datagrid-tree，支持树节点增删改查，各种骚操作。

@liuxey 老哥，懂行。

@minglanyu 这个要学 react 啊。
@sagaxu 已经购买了授权，不可能不用。

[wanguorui123]

一入前端深似海，从此代码不好改

[meathill]

1. 当然不一定要用 Vue，你还可以用 React，或 Svelte
2. MVVM 对前端是质的飞跃，类似内燃机之于蒸汽机，不要拒绝它，不要为了不同而不同
3. 老技术该放弃就放弃，抓住机会升级，花了钱的也该扔就扔——而且几万块，说真的，困住你的技术路线不值得……

[yaaaaaak]

都是现成的轮子，不如试着思考一下用新的开发效率是否有提升。更直白点，考虑下内部换项目开发或者离职交接成本够不够那几万块。
当然如果你是小领导且 miniui 是自己拍板买的，更换成本可能会特别高。

[zhw2590582]

我手写原生 JS 或者 JQ 也可以写前后端分离啊，只是麻烦而且没有社区支持，另外现在 web 控件这么贵的吗？开源的不是一大堆吗？

[Soar360]

上海普加的 jquery mini ui ？

[wangyzj]

这个得看业务需求把
跟用什么前端没关系
miniui 组件对目前业务好就还继续用贝

[yisiyisi]

说句题外话 MiniUI 太丑了。 = =
React + Ant Design 或者 Vue + Element UI 不香吗？
2020 年了，“好几万买了 miniui ” 就像很多年前几十万买台桑塔纳舍不得换一样。

[ipwx]

@w292614191 嘛，vue 的生态一般不是一个库一把梭，而是在 vue 的总体框架下，不同库协同使用。Vue 如是，ReactJS 如是。因为个整体框架，所以各个不同开发者出来的库可以很流畅放在一起。

当然如果你们熟悉 MiniUI，那也不着急换。另外其实 Vue 或者 ReactJS 都可能包装一个成熟的 jQuery UI 库（比如 vue-bootstrap ）。反正这要看你们团队得了。

[ipwx]

@w292614191 嘛，其实买控件也有买控件的好处。开源要自己整合开源库，写一点润滑代码。哪怕现代框架让这种事情变得很简单，但也是工作量。然而话说回来，ReactJS 作为好几年的项目，还是 Facebook 主推的，这种衍生商业库肯定是有的。Vue 的话，可能比 ReactJS 晚，但是近几年发展也很迅速，所以过段时间肯定也有优质的商业库。

如果你们公司是这段时间才买的 miniui，那估计就是 49 年入国军了。

[w292614191]

@Soar360 是的，
@cnvp21 主要是面向客户群体是这样的。不是很在意界面漂亮


@ipwx 其实也是领导比较中意这种稳重风格的 UI 吧。哈哈，就稀里糊涂用下来了。轮子倒是蛮多，能满足开发。