JScript 是最适合Ext 的 Server Side 语言

我也希望有一个更好的动态语言来取代JS。但是从历史和现实的角度来看，这是不可能发生的事情（除非是整个平台的改变——也就是不是传统的浏览器了，而是像AIR或者Silverlight这样的平台）。就算现在大家对ES4争论不休，也只是对于JS未来发展的一个分歧，即步子要迈多大的问题。在DC等一干人等看来，ES4已经变化太大了，他们更希望看到的是ES3.1。而BE为首的moz和adobe联合阵营则坚持ES4的方向。这其实有点类似过去xhtml2和html5的情形。

所以，我们只能在既有的条件下争取克服这些问题。

公共类库的问题，我们之前已经提到过了。虽然没有公共类库是一个大问题，但是也造成了今天百花齐放的局面，而发展下去必然有几个会成为最主要的事实标准（如prototype），并且会合流（如css selector api）。

而网络装载问题，其实也是有一些解决方案，例如现在许多libraries都提供了脚本的托管和分发。

总之，当前的js虽然有不少缺陷，但是幸运的是，绝大多数问题，还是能找到一些可行的解决方案的。只是我们要在整个社区里对此形成共识，并总结最佳实践。

我承认这些问题都能找到相应的解决方案，但是我想说的是这些解决方案绝对不是最好的，我更希望的是能从浏览器的角度出发去解决这些问题，也就是说希望能从WEB应用的客户端运行时环境上着手解决掉这些问题，如果不从这个层面上去解决，总感觉不论采用如何如何的其他方案解决都显得十分别扭。公共类库现在确实是百花齐放，但是还没到哪个公共类库真正能被绝大部分程序员公认成为主流标准的局面。如果能在浏览器端确立出标准的公共类库无疑对程序员来说是无法抗拒的，同时能降低百花齐放局面带来的内耗，这么多天才来发展一个类库可能会发展的更好。我一直认为WEB应用的真正发展还是在于浏览器的发展，毕竟WEB应用是在浏览器之上构造各种实际应用。由于各种商业团体及组织的利益冲突，目前我们也只能忍受这种次优解决方案拉。

dorado我试用过，确实做的不错，但是从我现有的解决方案中集成他成本过高，而且还在试用FLEX，FLEX除了及个自身缺点，从整体上来说作为企业解决方案还是非常合适的，而且FLEX还足够年轻

这位朋友咧，既然都用JAVA语言来写，为啥不直接用JSP呢？这样不更容易一些？

我曾用过 js 写ASP，写过一些网站。而且也抽像出一个简单的asp框架。
面向对象这块我当时采用了 prototype.js 这个东东（如果是现在，我会选用mootools）。

见 http://www.longthsoft.com

不过这一年内都没有写过ASP了，楼主如果感兴趣可以帮我改进哦，或者告诉我有价值，我会重新改写。
我只是写了一个很简单的东东，因为本来也是只做一个公司的主页，写着写着就出来一些东西了。。。见附件吧（里面有所有的代码）

我说点题外话。
国内有创造力的开发者其实很多，但是大多缺乏推广和宣传能力。sp42是我见过比较善于宣传鼓动的一位，hax也有很好的宣传能力。

其实如果觉得自己认可的开发套路很有推广价值，写一本书是最好的方法。既可以加深自己的理解，也可以帮助其他开发者。

客户端-服务器端全部采用JavaScript是一种很有趣的开发套路，不过在没有全面的文档的情况下，很少有人敢去尝试。《Rails敏捷Web开发》这本书对于Rails的普及起到了非常大的作用，也许将来会有人写服务器端JavaScript开发的书。其实这样的书在Amazon上已经存在，不过讲的是在JVM6上做JavaScript开发的，底层用的是Rhino，可能不是这里的朋友喜欢的组合。

JavaScript其实比Ruby更加动态，Ruby能做的事情JavaScript大多数都能做。不过Ruby写的代码会更加简洁，如果使用Prototype库的话，可以模仿写Ruby代码的方式来写JavaScript。但是JavaScript的一些动态特性妨碍了它的性能表现。具体是哪些动态特性，我们以后再来深入探讨。ActionScript2本来是跟JavaScript非常像的，但是到了ActionScript3，出于一些性能上的考虑，取消了很多动态特性（基于prototype的继承、eval函数等等）。ActionScript3还模仿Java增加了很多静态面向对象的支持，以支持hax所说的program-in-large。现在如果谁还说ActionScript3跟JavaScript是兄弟，那是不了解情况的说法。ActionScript3其实早已投向了Java，跟Java称兄道弟了。JavaScript2到底要向哪个方向发展，这是我们非常关注的一个问题。我和hax等朋友都不希望JavaScript2向ActionScript3的那个方向发展。ActionScript3几乎变成了一种类似Java的静态类型语言，但是却没有提供任何反射机制，这使得meta-programming几乎无法开展，无法做meta-programming会严重影响开发效率。ActionScript3的一些决策在我看来是愚蠢的，可能会成为将来Flex被Silverlight超越的一大原因。

JavaScript最初设计在客户端运行少量脚本的，不需要很高的性能。如果放在服务器端使用，对于并发量低的情况，也许问题不大。大多数中小型企业应用并发量都不高。但是如果做面向Internet的Web应用，并发量会达到一个非常高的水平。JavaScript目前还没有任何服务器端高可用性解决方案。这类应用在服务器端使用JavaScript做开发就是在开玩笑。

浏览器本身的增强确实也很重要，这个是HTML5+JavaScript2的任务，目前各大浏览器厂商以及W3C/ECMA之间还有分歧，希望他们能够尽快解决这些分歧。

还是要说一下，ActionScript3其实就是ECMAScript4（指语言核心特性），因为AS要成为ES的实现是很早就定下来的目标（从AS2开始），当然AS3只是ES4的一个草案的实现。但是要注意到，ES4的草案是基于AS3的。即使AS3跟ES4的最后标准有很多差异，估计Adobe也会快速推出完全符合ES4规范的AS4——因为ES4主要就是Adobe和Mozilla两家主导（大家已经了解Adobe捐给Mozilla一个ES的VM）。这一点我很久之前提到过，而且在ES4的讨论列表里面跳出来问他们是不是过多的向AS3的兼容性妥协。

Yahoo的DC等人显然不喜欢ES4，所以提交给TG1一个ES3.1的提案。当然，暂时似乎没有下文了。微软也有提出一些异议。后来的纷争大家都有目共睹（不过我还是没有时间仔细看……希望1个月后有时间可以加以研究，包括研究现在的ES4的参考实现）。

我想说说我的态度。其实我并非像dlee兄说的那样，不希望JS2（即ES4）向AS3发展。我的态度，其实我也不知道，嗯，是很暧昧的态度，呵呵。一方面我认为也许DC的提案比较现实，先出一个ES3.1比较好，但另一方面，我觉得ES3.1的提案确实保守了一些，应该引入一些更多的特性——ES4里确实有很多很棒的特性。而且，我也充分的理解Moz、Adobe、Opera等的需求，因为他们一个要做XUL应用，一个要做AIR，一个要做Widget等，总之，限制在当前的ES3，那确实是远远不够的。但是步子到底要迈多大，这是个很难权衡的问题。目前的ES4，几乎每个特性单独挑出来都很棒，但是合到一起，却令人怀疑是否过于复杂了。举个例子，ES4里既有package，又有namespace，还有unit（module）……单独看，每个都是必要的，如package解决program-in-large的基本问题；namespace提供一般的namespace机制，提供非常灵活的访问控制（就像其他语言的public/private等，但大大灵活），还有version的能力，另兼有部分annotation的作用，与E4X的namespace（for xml的）无缝结合（E4X又是一个扯不清楚的话题）；而unit是编译单元或Loading单元（有点类似C#的Assembly），似乎也是必要的……但是你见过一个语言同时有这样三种东西的么？这个不是说就不能接受，但至少是个复杂的信号。

关于反射，我要澄清一下，ES4应该会有强大的反射能力和metaprogramming能力的，不会延续AS3的那些限制。Adobe的人大体自己知道自己有什么缺陷的。

浏览器本身的加强，HTML5已经箭在弦上，最重要的MS已经在Working Group内了，分歧迟早会解决。至于ES4，可能就比HTML5难多了。幸好HTML5与ES4是基本独立的事情。

其实我最怀疑的一点是，ES4的目标实在太多。

譬如它把ES4对于ES3的向前兼容放在很高的位置。

另外一面，它又要修正ES3的一些错误，从而必然造成一些不兼容。例如this指向的问题，这可能会是造成移植到ES4后最可能导致问题的特性之一。

虽然ES4的设计者花了很大的功夫保证了最大限度的ES4向ES3的兼容。但是ES4糅合的特性如此之多，譬如吸收了Python的很多特性，同时又引入了类型系统（包括泛型、Nullable——虽然我认为其Nullable的设计不够好），以至于可以说是一种全新的语言，那保留这样的兼容所付出的代价到底是否值得（同时有prototype和class……）？

其实我最怀疑的一点是，ES4的目标实在太多。

譬如它把ES4对于ES3的向前兼容放在很高的位置。

另外一面，它又要修正ES3的一些错误，从而必然造成一些不兼容。例如this指向的问题，这可能会是造成移植到ES4后最可能导致问题的特性之一。

虽然ES4的设计者花了很大的功夫保证了最大限度的ES4向ES3的兼容。但是ES4糅合的特性如此之多，譬如吸收了Python的很多特性，同时又引入了类型系统（包括泛型、Nullable——虽然我认为其Nullable的设计不够好），以至于可以说是一种全新的语言，那保留这样的兼容所付出的代价到底是否值得（同时有prototype和class……）？

JavaScript取得成功一个最大的原因就是它的低门槛。只要学习过一点编程知识（通过C语言甚至是通过Word/Excel中的Basic语言），学习JavaScript几乎不需要花多少时间，一个下午足够了。

当然，我们知道其实要真正把JavaScript用好，水还是很深的，但是这并不妨碍我们使用JavaScript解决自己想要解决的问题。哪怕我们开始写的是dirty的代码，只要它能正确完成功能，谁敢说这些代码完全没有价值？我们总是可以在不断使用这种语言的过程中加深对它的理解，找到编写代码更好的方法。JavaScript允许开发者以一种长时间循序渐进的方式来学习和进步，将学习曲线拉的很平，所以JavaScript对于开发者来说是非常平易近人的。网上流传的很多JavaScript脚本都是由非专业程序员，甚至是由网页设计师开发的。我们虽然可以骂这些家伙的代码写的真烂，但是这其实正是JavaScript取得成功的一大原因。这些很烂的代码确实能够工作，而且向我们展示出了DHTML的巨大潜力，我们总是可以通过修改和重构使得这些代码容易维护。

ECMAScript4（对应JavaScript2）与ECMAScript3（对应JavaScript1.x）兼容是必要的，否则将极大拉高JavaScript的学习曲线，会严重破坏JavaScript取得成功的基础。ActionScript3与ActionScript2不兼容，为过去的ActionScript开发者设置了很高的门槛。Adobe甚至为此在Flash Player中做了两个虚拟机：AVM1（执行AS2代码）和AVM2（执行AS3代码）。ActionScript3是Adobe的私货，Adobe可以按照自己的意愿来处置。但是ECMAScript是公共的，对于ECMAScript的升级，不能采用这样强制性的做法。

ActionScript3的核心类有两套不同的实现：与ECMAScript兼容的基于prototype继承的实现，ActionScript3自己的基于静态面向对象（class/package/extend）继承的实现。
我从Adobe官方的《ActionScript 3.0编程》这本书中摘抄了两段：


ActionScript3通过namespace来设置是否需要与ECMAScript兼容。默认情况下是使用与ECMAScript不兼容的方式，所以不能认为ActionScript3的做法就是ECMAScript4中要求的做法。

另外，ActionScript3的运行环境与JavaScript2差别非常大。ActionScript3是一种编译型语言，编译为swf文件运行于Flash Player中，与Java类似非常依赖使用IDE来做开发。而JavaScript2不需要编译，由浏览器的JavaScript引擎解释执行，开发几乎不需要使用任何IDE。即使存在JavaScript的JIT编译器，使得JavaScript从本质上说也是一种编译型语言，但是它的运行环境和需求仍然与ActionScript3有巨大差别。Adobe强行将自己的一些需求塞入ECMAScript4规范，这是我非常反对的做法。

现有的JavaScript1.x尽管存在问题，但是这些问题都得到了广泛的理解，拜JavaScript语言超级动态特性（不像Java那么死板）所赐，绝大多数问题（包括program-in-large）都找到了适当的解决方案。现存的几乎所有的Ajax/Widget库都是基于JavaScript1.x的，如果升级到一个完全不兼容的JavaScript2，所带来的忙乱和巨大的迁移成本是可想而知的。

ECMAScript4确实解决了很多问题，但是走的太快了，这跟以前的XHTML2的地位有些相似。确实有必要搞一个与现有ECMAScript3兼容，变化不是非常剧烈的ECMAScript3.1，而且未来得到最广泛支持的很可能会是ECMAScript3.1这个版本。或者也可以像UML2那样分成两个部分：基础部分和高级部分。浏览器厂商必须实现基础部分，然后根据自己的具体需求实现高级部分。ECMAScript规范一定要兼顾各大浏览器厂商（当然也包括IE）的诉求，这样最后才能达成对广大Ajax开发者最有利的局面。

ECMAScript4设计的太复杂，一些特性包括我在内的很多人都不喜欢。主要问题是很多新的特性从概念上看似乎缺乏一致性（要支持更好的OOP，还要支持GP），或者彼此重叠，这些直接导致的了学习成本的直线上升。Ruby这门语言的一致性保持得非常好，这是Ruby取得成功的重要原因。设计一门语言，懂得取舍是非常重要的，我感觉ECMAScript设计团队中似乎缺乏设计语言的大师级人物。