TypeScript or Pure JavaScript?

I was really excited when I got to know that Microsoft had released a new language called TypeScript.

Type, which means better intellisense and type safety that serve the purpose of its existence — scalable.

Why is this important?

  1. Type safety.
    Hate bugs? There’s a joke we talk a lot, which is also a truth: “The weirder the bug is, the stupider mistake we might have made.” And the compiler would now worry about some of these things for us, like typo or forgetting to change a property after copying some code.
  2. Tooling.
    When a project grows, the API might become too complex for the developer himself to remember. Visual Studio provides great experience on JavaScript intellisense by actually running the code in background. But on the one hand, it would usually requires a special rewritten-version of intellisense file. On the other hand, it would become very slow when code lines add up. (I wrote a framework called VEJIS which picks up the powerful intellisense feature of Visual Studio, provides support for classes, interfaces, delegates, etc. But it’s a runtime framework and there’s no type safety. Checkout http://vilic.github.io/vejis/)
    TypeScript makes code navigation much easier and most of the time, we won’t even need to navigate because the information we need is there with intellisense.

Searching articles related to TypeScript would result in many that are comparing it to CoffeeScript and Dart. It’s really weird because some (maybe most) of these articles treats TypeScript the same sort of thing as CoffeeScript simply because both of them compile to JavaScript. And I have even seen an opinion saying: “If you want to build a big application I’d recommend going with CoffeeScript as you end up writing less code.”

WHAT? Maybe that buddy haven’t really met something big enough.

CoffeeScript won’t do things better for people like me, who have been writing JavaScript since day one. People like to talk about the “good part” when it comes to CoffeeScript, but… does it really take more effort for one person who starts with JavaScript to remember how to avoid the bad part than learning a syntactically brand new language?

And actually I have never given the “good or bad part” thing much credit.

So back to the topic, TypeScript or pure JavaScript? Ignoring things other than the languages themselves, I go with TypeScript without hesitate. Because it’s a superset of JavaScript, and it provides much more useful features for larger-scale applications. And, the key point, I write relatively large-scale web applications. However, to use TypeScript in productive environment, there would be more to think about.

  1. Poor IDE and editor plugin support.
    There have been several IDEs with TypeScript support integrated. Visual Studio, of course, would be one of them. But the experience coding using Visual Studio can’t even beat the experience on TypeScript Playground. This really bothers me a lot. No automatic-quote/bracket completion, no snippets, strange indent behavior, etc.
    I haven’t tried TypeScript in WebStorm, maybe it would have done better job. Also ReSharper for Visual Studio may improve the experience according to some comments I’ve seen.
    There are also some plugins for Sublime Text, but… you know.
  2. Poor NPM package and cross-project referencing support.
    Actually TypeScript is capable generating definition files so that it should have been friendly to these things. But the reality is not that awesome…
    I have proposed a convention on distributing TypeScript-written NPM package, and hoping it would make things better.

If finally you choose TypeScript, here’s some information and techniques that might help.

  1. Definitions of popular JavaScript libraries.
    I don’t have any crush on open source, but here open source does it right. So far most of the declarations I need for specific JavaScript libraries can be found in DefinitelyTyped, and it’s becoming of better quality and of larger covering.
    You may install the declarations though NuGet on Visual Studio, to make things work after installation, try to refresh the solution tree.
  2. Temporary “best” practice for cross-project referencing in Visual Studio.
    In project properties page TypeScript Build tab, check “Combine JavaScript output into file” (and specify a file name) and “Generate declaration files”.
    Create a “.d.ts” file in parent project and add the declaration file generated by sub project to it as a reference.
    Visual Studio would compile all “.ts” files included in the project into the JavaScript file specified, so make sure other test files are excluded from the project or you may want to create another project for samples and tests.
    When it comes to NPM packages, I haven’t figure out an acceptable way. But following that convention I mentioned earlier in this post, I may try to write an extension for Visual Studio which would pick up declaration files automatically, wrap it up with ambient module name and add the modified declaration file into the project that’s using that module. It would also be useful even if we are using these packages ourselves without publishing it to npmjs.org only. (BTW, symlink would save you hours if you didn’t know.)

I have now a symptom trying to make everything typed, it slows me down starting up coding a project, but speeds my lines up once the skeleton completes. Hope you enjoy writing in TypeScript if you need it.

(BTW it would be great if TypeScript add support for await/async based on Promise.)

TypeScript 小感

今天在一个Windows Phone的论坛看到微软出了个TypeScript, 瞬间想到高中时期自己构想的InviScript和Prever 2… 不过后来因为种种原因, InviScript只是停留在了构想上, 而Prever 2也在开发初期流产. 不过后来取代InviScript的, 则是VEJIS.

很高兴的是, 自己, 当然也一定是很多当时和我面临同样问题的人的设想, 最后被很好的实现. 其实Google也有一个叫Dart的语言, 不过与和InviScript的相似度赶TypeScript和InviScript的相似度就差太多了… 而且我个人也不喜欢Dart的语法, 感觉抛弃了很多JavaScript的精髓.

TypeScript和InviScript应该说都是JavaScript的超集, 并且相同的, 最终都会编译成JavaScript. 这也是我为什么取名为InviScript的原因. 意为INVIsible SCRIPT. 只在开发过程中存在.

不过同样高兴的是, 我选择了一个对于我个人而言, 更现实的实现, 即VEJIS. 虽然独立开发完InviScript也并非不可能, 但成本显然太过高昂…

VEJIS通过各种各样的函数, 从语法层面加强了JavaScript的功能, 提供了可以媲美甚至超过TypeScript的类/类型/模块工具, 当然因为VEJIS是运行时的脚本库, 代价就是一定的性能损耗. 这也限制了VEJIS的运用场景. 但就目前的实践经验来看, 在正确使用VEJIS的情况下, 这种影响是可以忽略不计的.

现在正在开发VEJIS 0.5, 重写了核心代码, 并提供了更多, 更具扩展性的功能. 甚至是delegate_, 虽然还没有决定是否会最终使用. 不论最终是中间语言形式的TypeScript更容易被接受, 还是运行时的VEJIS, 都一定程度反应了Web开发的趋势. 这点上, 我觉得Franky或许不会永远是对的. 😛