I have now been developing two projects with TypeScript and thought this would be a good moment to share some of my initial observations (just to get some discussion started):
+ Love the type system. And when generics are added, this is a easy way to add type info to to your code without sacrificing too much of the flexibility that JS has to offer. One of my favorite features is the fact that Interfaces and Modules
+ The generated JS is so recognizable, that I sometimes bug-fix the JS code instead of the TS code. So this is definitely an advantage in figuring out why something goes wrong. I'm happy with plain JS debugging and don't even bother
with generating source maps.
+ The TS compiler is fast (even more so realizing it is running on top of a JS engine) and this makes the run/fix/compile cycles very quick.
- External file modules really need some work. Right now they are not convenient to use, mainly due to the module alias that you are forced to use when accessing one of its exported members. Please allow somehow to import module members into the current scope
without having to use a prefix all the time.
- Enumerations should not compile to numbers, but use strings instead. But I believe this is already on the radar.
- You should be able to set member variables in the constructor signature, but not define them. It makes the code much harder to read if you can define member variables at two different places. So the following approach (like Dart) seems to be nicer to
- Compiler needs some attention. Sometimes it misses type errors or even generates invalid code. Difficult to reproduce, but there has been cases that the _this was not generated while it was being used. Also nested functions are not type checked the same
way as normal functions. But I'm sure these are things that will be fixed on the way.
- HTML interface is bad!!! Not really a TS issue, but by exposing the HTML API in a typed manner it becomes more obvious. Too weakly typed, requiring too many typecasts and too many properties on the global (window) namespace. I now understand why Dart
is coming up with a new API. Of course a TS user library could do the same and wrap the native API into something nicer to use without introducing too much glue.
- One monolithic lib.d.ts file is not a good approach. Should be split into several files, so you can pick what aspect you want to include in your project. For example serverside development should not have the HTML API available by default
or a web worker has only a subset of the full HTML available. But there are many more examples, so a more flexible approach would be nice.
And finally a non-technical observation:
- The Microsoft TS project team itself seems to be smaller and moving at a slower pace than say for example Dart. When I look at the changes made to the source repository and the number of people making these changes, they are only a few. The same is true
when it comes to the interaction of the TS team with the community. Not saying this is necessary a bad thing, but it does leave the impression that this is not (yet) a strategic project for MS.
Of course another reason could be that they are working hard behind the scene and not ready to share the results yet. But even then it would be nice to have more interaction between the MS team and the community.
So far my rambling for today.