I built a non-trivial webapp in nodejs + Typescript but abandoned it due to these issues:
1. You can generate source maps for your TS files, but node can't use them. There is some support for source maps via the node-source-map-support, but it doesn't play well with a lot of stuff out of the box. Just getting accurate stack traces in my logs turned into a project of its own.
2. Most node libraries don't include type definitions, and what is on DefinitelyTyped is more likely than not to be out-of-date and inaccurate. Having the wrong type definitions might be worse than none at all, which means for the most part you'll be declaring a lot of stuff as "any." It makes even preserving the types in your own code difficult, as anything that touches a 3rd-party library is going to come back as the any type without additional annotation.
3. Similar to 2, if you want to use a promise-based approach to deal with the "callback hell" induced by node's continuation passing style, you are probably going to need to use a library that does runtime mutation of the many libraries that don't support promises, which means that any time information you do have about 3rd-party libraries is going to get lost.
4. The last two items, combined with the lack of runtime type checking, means that your types are going to be difficult to maintain and can easily become inaccurate without feedback from the compiler to let you know that something is wrong.
Re 1: This is not a problem with TypeScript, but with Node. It's the same with every to-js-transpiled language. You can use https://github.com/evanw/node-source-map-support to get stack traces for your TS sources.
Re 2: I do agree that this is a problem but remember that it's all just a community effort. You can always create your own type definitions or enhance existing ones and share on the DefinitelyTyped repository. Also, most of the time if a type definition is out of date or invalid, you can just create your own partial typedef for a module with only those several methods you are actually using.
Re 3: IMO it's a feature. By using, for e.g. a bluebird library to wrap third party code in a Promise, you are changing the way how your code is interacting with that library by redeclaring the whole library or some parts of it. TSC is complaining because you've changed the declarations. You have to provide your own type definitions, either inline, or for the whole module.
I've engineered or reviewed several projects that are using TypeScript with success. The teams after initial hiccups are mostly not willing to come back to pure JavaScript now.
I'm not advocating to use TS everywhere and for every project. It all depends. Many factors must be considered but some sort of type checking is usually a good thing to have.
I just built a 3500 line chatbot with the ms bot framework in typescript and my experience was very different.
Source maps in node are working fine for me in intellij. I can set breakpoints in the typescript code and step from there with full inspection capabilities.
The library compat issues you're describing I didn't have. I used what MS recommends or uses itself in the bot framework, which is of course all nicely compatible (e.g. mocha/chai/sinon for unit tests). For promises I used regular ES6 promises, so that wasn't an issue either.
I've run into the same problems with #2 quite a lot, especially in terms of libraries that are on DefinitelyTyped but are either out-of-date, or where the DefinitelyTyped typings are in some way tailored toward a specific module loader choice (node/SystemJS/es6/&c.).
In the end, my solution has been to just use only the DefinitelyTyped typings that work well, and fall back to inserting my own broad, liberal `declare`s for remaining libraries. This has the enormous drawback of effectively opting out of most of the benefits of using TypeScript in the context of those specific libraries, but it seems like a worthwhile trade-off given I keep the benefits throughout a lot of the app.
I haven't encountered #1 personally - this seems to work OK in my experience.
On #3, I've always thought both that "callback hell" was exaggerated and largely called by badly planned code rather than being a fundamental problem with callbacks, and also that Promises are an oversold solution that offer some benefits but are certainly no magic bullet. My code generally uses Promises, but never pervasively. They wouldn't be a dealbreaker by any means.
TL;DR while your criticisms are understandable and valid, they seem relatively minor based on my own experience. Abandoning an app completely seems extreme.
- Much better tooling and editor/IDE integration (I'm using vscode and WebStorm),
- DefinitelyTyped repository and the availability of type definitions,
- It's subjective but TS has better documentation and examples,
Don't get me wrong, the Flow (and React) community is doing a great job and in my opinion Flow is a very good tool for static type checking. The real problem with both is the coverage/quality of type definitions and the amount of time it takes to create typedefs. Right now there are many more typedefs available for TypeScript and the community is stronger and more active.
The alternative refers to an alternative type checking system - Flowtype. Not that the seconds has the async/await and modules. Both repositories are trying to deliver quite similar tools - type checking, es6 + async/awat + import syntax and linter.
Comments such as this one read to me as a dig at a particular technology the commenter does not like. Sort of a more subtle version of "Oh, I didn't realize people were still using THAT."
Yes, I think even more so now with the Node Foundation and support for all modern JS syntax (ES6 and beyond). It's being used by mayor players (LinkeIn, Netflix, Medium and Uber to name a few) but also smaller companies (from my personal experience as a freelance developer).
PS Assuming that by web app you mean "the backend for web apps". Otherwise Node would be used 'just' for the build process, together with Webpack and friends.
It's still a popular choice. It's very easy to get a simple API or service up and running in production with node, especially if you don't try and include every new library out there for node projects. Express, Rails, and Flask/Django aren't going anywhere anytime soon since they're accessible frameworks in popular scripting languages.
[+] [-] pyrophane|9 years ago|reply
1. You can generate source maps for your TS files, but node can't use them. There is some support for source maps via the node-source-map-support, but it doesn't play well with a lot of stuff out of the box. Just getting accurate stack traces in my logs turned into a project of its own.
2. Most node libraries don't include type definitions, and what is on DefinitelyTyped is more likely than not to be out-of-date and inaccurate. Having the wrong type definitions might be worse than none at all, which means for the most part you'll be declaring a lot of stuff as "any." It makes even preserving the types in your own code difficult, as anything that touches a 3rd-party library is going to come back as the any type without additional annotation.
3. Similar to 2, if you want to use a promise-based approach to deal with the "callback hell" induced by node's continuation passing style, you are probably going to need to use a library that does runtime mutation of the many libraries that don't support promises, which means that any time information you do have about 3rd-party libraries is going to get lost.
4. The last two items, combined with the lack of runtime type checking, means that your types are going to be difficult to maintain and can easily become inaccurate without feedback from the compiler to let you know that something is wrong.
[+] [-] jsynowiec|9 years ago|reply
Re 2: I do agree that this is a problem but remember that it's all just a community effort. You can always create your own type definitions or enhance existing ones and share on the DefinitelyTyped repository. Also, most of the time if a type definition is out of date or invalid, you can just create your own partial typedef for a module with only those several methods you are actually using.
Re 3: IMO it's a feature. By using, for e.g. a bluebird library to wrap third party code in a Promise, you are changing the way how your code is interacting with that library by redeclaring the whole library or some parts of it. TSC is complaining because you've changed the declarations. You have to provide your own type definitions, either inline, or for the whole module.
I've engineered or reviewed several projects that are using TypeScript with success. The teams after initial hiccups are mostly not willing to come back to pure JavaScript now.
I'm not advocating to use TS everywhere and for every project. It all depends. Many factors must be considered but some sort of type checking is usually a good thing to have.
[+] [-] Joeri|9 years ago|reply
Source maps in node are working fine for me in intellij. I can set breakpoints in the typescript code and step from there with full inspection capabilities.
The library compat issues you're describing I didn't have. I used what MS recommends or uses itself in the bot framework, which is of course all nicely compatible (e.g. mocha/chai/sinon for unit tests). For promises I used regular ES6 promises, so that wasn't an issue either.
[+] [-] lucideer|9 years ago|reply
In the end, my solution has been to just use only the DefinitelyTyped typings that work well, and fall back to inserting my own broad, liberal `declare`s for remaining libraries. This has the enormous drawback of effectively opting out of most of the benefits of using TypeScript in the context of those specific libraries, but it seems like a worthwhile trade-off given I keep the benefits throughout a lot of the app.
I haven't encountered #1 personally - this seems to work OK in my experience.
On #3, I've always thought both that "callback hell" was exaggerated and largely called by badly planned code rather than being a fundamental problem with callbacks, and also that Promises are an oversold solution that offer some benefits but are certainly no magic bullet. My code generally uses Promises, but never pervasively. They wouldn't be a dealbreaker by any means.
TL;DR while your criticisms are understandable and valid, they seem relatively minor based on my own experience. Abandoning an app completely seems extreme.
[+] [-] vnglst|9 years ago|reply
[+] [-] jsynowiec|9 years ago|reply
Usually I tend to lean towards TypeScript due to:
- Much better tooling and editor/IDE integration (I'm using vscode and WebStorm),
- DefinitelyTyped repository and the availability of type definitions,
- It's subjective but TS has better documentation and examples,
Don't get me wrong, the Flow (and React) community is doing a great job and in my opinion Flow is a very good tool for static type checking. The real problem with both is the coverage/quality of type definitions and the amount of time it takes to create typedefs. Right now there are many more typedefs available for TypeScript and the community is stronger and more active.
Also, right now one common format or conversion between definition formats is not possible, see: https://twitter.com/lbljeffmo/status/787692583350829056
[+] [-] Joeri|9 years ago|reply
- Typescript has excellent dev tooling. I've been using vs code and intellij, and typescript integration is first class.
- Typescript seemed to have a richer type system. I didn't look deeply enough into flow to know for sure though.
- Outside of facebook flow didn't seem to have much traction. With angular 2 being built with typescript I have more confidence in it sticking around.
[+] [-] vnglst|9 years ago|reply
Writing unit tests in TypeScript can sometimes be troublesome and confusing. Especially when mocking dependencies and using spies."
Anybody know why unit tests are difficult in TypeScript?
[+] [-] Joeri|9 years ago|reply
[+] [-] roboguy12|9 years ago|reply
[+] [-] jsynowiec|9 years ago|reply
[+] [-] elvinyung|9 years ago|reply
I thought that has stopped being true for a while now.
[+] [-] pyrophane|9 years ago|reply
[+] [-] vnglst|9 years ago|reply
PS Assuming that by web app you mean "the backend for web apps". Otherwise Node would be used 'just' for the build process, together with Webpack and friends.
[+] [-] rockostrich|9 years ago|reply
[+] [-] WayneBro|9 years ago|reply
[+] [-] Scarbutt|9 years ago|reply
[+] [-] devdad|9 years ago|reply
[+] [-] debaserab2|9 years ago|reply