Java Web框架前景浅析

看了你们的讨论后，受益匪浅，
我们现在服务器端已经不关心客户端使用的是什么技术
一律返回的json串，然后由客户端去解析json

我们目前主要是做移动互联网，android ios客户端都调用服务器端，
然后返回json，客户端解析

跨时间，跨团队维护 这个说的到位！

整合前端路线 说的就是GWT之类的吧？

几年前项目里用Gwt-ext，觉着写起来蛮有意思的，后来直接用了extjs以后，就再也不想回到gwt了。该怎么说呢，基本的用法只要熟悉了都好用，灵活的部分那肯定是直接上js来的方便一点。

个人有几个疑问：

1. LZ提到桌面开发方式的好处是组件化能力非常强，借助发展多年的桌面控件设计经验，可以很容易地设计出复用度非常高的组件——
前端js的发展，用B/S分离形式，b端就不能“容易地设计出复用度非常高的组件”么？
维护和扩展性比用java写的组件差？（学习成本另外讨论）

2.如果B/S结合紧密，不适用移动终端的本地应用，B/S分离，起码S还能复用。
B/S紧密是否会带来终端针对性优化或简化的困难？有没有jsf做的应用在ipad运行和用B/S分离做得同样的应用的性能比较？

另外就是楼主说的跨团队沟通成本的提高，这个比较赞同。
但据我接触的一些公司，70分水平的javaer + 70分水平的jser做的东西比70分水平javaer同时做前后端（第一种框架的方式）会好的多。

说说我个人的理解：

1. js的扩展性比java强，任何object和prototype都是开放的，可以随时修改。除非你刻意把一些东西封在闭包里，否则都有扩展的可能，比起java不知强多少。例如java里你不可能修改原生数组的行为，js里就能轻松办到。

维护性在同等的管理力度和编程水平下比java弱。java只要稍微质量好一点的代码，基本上都能做到自文档。大部分内部类库拿到api只要大概看看例子就能用。js组件库没有详细文档的情况下不认真研究实现细节的话基本不可用。函数经常接收一个config对象，不看文档你完全不知道config里该放什么。而javascript需要在网络上传输这种天性就注定了它不鼓励在生产环境代码中写大段注释（你拿到min version后还要找对应的debug version），保证文档与代码同步并不容易（java也不容易，所以我个人比较提倡写自文档的代码而尽量少写注释）。不涉及具体业务的纯专业组件库（ExtJS之类）自然可以做好，但某个业务项目团队能否持续维护文档和保证代码质量是个很大的问题。所以我前面说：如果你能把javascript团队管起来，并且大部分逻辑都在前端，代码质量，单元测试和文档也能管理好，说明这个公司具有合格的动态语言团队管理能力。那后端根本没必要用java（除非因为遗留代码你没得选），随便一种主流动态语言都比java好。

2. 这里讨论所谓B/S，是在展现层再分出一个B/S，也就是在展现层上使用客户端技术或框架的比重如何，甚至把MVC里的V和C都使用客户端技术实现，例如Angular。你要移植到其他客户端上，无论是哪种方案都可以复用服务器端的M层和部分C，反而如果B的比重太大，有可能导致因为客户端不兼容而被迫丢弃一些本来可以直接复用的C层代码。理论上jsf之类的组件框架多了一个渲染层，有可能对同一套组件库针对不同客户端渲染出不同的响应内容，那就有可能连V都直接复用（但事实上这样做的不多）。至于性能，肯定越底层，抽象程度越低的技术潜在性能越好（但用不好也未必有高性能）。问题是是否值得专门设置这样的团队和相应的管理代价。

3. 70的jser+70的javaer是两个团队，两个专业团队一起做涉及前端的内容肯定比一个纯javaer的团队好。问题是性价比，是否值得在纯软件工程上进行这种投入。对很多市场已经成熟的企业应用，展现层做得多炫根本没有加分，最重要的是行业理解，持续快速维护和稳定。

ZK（The leading enterprise Ajax framework）
http://blog.csdn.net/daquan198163/article/details/9304897

不知道楼上各位有没有用过Groovy的SwingBuilder或Griffon

如果java端有动态语言做一个类似SwingBuilder的这样东西来做JSF/ZK等事件驱动型的基于web的RIA方案，我才觉得比起纯js的rest风格的有优势

我知道zk支持groovy，但groovy的角色只是一个js的替代而已，静态语言+XUI的方式个人以为比动态语言描述UI的方式有差距

刚写了一篇帖子http://www.iteye.com/topic/1131255分析了JSP的弊端，就看了ZK框架，感觉和我的想法比较接近，回头研究一下再讨论。

用动态语言还是用XML表达UI，其关键还是是否足够“声明式”。用XML的好处是结构化语言便于设计IDE，另外动态语言的学习成本也是考虑因素。

动态语言除了“声明式”，更容易集成“模板”，“变量”和“事件处理”——
换句话讲，声明式要配置一个执行引擎，动态语言本身的dsl特性更适合声明式结构，动态语言本身就是这个引擎，
可以对比下maven和gradle

类似zk这样的框架<panel><window>这种粗粒度的标签，很快就谈不上优势了，如果说优势，更多的是它提供的css可以让开发漂亮点的ui容易点