给 JavaScript 一个体面的外表

在 Ajax 体验大会上，微软的 UI 框架部门的开发经理 Matt Gibbs 谈到了微软对 JavaScript 开发支持的一些计划，核心内容就是从面向对象化特征、Visual Studio.NET 开发工具和.NET Framework 等几个层次对 JS 进行包装，并进一步提升其对 Web UI 体验的支持能力。这个计划的需求来源于 Ajax 的快速发展，JS 作为 Ajax 的中心技术，通过改造它可以较大程度提高 Ajax 开发的产能。

对开发人员而言，开发 JS 往往并不是什么愉快的经历，很多时候被称为“Write Once, Won’t read a life（一次写成，终生不读）”，就是在 ASP.Net Ajax 团队自己进行产品开发的过程中，他们也在调试 JS 时也饱受煎熬。痛定思痛，微软觉得必须要为 JS 增加面向对象特征，按照“急用先上”的原则，首先要增加命名空间和继承的支持。前者是实施大规模项目的基础，如果所有的对象都散落在一个个 function 里面，那几乎等于直接倒退到 10~15 年前的结构化开发，在快速变化的业务面前，管理和组织这些代码就只能对“敏捷”取非了，通过命名空间的梳理作用起码可以给对象一个有效的组织，在这之后再去考虑重用、架构优化之类的事情；后者的作用更明显，没有继承的 JS 代码适合做“一锤子买卖”的项目，虽然有很多现成的框架，但开发过程和早期的 VB 差不多，项目迭代 2、3 个版本后，重写恐怕比“重用”划算的多。

除了面向对象的封装之外，微软还要推出一个面向 JS 的 UI 对象模型，旨在尽量解决现有浏览器兼容性问题和 JS 执行效率问题的基础上，向 JS 开发人员提供类似 C#一样简便的富客户端开发体验，其中包括 Ajax Web 客户端的数据绑定机制和客户端事件多播机制（Multicast）。不过现阶段能够提供开发人员的还仅限于 Visual Studio.NET 环境中的 JS 代码感知能力和 ASP.NET Ajax 1.0 所提供的运行时服务，包括最基本的安全服务：

• 读取用户安全信息；
• 浏览器客户端的远端认证；
• 用户角色信息。

在此次会议上，针对现有 Ajax 框架对浏览历史记录支持不够的情况，微软也着重阐明了要在 ASP.NET Ajax 中增加相应支持的意见，务求让用户在点击 Back 按钮的时候，可以比较的有效的恢复现场，确保不会因为 Ajax 令用户直观上感到困惑。

相信借 Windows 占领绝对用户市场的微软也意识到如果不紧随 RIA 的趋势，那么用户、商业平台和项目机会将会很快被竞争对手夺取，很大程度上来说用户是应用导向型，谁可以把更大比例的 Web 开发人员聚集到自己的平台，谁就更有可能通过技术因素占领市场。既然现在很多 Web 开发人员最关心的是 Ajax 和 JS，那该出手就要出手了。