本文共 2512 字,大约阅读时间需要 8 分钟。
今天看到了 的消息。与同事们对 TypeScript 展开了讨论。本文记录一些个人的想法。
理想的 JavaScript 开发模式
其实早在 TypeScript 发布早期的时候,我就已经开始关注这个语言。因为在2012年初时,我需要为 Rafy/OEA 平台选型编写 Web 端自动界面生成框架:Rafy.js。而这个客户端框架需要基于一些流行的 JS 库来进行开发,当时选型的重点就是选择哪一个基础框架。
当时,我期望能找到一种可以编写大型 JavaScript 框架程序的开发模式。理想情况下,这种开发模式需要:
上面说的这些要求,对于强类型的 .NET、Java 开发来说,其实都是最基本的。但是,对于弱类型的动态语言 JavaScript 来说,却不是易事。弱类型、动态的特性,导致如果不到运行时,就很难确定一个变量的具体类型,所以也就很难提供代码提示、重构等。从我开发 JavaScript 的第一天开始,我就一直被这些问题困扰,希望未来有一天能有技术解决它们。
Rafy.js 的基础框架选型
当时在编写 Rafy Web 前端框架时,为了解决上述的问题,我挑选了几个方案。其中一个就是 TypeScript!我经过试用后发现,强类型的 JavaScript,确实可以解决这些困扰。但无奈的是,当时的 TypeScript 只是一个刚出生的婴儿,版本号 0.8,连第一个正式版本都没有发布,实在不敢用在真实项目上,由于项目的时间要求,所以不得不放弃了这个语言。
此外,我也考察了几个 JS 框架,最终选定了 ExtJs 4。一是因为我要做的是 SinglePageApplication 的 Web 界面框架,而 ExtJs 4 中带了大量的界面控件,非常方便使用;其次,ExtJs 4 提供了客户端的实体模型,这可以与 Rafy 服务端实体可以更好地结合起来。更重要的是,ExtJs 4 带来了全新的,这解决了面向对象设计的基础设施问题。虽说如 prototype.js 等其它框架也或多或少地支持了部分的面向对象设计,但是 ExtJs4 的类型系统,无疑是支持得最全面的:命名空间、封装、继承、接口、静态、单例、类型引用管理。所以,Rafy.js 最终是基于 ExtJs4 来构建的。
下面是当时 Rafy.js 开发完成后的框架类截图:
注意到,为了更好地解决开发过程中的上述问题。我们不得不人为地添加了一个《Javascript 类库开发规范》。该文档中的内容其实还是约定了一些封装、继承、多态的编写约定(ExtJS 给出的面向对象类型系统同样不完美)、以及一些代码的规范。这些问题,其实完全可以从语言、工具的角度解决,但是我们不得不人工约定、人工检查!
虽然 ExtJs4 大体上解决了面向对象设计的问题。但是由于重构困难,编写低效,导致 Rafy.js 的第一个版本只写了几千行,就已经感觉到维护起来很吃力了。
TypeScript
上面说了这么多,无非就是想表达:强类型很重要、重构很重要、工具很重要。而这些正是 TypeScript 语言设计的主要目标:“As we look to the 2.0 release, we 're focusing on two goals in addition to our main goal of bringing good tooling to JavaScript development. The first is to align with ES6…….“
先来说明一下,TypeScript(强类型 JavaScript)的优势:
这正是我想要的东西,也是开发大型 JS 项目的利器。
但是,TypeScript 并不适应于所有的开发人员、所有的项目,下面是 TypeScript 适应的场景:
下面是 TypeScript 不适应的场景:
一些简单的、不需要 OOD、灵活性高、动态性高的代码就不适合选择 TypeScript。例如一般性的 Web 应用或站点的前端开发,这种页面级的逻辑往往编写在页面中,即简单,也不需要 OOD;再如,JQuery 框架的开发,这种框架的目标是灵活、方便、动态,而不是面向对象,所以也不太适合,所以 JQuery 框架应该不会使用 TypeScript 来重写。
目前,TypeScript 已经发布了 1.4 版本。打开 Visual Studio 2013 的扩展管理器,即可安装:
接下来的计划
接下来,我将使用 TypeScript 来把 Rafy.js 重新编写。在正式改 Rafy.js 之前,我还会把之前做的这个 Web 游戏《》改造一下试试。
敬请期待。
转载地址:http://zsozx.baihongyu.com/