讨论一下最新一期TW技术雷达关于JSF的建议

57 views
Skip to first unread message

liyin...@gmail.com

unread,
Aug 9, 2014, 3:29:27 AM8/9/14
to agilechina
各位,
最新一期TW技术雷达继续唱衰JSF( http://www.infoq.com/cn/news/2014/08/thoughtworks-radar-july-2014   http://www.thoughtworks.com/radar#/ )
  • (107)JSF依然停留在Hold位置,ThoughtWorks认为“JSF是有缺陷的,因为它试图将HTML、CSS和HTTP抽象出来,而这与现代的web框架所做的是相背离的”。
本人最近一年多都在关注和使用一个叫做ZK的Web框架(http://www.zkoss.org/ ),它是RIA领域的JSF竞争对手,主要卖点是纯Java的透明化AJAX开发
正如TW对JSF的批评,RIA框架都是“试图将HTML、CSS和HTTP抽象出来”的,但是我并不认为这是反动的,抽象的好处显而易见。


Bo Yang

unread,
Aug 9, 2014, 4:25:30 AM8/9/14
to agile...@googlegroups.com
Broken Abstraction.

我没什么理论好说。根据我的经验,企图从程序员手中拿走控制权的做法,最终除了增加额外的复杂性外,没有任何正面收益,它不过是不(屑)写代码的人的恐惧的产物。

    致


杨波


--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛中的“敏捷中国”论坛。
要退订此论坛并停止接收此论坛的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

皮宇

unread,
Aug 9, 2014, 5:01:06 AM8/9/14
to agile...@googlegroups.com

是否使用ria框架应该是由多方需求决定,包括不限于:工期,需求复杂度,性能和浏览器兼容性,工程师的能力。
假设你是一位架构师,要做一个抽象HTML,CSS,和HTTP的框架,A团队说,我们需要Dom与js object双向绑定,B团队说,我们需要兼容IE6 和旧版本的Opera,C团队说,我们需要高性能,D团队说,我们要能够很容易的换肤。试问,你会如何做?
距我所知目前没有神马东西能同时满足上述4个需求。多数都是各有利弊。
如果想做一个神马场景都能用的东西最后做出来的一定是神马场景都没法用的废柴。

Joseph Tseng

unread,
Aug 10, 2014, 3:18:30 AM8/10/14
to agile...@googlegroups.com
所以放弃吧, 不要做一个神马场景都能用的东西。   越通用越难用,最后不过是又发明了一门新的通用语言,复杂性没有降低。

Joseph Tseng

liyingquan

unread,
Aug 10, 2014, 10:59:11 AM8/10/14
to 皮宇, agilechina
你说的这几个方面,除了性能,其它恰好是ria可以帮助解决的

---原始邮件---
发件人: "皮宇"<ds3...@gmail.com>
发送时间: 2014年08月09日 17:01:01
收件人: "agilechina"<agile...@googlegroups.com>;
主题: Re: [agilechina] 讨论一下最新一期TW技术雷达关于JSF的建议

是否使用ria框架应该是由多方需求决定,包括不限于:工期,需求复杂度,性能和浏览器兼容性,工程师的能力。
假设你是一位架构师,要做一个抽象HTML,CSS,和HTTP的框架,A团队说,我们需要Dom与js object双向绑定,B团队说,我们需要兼容IE6 和旧版本的Opera,C团队说,我们需要高性能,D团队说,我们要能够很容易的换肤。试问,你会如何做?
距我所知目前没有神马东西能同时满足上述4个需求。多数都是各有利弊。
如果想做一个神马场景都能用的东西最后做出来的一定是神马场景都没法用的废柴。

2014年8月9日 下午4:25于 "Bo Yang" <yab...@gmail.com>写道:

liyingquan

unread,
Aug 10, 2014, 11:02:40 AM8/10/14
to Joseph Tseng, agilechina
我都被你们俩说晕了,哪里说要做一个适用所有场景的万金油了,我是想讨论一下tw技术雷达对jsf的否定理由是否充分。
其实我也不觉得jsf做的好,可是ria这个方向不只有jsf

---原始邮件---
发件人: "Joseph Tseng"<air...@gmail.com>
发送时间: 2014年08月10日 15:18:25
收件人: "agilechina"<agile...@googlegroups.com>;
主题: Re: [agilechina] 讨论一下最新一期TW技术雷达关于JSF的建议
所以放弃吧, 不要做一个神马场景都能用的东西。   越通用越难用,最后不过是又发明了一门新的通用语言,复杂性没有降低。

2014-08-09 17:01 GMT+08:00 皮宇 <ds3...@gmail.com>:

是否使用ria框架应该是由多方需求决定,包括不限于:工期,需求复杂度,性能和浏览器兼容性,工程师的能力。
假设你是一位架构师,要做一个抽象HTML,CSS,和HTTP的框架,A团队说,我们需要Dom与js object双向绑定,B团队说,我们需要兼容IE6 和旧版本的Opera,C团队说,我们需要高性能,D团队说,我们要能够很容易的换肤。试问,你会如何做?
距我所知目前没有神马东西能同时满足上述4个需求。多数都是各有利弊。
如果想做一个神马场景都能用的东西最后做出来的一定是神马场景都没法用的废柴。

2014年8月9日 下午4:25于 "Bo Yang" <yab...@gmail.com>写道:



--
Joseph Tseng

Xiao Peng

unread,
Aug 13, 2014, 4:03:56 AM8/13/14
to agile...@googlegroups.com, 皮宇
RIA有客户端方案也有Server段方案。JSF属于Server端的方案。所以,你说“其它恰好是RIA可以帮助解决的”,我觉得你是要说JSF或者ZK等Server端方案,因为客户端方案当然可以解决,而且也是目前的趋势(AngularJs, Ember)。这个事情上升到理论可能争议会更大,所以大部分程序员(比如我)可能干脆就说老子不愿用。如果非要探寻原因,不论是那种方案最终交给Browser的必须是Html + JS + CSS。而程序员能够进行调试跟踪的也就只有这个环境,那么你的抽象就必须兼容或者极为接近这个环境。

好的抽象必须是掩盖细节,而Browser这个运行平台决定了你不能用引入完整的中间层的方式掩盖细节。比如JSF中加一个Button<h:commandButton id="submit" action="success" value="Submit" />,我理解这些就够了吗?不够我还是要明白它最终对应的HTML tag是什么,前端出了问题我还是要debug JavaScript。这种方式从根本上讲就是要失败的。除非有一天Browser变成了真正的平台,你可以在上面直接运行渲染JSF,而不用先转成HTML。不说还有很长的路要走,即便是有那一天,也轮不到JSF上场,肯定是Web Component的天下。

我觉得你是没有看明白皮宇所列的几个问题,或者不清楚前端解决方案是如何处理这些问题的。否则你不会说“恰好可以帮助解决”。事实上,没有一个框架能解决这些问题。即便是目前流行的前端框架,也是各做各的取舍。



Xiao Peng, Developer Practice Lead at AusRegistry
Blog: http://mrcoder.github.io/

liyin...@gmail.com

unread,
Aug 13, 2014, 5:14:59 AM8/13/14
to agilechina
按照你这个逻辑,java和c++也是注定要失败的,除非有一天计算机可以直接运行Java代码而不用先转成汇编指令。
这些不都是抽象的代价么,包括性能的损失,只不过一个好的实现可以让损失可以接受。

.net领域的Silverlight用的好好的,只不过java领域的jsf不争气罢了。


 
发件人: Xiao Peng
发送时间: 2014-08-13 16:03
收件人: agilechina
抄送: 皮宇
主题: Re: [agilechina] 讨论一下最新一期TW技术雷达关于JSF的建议

Jeff Xiong

unread,
Aug 13, 2014, 5:17:39 AM8/13/14
to agile...@googlegroups.com
抽象就必须兼容或者极为接近这个环境
好的抽象必须是掩盖细节

按照你这个逻辑,java和c++也是注定要失败的,除非有一天计算机可以直接运行Java代码而不用先转成汇编指令这些不都是抽象的代价么

理解力呀理解力。

liyin...@gmail.com

unread,
Aug 13, 2014, 5:21:45 AM8/13/14
to agilechina
Jeff看邮件不认真吧,我针对的是“这种方式从根本上讲就是要失败的。除非有一天Browser变成了真正的平台,你可以在上面直接运行渲染JSF,而不用先转成HTML。

服务端AJAX框架就是把html/css/js看做web领域的汇编啊。


 
发件人: Jeff Xiong
发送时间: 2014-08-13 17:17
收件人: agilechina
主题: Re: Re: [agilechina] 讨论一下最新一期TW技术雷达关于JSF的建议

Bo Yang

unread,
Aug 13, 2014, 5:26:51 AM8/13/14
to agile...@googlegroups.com
我简直怀疑你不写代码!

html/css/js不是汇编,是源代码,是你要调试的代码,是程序员需要去打交道的代码。JSF之类的框架只要解决不了这个问题,必然被写代码的程序员骂。

其实补齐jsf的缺陷很简单,做一个浏览器运行你的jsf代码。然后你就发现jsf的理论就是块破布,是没事找事的抽象。

    致


杨波

liyin...@gmail.com

unread,
Aug 13, 2014, 5:55:45 AM8/13/14
to agilechina
再确认一下RIA框架指的什么,
最早RIA概念很明确,基本就等价于Flex,
后来陆续出现了微软WPF Silverlight和Java阵营的一大堆:JSF、ZK、GWT(Vaadin、GXT)、JavaFX,
最近又开始流行前端MVC(Angular等),

其实这些技术区别很大,但目标一致——高效率的开发高交互性、界面复杂的企业应用,
实现的方式就是抽象和组件化,让开发人员不再直接编写最终代码(HTML、JS、CSS),而是基于抽象的Web组件来搭建用户界面,

因此我其实不认为JS MVC算RIA,因为它不是组件化开发。

回到前面的问题,
>我觉得你是没有看明白皮宇所列的几个问题,或者不清楚前端解决方案是如何处理这些问题的。
>否则你不会说“恰好可以帮助解决”。事实上,没有一个框架能解决这些问题。即便是目前流行的前端框架,也是各做各的取舍。
>皮宇列的问题:
>是否使用ria框架应该是由多方需求决定,包括不限于:工期,需求复杂度,性能和浏览器兼容性,工程师的能力
>假设你是一位架构师,要做一个抽象HTML,CSS,和HTTP的框架,A团队说,我们需要Dom与js object双向绑定,B团队说,我们需要兼容IE6 和旧版本的Opera,C团队说,我们需要高性能,D团队说,我们要能>够很容易的换肤。试问,你会如何做?

为什么我觉得RIA恰好可以帮助解决皮宇列的几个问题:工期,需求复杂度,性能和浏览器兼容性,工程师的能力
其实很好理解啊,工期靠开发效率解决,需求复杂度靠组件化解决,浏览器兼容性靠抽象和优秀的实现解决,
工程师能力问题,也是因为抽象把工程师从底层代码开发中解放出来。
至于什么Dom与js object双向绑定,不就是MVVM么,ZK和Silverlight都默认支持的。

当然这一切的前提是RIA的实现要足够好,否则也只是美好的理论。

 
发件人: Xiao Peng
发送时间: 2014-08-13 16:03
收件人: agilechina
抄送: 皮宇
主题: Re: [agilechina] 讨论一下最新一期TW技术雷达关于JSF的建议

皮宇

unread,
Aug 13, 2014, 6:24:35 AM8/13/14
to agile...@googlegroups.com

要解决跨浏览器 跨平台  只用一种技术,目前就不可能,未来也不大可能,所以抽象出来就只能是死路一条。
PC端flex是跨浏览器,但移动端呢?js CSS HTML是跨平台 但IE6 opera呢?这都是前车之鉴。

Bo Yang

unread,
Aug 13, 2014, 6:35:12 AM8/13/14
to agile...@googlegroups.com
跨所有平台,本来就不大可能,而且成本是个问题。实际点的要求,是跨主要的平台,剩下的,如果重要,做native的client也不是不行,成本和收益的权衡而已。正是基于这个现实,server端剥掉GUI的逻辑成为潮流。

重点是jsf这种技术到底做了啥?(难道不就是把其它技术包了一层皮打包到一起?)好用过吗?过去不好用,凭什么相信它将来会好用?

对我们程序员来说,如果我用jsf要用好,我不得不掌握好HTML/css/js,那么我为什么不直接用它们?我闲的没事干么?


    致


杨波

Xiao Peng

unread,
Aug 13, 2014, 8:19:21 PM8/13/14
to agile...@googlegroups.com
本来是个挺好的话题,你的理解力和错误的引申快把它引向吵架了。

如果你仔细读一下我的原文,我谨慎地使用了“Browser这个运行平台决定了你不能用引入完整中间层的方式掩盖细节”这样的描述。Java可行是因为它引入了完整的中间层,你可以在这个中间层之上完成所有被支持的操作和开发活动。Silverlight/Flex也算是引入了较为完整的中间层,因为它门不需要进一步转换为HTML/JS/CSS。所以,我不会说从技术上讲Silverlight/Flex注定要失败。即使最终还是失败了,但是未来还有可能以别的形式再出现。

Jeff下面帮你引用了两句话也是理解这个问题的关键。当然你要放到Browser的背景下去理解。如果你理解了在Browser这个平台上做抽象和计算机平台上做抽象的区别,你就不会说是别人看邮件不认真了。

Xiao Peng, Developer Practice Lead at AusRegistry
Blog: http://mrcoder.github.io/


liyin...@gmail.com

unread,
Aug 13, 2014, 9:59:50 PM8/13/14
to agilechina
“Browser这个运行平台决定了你不能用引入完整中间层的方式掩盖细节 ”
Java可行是因为它引入了完整的中间层…… Silverlight/Flex也算是引入了较为完整的中间层”


 
发件人: Xiao Peng
发送时间: 2014-08-14 08:18
收件人: agilechina
主题: Re: Re: [agilechina] 讨论一下最新一期TW技术雷达关于JSF的建议

刘松

unread,
Aug 14, 2014, 10:50:42 AM8/14/14
to agile...@googlegroups.com
html/js/css能够自说明、足够正交。JSF破坏了这套体系,捡了芝麻丢了西瓜。

刘松

unread,
Aug 14, 2014, 11:09:36 AM8/14/14
to agile...@googlegroups.com
而且,JSF封装了交互和通信,还不如REST风格让人痛快。

再者,java这个略显老旧的编程语言,对前后台逻辑的表达上,也不具优势。
我指的是相比前台基于js的框架(angular,react..)、其它语言(coffee、dart、elm),或跟进html/http规范上。在后端更有一堆优秀的竞争者。

也许,人用的熟的话,用JSF能快速开发出规模不大、业务模式单一的企业系统。
但如果想把东西做出彩,想深耕细作,JSF绝对是个绊脚石。
从这个角度看,Extjs也是这个德行。

Jeff Xiong

unread,
Aug 17, 2014, 10:14:47 AM8/17/14
to agile...@googlegroups.com
我想起几年前陶文给我介绍过另外一种技术,都忘了是什么茬儿了,总之意思就是一种基于Ruby的DSL,用来描述web UI的呈现布局什么的。我当时就跟他说的,描述web UI的呈现和布局,这样的DSL早就有了,一个叫HTML,一个叫CSS。我完全能理解有人不熟这些DSL,但是很明显你要紧螺丝又不熟螺丝刀怎么用的话你就应该去学会用螺丝刀,而不是变着法儿的使锤子来紧螺丝。

李建业

unread,
Aug 18, 2014, 10:19:38 PM8/18/14
to agile...@googlegroups.com
硬要走这条路的东西太多了,有人记得GWT么?

在 2014年08月17日 22:14, Jeff Xiong 写道:
我想起几年前陶文给我介绍过另外一种技术,都忘了是什么茬儿了,总之意思就是一种基于Ruby的DSL,用来 描述web UI的呈现布局什么的。我当时就跟他说的,描述web UI的呈现和布局,这样的DSL早就有了,一个叫HTML,一个叫CSS。我完全能理解有人不熟这些DSL,但是很明显你要紧螺丝又不熟螺丝刀怎么用的话 你就应该去学会用螺丝刀,而不是变着法儿的使锤子来紧螺丝。



html/js/css能够自说明、足够正交。JSF破坏了这套体系, 捡了芝麻丢了西瓜。


RIA 有客户端方案也有Server 段方案。JSF属于 Server端的方案。所以, 你说“其它恰好是RIA可以帮 助解决的”,我觉得你是要说 JSF或者ZK等Server 端方案,因为客户端方案当然可 以解决,而且也是目前的趋势 (AngularJs, Ember)。这个事情上升到理论可能争议会更大,所以大部分程序员(比如我)可能干脆就说老子不愿用。如果非要探寻原因,不论是那种方案最终交给 Browser的必须是 Html + JS + CSS。而程序员能够进行调试跟踪的也就只有这个环境,那么你的抽象就必须兼容或者极为接近这个环境。

好的抽象必须是掩盖 细节,而Browser这个运 行平台决定了你不能用引入完整 的中间层的方式掩盖细节。比如 JSF中加一个Button<h:commandButton id="submit" action="success" value="Submit" />,我理解这些就够了吗?不够我还是要明白它最终对应的HTML tag是什么,前端出了问题我 还是要debug JavaScript。这种方式从根本上讲就是要失败的。除非有一天Browser变成了真正的平台,你可以在上面直接运行渲染JSF,而不用先转成 HTML。不说还有很长的路要 走,即便是有那一天,也轮不到 JSF上场,肯定是Web Component的天下。

我觉得你是没有看明 白皮宇所列的几个问题,或者不 清楚前端解决方案是如何处理这 些问题的。否则你不会说“恰好 可以帮助解决”。事实上,没有 一个框架能解决这些问题。即便 是目前流行的前端框架,也是各 做各的取舍。



Xiao Peng, Developer Practice Lead at AusRegistry
Blog: http://mrcoder.github.io/


2014-08-11 0:59 GMT+10:00 liyingquan <liyin...@gmail.com>:
你 说的这几个方面,除了性能,其 它恰好是ria可以帮助解决的

---原始邮件---
发件人: "皮宇"<ds3...@gmail.com>
发送时间: 2014年08月09日 17:01:01
收件人: "agilechina"<agile...@googlegroups.com>;
主题: Re: [agilechina] 讨论一下最新一期TW技术雷达关于JSF的建议

是 否使用ria框架应该是由多方 需求决定,包括不限于:工期, 需求复杂度,性能和浏览器兼容 性,工程师的能力。

假设你是一位架构师,要做一个 抽象HTML,CSS,和 HTTP的框架,A团队说,我 们需要Dom与js object双向绑定,B团队说,我们需要兼容IE6 和旧版本的Opera,C团队 说,我们需要高性能,D团队 说,我们要能够很容易的换肤。 试问,你会如何做?
距我所知目前没有神马东西能同 时满足上述4个需求。多数都是 各有利弊。
如果想做一个神马场景都能用的 东西最后做出来的一定是神马场 景都没法用的废柴。

2014年8月9日 下午4:25于 "Bo Yang" <yab...@gmail.com> 写道:
Broken Abstraction.

我没什么理论好说。 根据我的经验,企图从程序员手 中拿走控制权的做法,最终除了 增加额外的复杂性外,没有任何 正面收益,它不过是不(屑)写 代码的人的恐惧的产物。

    致


杨波


2014-08-09 15:29 GMT+08:00 liyin...@gmail.com <liyin...@gmail.com>:
各 位,

  • (107)JSF依 然停留在Hold位 置,ThoughtWorks 认为“JSF是有缺陷的,因为 它试图将HTML、CSS和 HTTP抽象出来,而这与现代 的web框架所做的是相背离 的”。
本人 最近一年多都在关注和使用一个 叫做ZK的Web框架(http://www.zkoss.org/ ), 它是RIA领域的JSF竞争对 手,主要卖点是纯Java的透 明化AJAX开发
正 如TW对JSF的批评,RIA 框架都是“试 图将HTML、CSS和 HTTP抽象出来”的,但是我 并不认为这是反动的,抽 象的好处显而易见。
--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了 Google网上论坛中的“敏 捷中国”论坛。
要退订此论坛并停止接收此论坛 的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了 Google网上论坛中的“敏 捷中国”论坛。
要退订此论坛并停止接收此论坛 的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout
--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了 Google网上论坛中的“敏 捷中国”论坛。
要退订此论坛并停止接收此论坛 的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com

要查看更多选项,请访问https://groups.google.com/d/optout
--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了 Google网上论坛中的“敏 捷中国”论坛。
要退订此论坛并停止接收此论坛 的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了 Google网上论坛中的“敏 捷中国”论坛。
要退订此论坛并停止接收此论坛 的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout
--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了 Google网上论坛中的“敏捷中 国”论坛。
要退订此论坛并停止接收此论坛的电 子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛中的 “敏捷中国”论坛。
要退订此论坛并停止接收此论坛的电子邮件,请发送电子邮 件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout
--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛中的“敏捷中国”论坛。
要退订此论坛并停止接收此论坛的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout
--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛中的“敏捷中国”论坛。
要退订此论坛并停止接收此论坛的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout
--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛中的“敏捷中国”论坛。
要退订此论坛并停止接收此论坛的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout


-- 
-----------------

Best Regard,

李建业

Bo Yang

unread,
Aug 18, 2014, 11:54:45 PM8/18/14
to agile...@googlegroups.com
我之前的公司就用过GWT,还继续在上面封装了一层。

这东西,从理论上来说还是完善的——提供了在浏览器上的类本地的图形库;还提供了抽象的穿透机制JSNI。这点比JSF强多了——JSF就像是个糊弄人的粗制滥造品。但我前公司最后放弃了这东西,混杂着人事变动(力推这东西的架构师走掉,我进去后没多久能维护这东西的最后一个工程师也走掉了。)。原因大致有如下两点:

1. 修改太困难,例如table里cell能放什么东西。本身不算是框架的问题,但喜欢这东西的人往往就喜欢封装了再封装,到某个时候某种table里cell里能放的东西就限定得很死了,改动这种能力要牵涉的地方就太多了。另外,BA之类的总会有一堆很小的修改的愿望。如果代价低通常team会选择满足他们。但在这种架构下,小修改往往变得麻烦。

2. 怎么跟上浏览器的变化。这就需要不停更新GWT的版本,但1.0到2.0的话,怕是都得废了。因为封装得深(GWT本身就算是深封装了),你不大可能自己修改它。不像单纯的浏览器polyfill。如果只是浏览器新feature还好,不用就是了;可是有时新浏览器会带来新的bug,或者什么限制改变了原来不是问题的东西变成bug了。

当然,所有这些问题,只要有一个资源就可以解决了——GWT的专家。噢耶,这是常见的答案,也是我最讨厌的答案。GWT专家意味着他同时是Java、Javascript、CSS、HTML、浏览器和编译器专家。我们还是选择其它纯浏览器端的技术吧。

我问过同事还有领导为什么选了个这么麻烦的技术,原因大致分为两种:
1. 政治原因。架构师喜欢,很能说,很能画饼。
2. 公司定位。考量架构时高层认为自己是面向企业领域的,认为需要控件、重用,不需要大量的UI修改;甚至有种中央team完成一切,应用team改改配置的理想。不幸的是,不久就变成UI必需时髦了。如果这选政治的话,那就都是政治原因了。

顺便说一下,写代码的同事里没人喜欢这种东西。我的理解是这样的:客户给的是需求,程序员最核心的工作是把需求映射到代码的变化中去,技术太拐弯抹角就会招人恨,谁的时间都很宝贵,不要让人在没用的东西上浪费精力。

    致


杨波

Xiao Peng

unread,
Aug 19, 2014, 8:21:52 PM8/19/14
to agile...@googlegroups.com
GWT自己的报告里面说89%的团队希望在下一个项目中继续使用GWT(https://vaadin.com/gwt/report-2012),91%的团队认为效率有所提高(https://vaadin.com/gwt/report-2013),不知道这个应该怎么看?

固然可以从样本的角度认为里面有一些水分,但是这个数字还是挺让我吃惊的。

Xiao Peng, Developer Practice Lead at AusRegistry
Blog: http://mrcoder.github.io/


Bo Yang

unread,
Aug 19, 2014, 9:30:17 PM8/19/14
to agile...@googlegroups.com
我认为GWT的报告应该没有作假。按照前面刘松兄台的说法,这类框架,至少适合“规模不大、业务模式单一的企业系统”。据我从很多人那儿听来的说法,欧美企业,对于UI往往不会那么斤斤计较。这个和日本企业及互联网企业不同:日本企业会傻计较,互联网企业不在UI上精耕细作就没竞争力。

而我的经历,更多的是:人算不如天算。推动者期待的方向和实际的结果偏离了。

当然,如果允许我无礼随意推测的话,就是人的惰性,会喜欢用自己熟的东西。GWT、JSF、Wicket之类的都是Java世界的爱好,AngularJS、Backbone、Dart就是浏览器世界的创作了。在我看来,必定是最接近你运行上下文模型的工具最好用了,改变模型是削足适履,必定有匹配阻抗,尽管在很多情况下,这个阻抗不是个问题。其次,这个问题里,还有一个人力资源的问题:你觉得是在浏览器端混的人和在Server端混的人,谁对浏览器的理解好?哦,到了最后,还是这个——你需要精耕细作吗?

    致


杨波

anders lin

unread,
Aug 20, 2014, 12:16:28 AM8/20/14
to agile...@googlegroups.com
兄弟,认真就输了。

1.TW的报告代表了其一家之言,可以作参考,研究TW评价的出发点和依据,但绝对没必要奉为上经。
2.JSF或者ZK自有其市场和用户群体。
   不同企业,不同市场要求对开发者要求不同。开发者能力和风格喜好造成了选择上的差异。
   就好比买车,喜欢自动挡就买自动挡,喜欢手动挡就买手动挡,再不行弄俩手自一体。喜欢手动挡的人常说的就是自动挡耗油。你自己在市区开自动挡舒服就可以了,那点油钱换舒适有何不可。
   我之前单位用JSF很欢乐,顾问单位用ZK非常high。
   
BTW,别说JSF这样的应用开发框架,我还见连jquery都不喜欢的人,只喜欢自己基于HTML、CSS和JS的API搞。你说这给怎么说呢?

anders lin

unread,
Aug 20, 2014, 12:20:55 AM8/20/14
to agile...@googlegroups.com
米国不少单位用CA Plex工具(不知道国内有几个人听说过)开发,UI全部生成好的,没有那么多定制,没有那么多花哨界面。
开发人员老老实实关注功能实现,快速的将用户需求实现,而不是在那里花大把时间整HTML和CSS。


2014-08-20 9:30 GMT+08:00 Bo Yang <yab...@gmail.com>:

Bo Yang

unread,
Aug 20, 2014, 12:47:01 AM8/20/14
to agile...@googlegroups.com
认真永远不会输的。除了谈恋爱(别认真啊)这种,对方要的就是谎言。

我们说一个东西比另一个东西好,或者说比较,总是有上下文的。10年前,你用着JSP,没有一点javascript,所有交互都是阻塞的form提交,都没有什么问题。现在,如果这么做不影响赚钱,那么继续没有问题。但,大概任何一个框架都不会这样宣传。而且,一个东西不够优秀,和不能存活毕竟是两码事。不过这个帖子讨论的是JSF是不是“好”的,不是它有没有人愿意用。

我的观点是Server端的框架永远不会大于浏览器端的框架,因为你的框架最终运行在浏览器端上,服务器端框架也是一个浏览器端框架。这不是说所有浏览器端的框架都比服务器端框架优秀,但因为前面说的原因,服务器端框架必然有些事情做不了。当这些做不了的事情不在你的需求范围内时,它不是个问题。但一旦是,那么就得很奇怪的hack了。

另外,写代码不是讲究模块化吗?即便同样是Java代码我们都得划分,那么HTTP协议这么大的天然分界线,为什么不利用起来?

    致


杨波

Joseph Tseng

unread,
Aug 20, 2014, 3:35:16 AM8/20/14
to agile...@googlegroups.com
我是同意杨波的观点, 就近原则,客户端框架更擅长做客户端的事情。 

但,服务端框架也有一个额外的优势,就是SEO。内容一旦是前端动态生成的,就对SEO不利。  在这个流量就是钱的世界里, 这个优势还真不可忽略。 各位能就这一点补充一下吗?
Joseph Tseng

anders lin

unread,
Aug 20, 2014, 3:53:32 AM8/20/14
to agile...@googlegroups.com
如果要讨论JSF好不好,那就要拿出尺子来了,问题在于用什么的尺子?

尺子不合适,最后的结果就是花了n个人天,得出一个已知的结论

anders lin

unread,
Aug 20, 2014, 4:05:51 AM8/20/14
to agile...@googlegroups.com
JSF本来就是一个服务端框架,其设计思路从一开始就不是struts那套,对界面控件的抽象和封装是其思路的一部分。

服务端框架和客户端本来就是两码事,不存在谁大于谁的概念,更不会是“服务端不会大于客户端”。如你所述,浏览器端和服务端的通讯基于HTTP协议,浏览器端用HTML来展示。当这并不影响服务端采用什么技术。

我不理解你所指“因为你的框架最终运行在浏览器端上,服务器端框架也是一个浏览器端框架。”是个什么样的场景和结论。

我理解,服务端的输出包括(但不限于)HTML,但这无法得出服务端框架也是一个浏览器框架的结论。

刘松

unread,
Aug 20, 2014, 5:56:11 AM8/20/14
to agile...@googlegroups.com
考虑SEO的话,无论前端框架还是后端框架,只要重的(比如前端的angularjs、后端的JSF),都是障碍。

刘松

unread,
Aug 20, 2014, 11:37:37 AM8/20/14
to agile...@googlegroups.com
单说服务器端生成浏览器端代码这个特征,有点像lisp的宏。
lisp对宏的态度大致是,能用函数实现就别用宏。
WEB也是一样,本质上应该由哪层来解决,那就尽量在他那儿解决掉。转由其它层面去解决,就是绕腾。
组件化是html上的一大痛,JSF就是想绕过html组件化的局限,转而在服务器端去解决。这个做法就是避开了问题的本质。而html的Web Component相关规范就是用来解决这个问题的。赞同Xiao Peng说的:“除非有一天Browser变成了真正的平台,你可以在上面直接运行渲染JSF,而不用先转成HTML。不说还有很长的路要走,即便是有那一天,也轮不到JSF上场,肯定是Web Component的天下。”

随着html和浏览器的演化,JSF这种方案存在的意义会越来越小。


anders lin

unread,
Aug 20, 2014, 11:46:11 AM8/20/14
to agile...@googlegroups.com
那我只能“呵呵”了

Xiao Peng

unread,
Aug 20, 2014, 7:30:46 PM8/20/14
to agile...@googlegroups.com
在技术论坛里面“呵呵”是最无意义的了。另外,最好也不要讲太多大道理而落不到实处。笼统到不可能错的观点也就没有什么意义。


Google的爬虫已经开始支持JS了,当然还是有很多限制。这个问题我的理解是,需要SEO的网站和不需要SEO的网站(或者网站的一部分)有一个比较明确的界限。内容为主的网站(或者网站的一部分)需要SEO,业务逻辑为主的网站(或者网站的一部分)则对SEO要求很低。大部分企业应用都属于后面一种。



Xiao Peng, Developer Practice Lead at AusRegistry
Blog: http://mrcoder.github.io/


Joseph Tseng

unread,
Aug 20, 2014, 11:10:04 PM8/20/14
to agile...@googlegroups.com
@肖鹏 的确是这样,to B的企业应用可以无后顾之忧的用前端框架。  不幸的是,我们是做互联网产品,内容居多。
Joseph Tseng

anders lin

unread,
Aug 21, 2014, 1:42:23 AM8/21/14
to agile...@googlegroups.com
这么打比方吧,悍马设计的时候就油耗问题就不是第一要素,你非要用油耗来对比,说悍马不如比亚迪,是个垃圾,开起来不顺。

拜托,人家没有求着你买悍马,你可以买比亚迪啊。

“另外,最好也不要讲太多大道理而落不到实处。笼统到不可能错的观点也就没有什么意义。”

这句话说的好,但是技术讨论的目标是啥?

是随便找把尺子就来技术比较?这个长那个短的。恐怕也没有太多意义,大家平时该干啥干啥。(但如果仅为了酒足饭饱了来这里吐槽,那也不错)。

还是更进一步:既然技术各有千秋,那这些技术各自的适用场景?

比如: JSF就这个样子,比较是企业应用(内部应用)或者做欧美外包。如果在乎前端的展示的,请绕道选别的技术。

比如:“JSF破坏了这套体系,捡了芝麻丢了西瓜”,谁是芝麻谁是西瓜,给看场景。

在很多应用场景中,前端展示效果才是真正的芝麻,你说用你xx前端技术展示效果多炫,技术上多纯洁,客户端服务端多解耦。不好意思,在这里,这些都不重要,用JSF框架,培训一把,同样开发效率比你快,还不用精通HTML,工钱便宜。 


Jacky Li

unread,
Aug 21, 2014, 7:05:42 AM8/21/14
to agile...@googlegroups.com
看到“在这里,这些都不重要,用JSF框架,培训一把,同样开发效率比你快,还不用精通HTML,工钱便宜。 ”这段话之后,我觉得既然世界观不一样,那也没什么好争论的必要了,是吧? @xiaopeng 
Jacky Li

往昔所造诸恶业,皆由无始贪嗔痴
从身语意之所生,一切我今皆忏悔

anders lin

unread,
Aug 21, 2014, 8:04:54 AM8/21/14
to agile...@googlegroups.com
说到我心坎里了。 我的观点已经表达过了。

你们可以继续。

:)

liyin...@gmail.com

unread,
Oct 19, 2014, 1:37:40 AM10/19/14
to agilechina
敏捷宣言说“客户协作 胜过 合同谈判”真是说的太对了,项目招投标这种模式就是个双输的博弈,
事前乙方完全被动,事后甲方完全被动,
双方都知道这个规律后,事情就变得更糟糕了——乙方事前使劲吹、随便承诺,甲方呢也不傻,防电信诈骗一样对待乙方,要求极其苛刻,
双方都打了提前量,必然导致方案过于复杂、报价又低得离谱,最终的失败几乎必然。

这很像谈恋爱时男追女跟孙子一样,结婚过起日子来女的觉得落差太大受不了,觉得被骗,家庭不和。

按照这个逻辑,莫非 高富帅男 配 经济适用女 会和谐一些么? 起码婚前没装孙子婚后不会有落差。


Jeff Xiong

unread,
Oct 19, 2014, 1:43:20 AM10/19/14
to agile...@googlegroups.com
其实关系做得到位的话,事情都是在开始招标之前就决定了,招标文件都是乙方帮甲方写,来投标的其他公司都是陪标的。那你说的这个双输的博弈,指的是哪个阶段呢?

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛中的“敏捷中国”论坛。
要退订此论坛并停止接收此论坛的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

liyin...@gmail.com

unread,
Oct 19, 2014, 1:51:09 AM10/19/14
to agilechina
后面思路偏了,回到敏捷宣言,
客户协作 胜过 合同谈判”如何才能实现呢?  什么情况下才能绕过那个双输的博弈来获得合作机会、建立起信任呢?

我能想到的几个模式:
  • 一是先成为普通朋友、同学或同事关系,建立好感之后不知不觉成为男女朋友,甚至结婚了都想不起来谁追过谁。(翻译成it语言就是:从小项目做起,先通过额度比较小的项目建立起合作发生)
  • 二就是非常规手段——是灌药、灌酒、推倒、顺从,从此过上幸福性生活……这个只在yy小说里有。(翻译:走关系、搞定关键人、内定、陪标)



 
发件人: liyin...@gmail.com
发送时间: 2014-10-19 13:36
收件人: agilechina
主题: 我TMD受不了这万恶的项目招投标流程了

Jeff Xiong

unread,
Oct 19, 2014, 2:00:52 AM10/19/14
to agile...@googlegroups.com
其实你说的“理想模式”,人家就是这么做的。项目刚有个模糊想法的时候,就有乙方开始帮甲方规划设计出主意,这就是逐渐建立好感不知不觉发展感情的阶段。人家把感情都发展完了,招投标其实就相当于个订婚仪式。你自己不知道前面发生了什么,你以为就是“灌药、灌酒、推倒、顺从”,那有什么办法。你也可以换位思考一下,如果你是甲方,有家乙方从来没打听过你需要什么,你不知道该需要点什么的时候从来没帮你出过主意,等你都差不多想明白了突然就冒出来说我可以帮你做这个项目,你会怎么想?反正我觉得换我的话我就会想自己哪儿凉快哪儿呆着去。

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛中的“敏捷中国”论坛。
要退订此论坛并停止接收此论坛的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

liyin...@gmail.com

unread,
Oct 19, 2014, 2:16:30 AM10/19/14
to agilechina
Jeff,情况有很多种哦。
比如潘老板见马老板做的好了,自己就想出了一个主意,然后就立项了,他们不明白其实首先需要搞个咨询项目啊,
看人家就几个网页就把生意做到线上去了,他觉得没什么难的嘛,呵呵

况且也不是很多it公司有业务咨询能力吧,最多有IT咨询的都不错了。你们厂难道养了一批各领域顾问?
 而且你说的那种情况——“项目刚有个模糊想法的时候,就有乙方开始帮甲方规划设计出主意”——其实相当于已经结婚了啊,只不过是老夫老妻在不断生孩子
你们那个招投标其实不是订婚仪式,而是两口子启动新的造人计划。


 
发件人: Jeff Xiong
发送时间: 2014-10-19 14:00
收件人: agilechina
主题: Re: [agilechina] 回复: 我TMD受不了这万恶的项目招投标流程了

Jeff Xiong

unread,
Oct 19, 2014, 2:20:11 AM10/19/14
to agile...@googlegroups.com
你不信,我也没辙。其实我就想指出一件事,你希望一个理想的情景,甲方乙方可以先潜移默化地发展感情,但是其实有这种发展感情的机会你没有去做,你在等着甲方说“我想跟你潜移默化地发展感情哟”。你当然可以继续愤恨为什么鲜花都插在牛粪上,随意。

2014-10-19 9:17 GMT+03:00 liyin...@gmail.com <liyin...@gmail.com>:

liyin...@gmail.com

unread,
Oct 19, 2014, 2:27:45 AM10/19/14
to agilechina
愤恨为什么鲜花都插在牛粪上”是你脑补出来的么? 我哪里表达过这个意思

你的意思是只做熟客喽、建立长期合作关系,这个我没有异议,我们也有这样的客户。
开篇吐槽的是新客户。


 
发件人: Jeff Xiong
发送时间: 2014-10-19 14:19
收件人: agilechina
主题: Re: Re: [agilechina] 回复: 我TMD受不了这万恶的项目招投标流程了

Jeff Xiong

unread,
Oct 19, 2014, 2:30:08 AM10/19/14
to agile...@googlegroups.com
新客户同样有发展感情的机会。再说了,既然是新客户,你就要弄明白自己是个备胎的事实。人家刁难你那都是给你发展感情的机会。

Joseph Tseng

unread,
Oct 19, 2014, 10:46:41 PM10/19/14
to agile...@googlegroups.com
嗯, to B的市场,对新客户就得有备胎的觉悟, 现在吃亏以后才可能发展出感情。 

其实对于企业客户来说,最终是一个短期和长期的权衡。
Joseph Tseng

泥泥

unread,
Oct 20, 2014, 1:52:26 AM10/20/14
to agile...@googlegroups.com
抛开围标、陪标种种潜规则的事情,招投标本身并没有问题。
客户协作 胜过 合同谈判,前者胜过后者,并不意味着后者不重要。
对于有经验的甲方而言,乙方随便吹的风险也是巨大的。不乏销售负责提高期望,工程负责降低期望的事情,这些在专业的甲方面前,绝对是掉分的。
屁股决定脑袋,乙方认为不对的,甲方觉得难道不该这样么。
Reply all
Reply to author
Forward
0 new messages