JScript 是最适合Ext 的 Server Side 语言

再补充一点。

B/S两端使用js的方式古已有之，为什么至今没有成为主流呢？我认为，除了过去认识不足之外，主要是因为js存在一些先天的不足，妨碍了其在服务器端的运用。比如缺乏标准类库，效率比较低等。其中最主要的一点，我认为是缺乏namespace/package管理，从而无法适应program-in-large（这是为什么我要做pies，并且与jsi主要针对browser不同，pies的目标是包括服务器端的各种js环境的）。而ajax的出现，其实在浏览器端也提出了program-in-large的需求，因此像dojo、ext之类的框架在浏览器部分解决了p-i-l的需求的同时，必然也同时促进了服务器端js的发展。

其实ms社区还有一件事情是可以期待的,那就是dlr 中的jscript,dlr现在规划有四种语言vb,jscript,ruby,python. 其中,vb和jscript是不同以前版本的vb.net和jscript. 将是真正意义的动态语言. 这样,结合asp.net mvc ,我想楼上所说的服务器端的缺陷将不复存在

Hax的建议很中肯。
技术投资需要成本。
无论是jsp、php、asp和ror，都面临javascript前端架构的设计（其它表示层的方案如flex除外）。如何将这些我们掌握的知识点不断重用，一环扣一环地组成知识网络，构建稳健的技术平台，－－都有利成本的快速回收，这相信也是我们所关心的重点。
p.s “下一环”的接力棒我们打算交给Ajax on AIR, 一个基于高性能的开源方案webkit的实现: Adobe  AIR。

呵呵，回来顶一下，我们最关心的毕竟还是投入产出比、开发速度、知识/代码重用，一句话：“多快好省”地开发WebAPP:)

今天在ExtJS forum 搜到一个 Ext.ux.MVC ，这个ux.MVC 又可以完整地“挪用”到服务侧JScript，多省事啊，呵呵，B/S两侧都离 MVC 近了一步；
加上 Ext.ux.RemoteComponent，基于权限的UI呈现也不成问题了……

sp42: 我们也在考察 Adobe Flex/AIR，很是激动人心！

今天又听到一个开发员同事说，服务侧改用 Jscript 后，开发时思维再也不需要在两种不同的语言间切换了

没说项目目标也不谈项目规模的话,讨论用什么语言都是空谈
家庭小作坊式的web应用用shell都可以实现

语言就是那么回事,谁分额大,就使用谁的,要是当年netscape也支持vbscript,后来谁流行也不好说了,语言之间都差不多,重要是好不好用,快不快,用的人多不多

在国家都倡导“环保”的今天，我们的代码为什么就不能“绿色”一点呢（“循环再用”）？
再举一个例子，宜家IEKA家私大家很熟悉，实用可靠是它的特点，如果信得过，是比较可靠的，不在乎怎么包装、璩头。把丰富多彩的用户体验留给表示层。

B/S两端用同一语言很早就有，JAVA的applet就可以算其中之一。不管两边是不是统一用JS来开发，由于JS没有完全公共的规范类库并被广大程序员认可，所以在浏览器这个运行时环境下，不可能像操作系统一样预先装好各种虚拟机来充当预先装好的运行时环境，那么必然导致各种脚本类库的网络装载，这点就极大的限制了这种应用开发的发展。如果浏览器能预先装好各种公共的JS脚本类库，很多事情就好解决了。其实我更觉得不要老抱住JS不放，JS因为很多历史原因有这样那样的问题，也许一门新的语言更适合未来的WEB网络应用。

不知楼上几位是否使用过dorado这个产品