一般来说,基于组件的框架通常更难以使用,主要是因为它们将“Ajax通道”集成到自己的内部.作为一个例子,目前非常流行的Apache Wicket实现了所有的Ajax的东西,有时在某些平台上表现为破坏.这种整合的原因通常是这样,框架的开发人员可以完全依靠Ajax函数在其框架中的行为;通过自定义实现,他们可以依靠它,并可能更快地调试它.当然有例外(即使是Wicket也有自己的jQuery实现,称为wiQuery),但是即使这样,整合可能与您将能够正常写入的相同.

现在,基于请求的框架就像您所说的那样(我将它们归类为基于我的体验的基于模板的框架)通常允许您对页面的各个部分进行更细粒度的控制,通常最终甚至编写最终的标记在这里和那里的一些魔术标签链接Web应用程序的动态部分与静态布局.考虑到这一点,很明显,这些通常允许您作为开发人员在许多其他事情中选择您选择的JavaScript库,但它是一个权衡;无论基于组件的框架在这​​一点上将提供什么,您需要自己重新实现.最常见的是,这仅限于处理Ajax请求,但从框架到框架不同.

总而言之,如果您真的想使用jQuery(以及为什么不这样做),并且您不能同意其集成在基于组件的框架中的方式,请查看另一种提供的方式.

如果我不得不推荐一些我相信会适合你的东西,那么我建议在Spring MVC之前使用纯Java的后端东西等等,但是由于GSP是Grails的一部分,所以这个组合并不存在,一个基于Groovy的Web应用程序框架.