So it's an alternative to Node? Sounds incredibly cool, honestly. This:
> Supports TypeScript out of the box.
Seems like a small thing, but it has me interested all on its own. It's a huge pain to set up a whole build process just for TypeScript (which is generally the only preprocessing you need outside of the browser).
Word of warning though - ts-node can be excruciatingly slow. We recently switched a project from using ts-node in our dev environment to compiling with tsc and running with node, and shaved around 5 minutes from our startup time.
Well, that answers something I was wondering about recently.
I noticed in a couple of popular TypeScript (+React fullstack) boilerplates, that they were using ts-node to run the server in production.
Unlike babel-node, there's no mention in the documentation to avoid using it in production - but I figured there'd be performance impact, since it's transpiling on the fly (I suppose just once per require).
More then one second and people will test their code less often. Five minutes and people start relying on the type-checker. Like with the chicken and egg problem, what came first, the type-checker or the need to have a type checker?
It doesn't really help that much with TypeScript native NPM-packages being published with JS and D.TS (TypeScript-definitions) instead of the original source, does it?)
> Supports TypeScript out of the box.
Seems like a small thing, but it has me interested all on its own. It's a huge pain to set up a whole build process just for TypeScript (which is generally the only preprocessing you need outside of the browser).