这是企业应用的技术方向吗？

    做j2ee开发9年了，或许还会做9年甚至更长。

    在过去的9年里感觉一直在做一件很“无聊”的事情，这件事情就是挖空心思、竭尽所能地用html+javascript模仿桌面应用，从外观到操作习惯。这件很无聊的事情现在有一个很"挨踢"的名称"Ajax"，以至于从IBM、M$到大大小小的开发工公司都在研究这个“新技术” 。

    这件很无聊的事情似乎说明两个问题。首先，从企业应用系统的受众来说，桌面程序的风格和操作方式才是他们需要的；另外，目前的web风格和操作方式真的不是他们想要的。从每次j2ee系统发布后，被最终用户骂的狗血淋头，我更加坚信这一点。

    既然如此，我们与其绞尽脑汁钻研ajax，不如改造一下HTML标准，让它内置支持RIA不更好吗？如果html有内置的菜单，那么JS Cook Menu就没有用武之地了；如果html有内置的树结构 ，DTree就不需要了。我很不理解，如此显然而迫切的需求，w3c和各个大公司却视而不见。

    说到html，其实http也不适合企业应用。企业应用很多时候需要一个介于request和session之间的“会话”，我记得seam可以模拟出来，myfaces的tomahawk可以用saveState标签来模拟。同样的道理，我们与其痛苦地走弯路，为什么不升级一下http协议呢？

    不知大家的体会如何？

全世界好几十万的人
靠这些协议
拿着几倍几十倍于你我的工资......
每当一个协议出来

为了实现这个东西大约要用掉几百亿的美金进行开发推广.
你知道ie6已经过时多少年了么?
我们现在开发的软件还是以它为qa标准....汗死....

兄弟，你的意见是什么呢？
本人愚笨，没有听懂。

每个协议都是钱堆出来的.....
上回的协议钱还没争回来之前
厂商是不会考虑新加协议的...

你的意思是:交互性,有状态在根源上得到支持,是吧?
我的观点:
   1.交互性:技术手段是一方面. 认识是另一方面:也就是说能抓住客户的需要,知道多少种交互的方式,正确的选择一种
   2.有状态:通过会话的支持已经做的很好.而组件状态,这不属于协议层的事情.应该属于jsf,seam这些框架实现的
   3.现有的http,html都好,容纳各种方案,但没有那个方案在你说的问题上成为霸主.在java,jsf不会成为霸主,别扭.看好的是ajax+对交互的深刻认识和选择

lz想法是可取的,但是改造http协议,绝不是一朝一夕,几个人能搞定的,需要几个大牛抛砖引玉,完后后人逐渐发展,再到以后的成熟应用,这段时间过去后,不知道我们是不是已经在家养老了

W3C可没JCP那样的效率

google  正在推这件事

html 13年来没有太大的变换，是该改改。

www才20个年头，还很年轻，问题多是好现象。

嗯，深有同感，无论j2ee、php还是rails，都是后台的事。
前台方面，不论taglib、jsf、helper，最终回归到html、js、css甚至http的局限上。
楼上说的没错，这半年来，google一伙正在加速推行这些基础设施的改进，而这些最基本的东西确实不是一时半会就能解决的。

最关键的问题，我认为是组件化，较新的情况是：
html5可以自定义标签，web form增强了标准输入控件，如<input type="date" />，css3也加强了这方面的支持：
http://www.blueidea.com/tech/web/2009/6460.asp

当然这些技术还没有普及，尤其是万恶的ie。

服务器端的组件化，我最近看好ruby的lesscss和erector。

用无状态的模型 去解决 有状态的问题，主流web开发方式不好跨越这个门槛。无状态模型有个好处，使系统的复杂度趋于平和，有利于大型复杂系统的平滑组建。

至于桌面应用的其它特性，只能来一点用一点了。把浏览器（WebView）打包到桌面程序里，好多年前就有前辈这么干了，我觉得还有必要继续尝试。