模板框架选用问题

Question

    近段时间在学习 Spring boot 。它将传统的 jsp 抛弃了 引用的新的模板技术 thymeleaf 引入了一堆新的标签库。这是问题背景

    在对比他们是的时候我发现除了标签库之外在使用上它们是没有区别的（不包括编译问题），像我这种 前端基本都是 jquery 来修改 dom 节点的。标签库这种东西对我的影响不是很大。。。 那么我在使用它们的时候是不是没什么区别呢 ？

    再然后就是前端框架，像vue，angular这类的前端框架 我感觉作用不是很大啊（个人感觉），无论传值显示，修改dom节点 感觉用处都没什么。应用是挺简单的，但是 jquery 写熟练的实现这种功能也挺简单的，在又要适应一种新的标签的情况下感觉 jquery 的效率应该不差于这些东西吧，而且 js 都是自己写的 应用起来灵活很多，那么为什么那么多人都说不推荐使用 jquery 来操作呢 ？

Answer 1

前端基础扎实， 学习vue还是多快的。 用了vuejs等你就知道他的好了， 逻辑随便写

Answer 2

前端模板都可以用，看你选哪个而已，thymeleaf 也只是官方推荐，前后端分离后，是没有什么限制的，你高兴也可以接着用jsp

 

Answer 3

thymeleaf 貌似也不推荐用了，推荐使用freemaker

Answer 4

JQ表单也能异步提交吧,formData就可以做到了

Answer 5

管他什么模板技术，提供什么后端模板标签，反正就写标准的HTML就可以了。

如果一个复杂的富客户端表单，你用 jQuery 后者用 MVVM 来做，你的代码肯定比后者多，而且还不如后者更直观。

当然了，几乎什么都是 form action=xxx submit 的这种传统方法，用不用 MVVM 几乎没用、前端模板应该都无用武之地。

Answer 6

我只熟悉jquery和easyui，其它的都没有玩过

Answer 7

一直是js，jQuery和easyUi，Ext的用，其他模板没咋熟悉过，出去感觉好慌。

Answer 8

dotjs值得拥有

Answer 9

嗯嗯，不管什么模板如果不是为了做模板导出，我应该都不会轻易使用，前端模板还是要比后端模板容易使用一点，API 也多一点

Answer 10

那就前后端分离吧

Answer 11

可能是我写后端代码习惯了，把前端的东西也当成后端代码来写，下次写项目考虑一下引入一下这种前端框架吧

Answer 12

回复
vue这种，可以当库引入，只用数据驱动部分（部分代替jq的复杂业务）；也可以当全家桶搞前后端分离。

Answer 13

jquery对应的后端可能比较像c语言，灵活、功能强大，什么都能做，但是维护的就蛋疼了，代码、数据、页面混为一体，浑然天成。所谓“撸的一时爽，维护火葬场”。对付简单的业务没问题。

vue这类现代前端模板引擎，很好的把数据、视图、页面划分开来，维护性、优雅性高了一个档次。

Answer 14

你连springboot解决了啥都没弄清楚……springboot一样可以打包war，部署在tomcat容器里的。你们自己搭建的项目诡异，需要两个boot项目……这关springboot本身啥问题啊？

Answer 15

回复
问题是几个人又会用回去打WAR发布？既然要打WAR我为什么要boot？或者你觉得写代码注解创建很多必要bean好过xml配置生成？或者boot真能省下什么必要的配置？或者jsp支持比传统结构方便？或者其它模版有jsp这种模版效率高？

Answer 16

回复
@sxgkwei : boot支持你却说无法做到，这是在误导别人好不

Answer 17

看项目类型吧。

一般做网站公共服务类型的，适合现在正流行的前后端分离方式来做。前面的 @ManderSF 已经说的很清楚了，这些好处还是显而易见的。说不定哪天，老板就想支持到其它端上的业务去了。

然而，做企业内部应用的，甚至连 Spring boot 都不适合使用。因为企业一般就一个服务器运行着各种支撑软件的服务器端，每个应用都是使用来做某项业务，分布式的硬件环境就不具备，访问压力根本也不存在的。所以这种情况下，还是传统的jsp运行在 tomcat 上的项目结构更好点。我目前公司就是做这种内部系统的，之前有些同事起项目时，选了 Spring boot ，现在看来坑略大。

坑的点有如下：

1， Spring boot 都是单进程独自启动的，那每启动一个，就是200-300M的内存没有了，客户就一个机器，哪儿有那么多内存让你这么折腾。如果是tomcat jsp mvc 结构的，那么多个项目就可以全部放一个 tomcat 里面运行，内存占用会小很多。运行时服务器容器也是很耗内存的啊。

2，现场实施维护便利性奇差。公司有好几个项目，每个都得启动一次，有的甚至前端一个boot，后端一个boot，要启动2次。实施人员经常搞不清楚 java 进程这一个对应的哪个应用，关哪个和开哪个。出现错关漏关漏启之类的事情很常见。而如果在一个tomcat里面，那么，只管关它，启它即可。当然这种情况你可能说也不好，我更新下A项目，也就停了B项目；但这种客户的抱怨总是好提前沟通安排好更新时机的，影响其实不大。

3，这个不能说坑吧，只能说事实就是如此，当然和我们选型和开发的人关系不大。就是：JSP 这种模版，渲染出 HTML 代码的速度最快，其它模版通通靠边站。

综上，软件项目的选型要针对它的应用场景来看，微服务并不是万用最优贴。硬件供给，项目目标使用者，是否需要考虑高频高并发压力，目前开发人员配备情况，人员对各个技术方案的熟悉情况，这些都会对最终项目定型产生影响。