4 ms·

Typescript is a fantastic language with an absolutely horrid, bug-ridden configuration, tooling and ecosystem integration side. I say this after working with TS

Typescript is a fantastic language with an absolutely horrid, bug-ridden configuration, tooling and ecosystem integration side. I say this after working with TS on a project for over a year now. In particular, attempting to use it with npm modules is an exercise in tedium, as its module resolution constantly breaks and bizarre, undefined behavior does not stop happening. I've found dozens, maybe hundreds of similar reports online, with no solutions offered. There are all sorts of arbitrary gotchas with its configuration as pertains to this and other things. "Oh, don't use outDir and it'll work." While it has great and straightforward integration with VS Code, it has disastrous integration with Visual Studio 2015 and 2017, the latter of which does not even support updating the bundled TS version at will without registry hacks. While TS emits code even in the case of errors, in many situations, Visual Studio refuses to complete the build process in case of TypeScript errors. For an ES6+->ES5 transpiler, it is also very strange in that it polyfills some things but not others, such as Promises and Maps. TypeScript has ultimately brought an unacceptable overhead to my project. It does not get out of the way as soon as you attempt to use it with the rest of the ecosystem. There belies its arrogance: it treats JavaScript as a second class citizen and favors Typings (additional files that assign types to plain JavaScript libraries). But in most cases, Typings are outdated, or nonexistent. Only recently has support for plain JavaScript libraries gotten better, with the AllowJS and CheckJS flags, the latter of which Visual Studio 2017 does not recognize for whatever reason. In my view, it comes with so much baggage that it's probably not worth using. Some of the solutions proposed by the project maintainers amount to writing boilerplate just to support JavaScript functions. It's essentially C header files: you have to write module declarations for certain plain JavaScript libraries to work. There are different versions of this boilerplate that you could be asked to write: you may be told to write a typings file (i.e. declare every single function of the library you want to use in a separate file, and add it to the project, possibly using ///<reference> in certain specific scenarios). There are also ad-hoc declarations of modules and constants/globals that you may or may not need to write (there is no idiom here, and the language regards this as going off-road).

tomelders 9y ago
I completely agree with this. It's maddening to hear everyone wax lyrical about the benefits of typescript when I see non at all, after you balance the benefits of type safety against all the flaws inherent to typescript itself. You used the word "arrogance", and that's exactly what it is. The fact that it's a transpiler (and a poor one at that) makes no sense to me. It's reach exceeds it's grasp and it burdens developers with the task of fixing it's own failings. Before anyone says "you just don't like typed language", stop right there. I do like Typed languages. Typescript is just very very poor when compared to other modern typed languages. It's such a horrible development experience that I'm looking for a way out of web dev. It's clear the community has gone nuts for it. And the Java back enders who seem to have an unwarranted amount of influence in this world are forcing it onto front end developers simply because it looks like Java. And damn you Angular2 for making all of this worse. You're a clunky and bloated framework already, but not content with ramming your flawed methodology down our throats, you've gone and stuck Typescript in there too, seemingly just out of spite. I fear Typescript is here to stay. If that's the case, I'm moving to Swift and iOS, or changing career completely.
- theprotocol 9y ago
  Fortunately, ES6 and 7 are very pleasant to work with. And say what you will about Facebook as a company, but their tech side tends to favor lean technologies over bloated ones, e.g. React over Angular (don't get me started on Angular!). I would pursue that path if I were you.
  - tomelders 9y ago
    I think the difference comes from the fact that Facebook makes things for the web. Their technologies are born out of necessity. Typescript feels like an academic exercise, created by someone who doesn't like Javascript (and there are good reasons to not like Javascript), and wants to reshape it to there tastes, but in the abstract, outside the context of real word usage. And Angular feels more like a land grab than a useful tool to me.
    - ENGNR 9y ago
mythz 9y ago
We've found the most productive way to use TypeScript in VS.NET is to configure it as part of your Webpack build where it's bundled along with all your other assets. You can then disable TypeScript errors from breaking your VS.NET builds by adding to .csproj: <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> When using Webpack you can run `webpack --watch` or run the Webpack dev server where it will instantly process changed TypeScript files to provide an optimal iterative dev work flow: http://docs.servicestack.net/templates-single-page-apps#development-workflow http://docs.servicestack.net/templates-single-page-apps#deve...
- theprotocol 9y ago
  Good advice, and I'm already doing something like that with a gulp script and Browserify. The following is specific to my case: as I'm working on a Cordova app, in order to launch the test process, I need VS to think the build was successful, which it often no longer does because TS module resolution and its associated configs are completely erratic. This is VS2015 with its Ripple emulator. I could upgrade to VS2017, which instead uses cordova-simulate, but then other TS-related issues appear. I can go into detail on this if you're interested. If I set the build flag you mentioned, then it defeats the purpose of TypeScript somewhat, since TS's error reporting being wrong is the reason VS wasn't accepting the builds in the first place. TypeScript without correct IDE integration is nearly useless. If I move to VSCode, the Cordova extension there decides to overwrite config.xml as it pleases, and you can't debug in Chrome (the extension shuts down if you try!). This bit is not TypeScript's fault, but having to go through all these IDEs is. To be clear, the above is simply my current problem with TS. My complaints about it are not limited to this one issue I'm facing. It has some pretty fundamental flaws that revolve around its mistreatment of its own JavaScript target.
lloydjatkinson 9y ago
This resonates with me, a lot. Damn. What would you use instead?
- theprotocol 9y ago
  Honestly, using ES6+ syntax with Babel and ESLint is a good experience. A comment above recommends Flow for type checking. I haven't tried it so I can't comment. Static type checking is great in theory but it's just not worth it if you can't get it to play nice with npm modules. I haven't been able to do so reliably in my year of using TS, among other issues. However, don't necessarily take it from me: if you can get it to work, then great, maybe you'll like it more than I did. If your project has a simple build process, you could still try TS with vscode; it works far better than with VS2015/2017 (that's not to say you won't encounter issues, but it won't be as hellish to diagnose). Although, IMHO, I would argue that Types just don't fit JavaScript; TypeScript is very OO while JavaScript is not. My TS code is all classes and interfaces. It's quite Javaesque and a departure from the non-TS part of the codebase. It feels a bit too enterprisey and unproductive for the JavaScript ecosystem. This last part is just opinion, though. This, in addition to the relentless bureaucratic weirdness I encountered, has driven me away. For instance, it doesn't polyfill Promises, Maps, or Sets, even though its front page says it's an ES2015 transpiler. You have to polyfill them yourself, and then you have to get TypeScript not to reject them by providing typings (https://stackoverflow.com/questions/30019542/es6-map-in-typescript/30112075#30112075 https://stackoverflow.com/questions/30019542/es6-map-in-type...). You also have to set a config flag in tsconfig.json that tells TypeScript that you're providing those polyfills, i.e. {"lib": [ "es5", "dom", "es2015.promise" ]}. Good luck finding all of this information in one place. I think TypeScript is secretly the enemy of JavaScript.
  - tmat 9y ago
    as a react/redux developer i tend to write very functional javascript.. We had a CTO try and ram TypeScript into the project and it went over like a fart in church.
invaliduser 9y ago
Just wanted to give a different perspective. Been using typescript for more than 2 years now, on 2 projects of medium sizes (30 to 100Kloc). Those are projects that provide my income, them breaking means no income anymore for me and my associates. Although Typescript started a bit as you say, complex tooling, had to write external type declaration to have the typing for external libraries (but they are optional, not having them only means not having typing on externals, which is fine in many cases, so not in the way at all), but overall, typing provided so many benefits it was already worth it to me: litterally saved me hundreds of bugs found at compile-time, and keeps the maintenance of the code base cheap and easy. But typescript evolved a lot, now the typing declaration are based on npm, the compiler got faster by an order of magnitude, it provides services to the IDE, and so on. I just wouldn't start a new project with a reasonable expected lifespan without typescript.
- theprotocol 9y ago
  Glad it worked well for you. I really wish it worked for my project, but I experienced issues at every turn and my day-to-day became "the TypeScript show." >not having them only means not having typing on externals AllowJS didn't exist until mid-late last year, so using JS libraries was pretty disastrous before that. That definitely fueled a part of my rant. I find this absolutely shocking, for a language that purports to work with JavaScript. JS modules actually still do not work right for me, as TSC can no longer resolve node modules. I've searched far an wide and found others with the exact same problems and no solutions. It happened suddenly and without cause. Nor does the IDE integration work for me at all. I've actually done completely fresh installations of the IDEs I've tried but nothing would resolve the issues I faced. I'm stuck with a dud of a VS2015 which can't recognize jQuery from npm. VS2017 can resolve the same modules but fails elsewhere. It then proceeded to choke on a JS library that uses its own Promise polyfill, yet provided a d.ts file. No snark, I am genuinely glad it worked well for you. But for me, it's overly laborious getting it to work right, and I've had enough of things like ///<reference> and d.ts files and reconfiguring tsconfig.json.
  - invaliduser 9y ago
    Maybe Typescript still lacks maturity in the sense that if you can adapt your projects (and your process) to how it was designed to work, then it's great and provides a lot, but on the other hand it may be quite difficult to adapt it to a particular workflow.
DavidWoof 9y ago
I've been using TS pretty heavily now for a few years and I'm pretty happy with it (especially recent versions). I was going to disagree entirely with you, until... > it has disastrous integration with Visual Studio 2015 and 2017 Yes, this is true. TS, like ES2015+, really wants to have a complete client build system. All the attempts to integrate it into the VS build have been disastrous, from web essentials on down. And you won't learn that from MS. All the problems you mention went away for me as soon as I began to treat the client code as a first-class citizen. Move all the client code outside the solution and give it its own build, and a lot of these problems go away. I never have problems importing npm modules, and I haven't written a ///<reference> comment in over a year. > Some of the solutions proposed by the project maintainers amount to writing boilerplate It sounds like that's a problem with the project maintainers rather than the language.
- theprotocol 9y ago
  My first words were that it's a fantastic language. :)
mvindahl 9y ago
I've had similar experiences. It's not enough to scare me away from using TS but it comes with a price, and I wouldn't apply it to a project until it reached a certain size. First off, I really like the language design. It's typing but without the red tape or the ceremony that makes languages like Java so bloated and painful. Duck typing works nicely. Not having to name every little type is a breath of fresh air. Typing is optional and easy to add when needed. It works well with both VSCode and IDEA. On the flip side, I've found myself spending far too much time trying to find the right typings to match the libraries that I use. It's very easy to end up with odd conflicts. Reminds me of the (hypothetical, of course) experience of finding subtitle files to match a bootleg movie. More often than not, they are off by five seconds, or jump out of sync midway due to been for the director's cut or whatever. Typescript typings are a bit like that; they get you 98% of the way but the last 2% can be surprisingly frustrating. That being said, after it has become possible to install typings from npm, it has become somewhat more manageable. But yeah, there is a premium to Typescript, like there is to unit tests. It's not a premium that I want to pay for a project unless I'm pretty sure that there is a payoff down the road.

tomelders 9y ago

I completely agree with this. It's maddening to hear everyone wax lyrical about the benefits of typescript when I see non at all, after you balance the benefits of type safety against all the flaws inherent to typescript itself. You used the word "arrogance", and that's exactly what it is. The fact that it's a transpiler (and a poor one at that) makes no sense to me. It's reach exceeds it's grasp and it burdens developers with the task of fixing it's own failings. Before anyone says "you just don't like typed language", stop right there. I do like Typed languages. Typescript is just very very poor when compared to other modern typed languages. It's such a horrible development experience that I'm looking for a way out of web dev. It's clear the community has gone nuts for it. And the Java back enders who seem to have an unwarranted amount of influence in this world are forcing it onto front end developers simply because it looks like Java. And damn you Angular2 for making all of this worse. You're a clunky and bloated framework already, but not content with ramming your flawed methodology down our throats, you've gone and stuck Typescript in there too, seemingly just out of spite. I fear Typescript is here to stay. If that's the case, I'm moving to Swift and iOS, or changing career completely.

theprotocol 9y ago
Fortunately, ES6 and 7 are very pleasant to work with. And say what you will about Facebook as a company, but their tech side tends to favor lean technologies over bloated ones, e.g. React over Angular (don't get me started on Angular!). I would pursue that path if I were you.
- tomelders 9y ago
  I think the difference comes from the fact that Facebook makes things for the web. Their technologies are born out of necessity. Typescript feels like an academic exercise, created by someone who doesn't like Javascript (and there are good reasons to not like Javascript), and wants to reshape it to there tastes, but in the abstract, outside the context of real word usage. And Angular feels more like a land grab than a useful tool to me.
  - ENGNR 9y ago

mythz 9y ago

We've found the most productive way to use TypeScript in VS.NET is to configure it as part of your Webpack build where it's bundled along with all your other assets. You can then disable TypeScript errors from breaking your VS.NET builds by adding to .csproj: <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> When using Webpack you can run `webpack --watch` or run the Webpack dev server where it will instantly process changed TypeScript files to provide an optimal iterative dev work flow: http://docs.servicestack.net/templates-single-page-apps#development-workflow http://docs.servicestack.net/templates-single-page-apps#deve...

theprotocol 9y ago
Good advice, and I'm already doing something like that with a gulp script and Browserify. The following is specific to my case: as I'm working on a Cordova app, in order to launch the test process, I need VS to think the build was successful, which it often no longer does because TS module resolution and its associated configs are completely erratic. This is VS2015 with its Ripple emulator. I could upgrade to VS2017, which instead uses cordova-simulate, but then other TS-related issues appear. I can go into detail on this if you're interested. If I set the build flag you mentioned, then it defeats the purpose of TypeScript somewhat, since TS's error reporting being wrong is the reason VS wasn't accepting the builds in the first place. TypeScript without correct IDE integration is nearly useless. If I move to VSCode, the Cordova extension there decides to overwrite config.xml as it pleases, and you can't debug in Chrome (the extension shuts down if you try!). This bit is not TypeScript's fault, but having to go through all these IDEs is. To be clear, the above is simply my current problem with TS. My complaints about it are not limited to this one issue I'm facing. It has some pretty fundamental flaws that revolve around its mistreatment of its own JavaScript target.

lloydjatkinson 9y ago

This resonates with me, a lot. Damn. What would you use instead?

theprotocol 9y ago
Honestly, using ES6+ syntax with Babel and ESLint is a good experience. A comment above recommends Flow for type checking. I haven't tried it so I can't comment. Static type checking is great in theory but it's just not worth it if you can't get it to play nice with npm modules. I haven't been able to do so reliably in my year of using TS, among other issues. However, don't necessarily take it from me: if you can get it to work, then great, maybe you'll like it more than I did. If your project has a simple build process, you could still try TS with vscode; it works far better than with VS2015/2017 (that's not to say you won't encounter issues, but it won't be as hellish to diagnose). Although, IMHO, I would argue that Types just don't fit JavaScript; TypeScript is very OO while JavaScript is not. My TS code is all classes and interfaces. It's quite Javaesque and a departure from the non-TS part of the codebase. It feels a bit too enterprisey and unproductive for the JavaScript ecosystem. This last part is just opinion, though. This, in addition to the relentless bureaucratic weirdness I encountered, has driven me away. For instance, it doesn't polyfill Promises, Maps, or Sets, even though its front page says it's an ES2015 transpiler. You have to polyfill them yourself, and then you have to get TypeScript not to reject them by providing typings (https://stackoverflow.com/questions/30019542/es6-map-in-typescript/30112075#30112075 https://stackoverflow.com/questions/30019542/es6-map-in-type...). You also have to set a config flag in tsconfig.json that tells TypeScript that you're providing those polyfills, i.e. {"lib": [ "es5", "dom", "es2015.promise" ]}. Good luck finding all of this information in one place. I think TypeScript is secretly the enemy of JavaScript.
- tmat 9y ago
  as a react/redux developer i tend to write very functional javascript.. We had a CTO try and ram TypeScript into the project and it went over like a fart in church.

invaliduser 9y ago

Just wanted to give a different perspective. Been using typescript for more than 2 years now, on 2 projects of medium sizes (30 to 100Kloc). Those are projects that provide my income, them breaking means no income anymore for me and my associates. Although Typescript started a bit as you say, complex tooling, had to write external type declaration to have the typing for external libraries (but they are optional, not having them only means not having typing on externals, which is fine in many cases, so not in the way at all), but overall, typing provided so many benefits it was already worth it to me: litterally saved me hundreds of bugs found at compile-time, and keeps the maintenance of the code base cheap and easy. But typescript evolved a lot, now the typing declaration are based on npm, the compiler got faster by an order of magnitude, it provides services to the IDE, and so on. I just wouldn't start a new project with a reasonable expected lifespan without typescript.

theprotocol 9y ago
Glad it worked well for you. I really wish it worked for my project, but I experienced issues at every turn and my day-to-day became "the TypeScript show." >not having them only means not having typing on externals AllowJS didn't exist until mid-late last year, so using JS libraries was pretty disastrous before that. That definitely fueled a part of my rant. I find this absolutely shocking, for a language that purports to work with JavaScript. JS modules actually still do not work right for me, as TSC can no longer resolve node modules. I've searched far an wide and found others with the exact same problems and no solutions. It happened suddenly and without cause. Nor does the IDE integration work for me at all. I've actually done completely fresh installations of the IDEs I've tried but nothing would resolve the issues I faced. I'm stuck with a dud of a VS2015 which can't recognize jQuery from npm. VS2017 can resolve the same modules but fails elsewhere. It then proceeded to choke on a JS library that uses its own Promise polyfill, yet provided a d.ts file. No snark, I am genuinely glad it worked well for you. But for me, it's overly laborious getting it to work right, and I've had enough of things like ///<reference> and d.ts files and reconfiguring tsconfig.json.
- invaliduser 9y ago
  Maybe Typescript still lacks maturity in the sense that if you can adapt your projects (and your process) to how it was designed to work, then it's great and provides a lot, but on the other hand it may be quite difficult to adapt it to a particular workflow.

DavidWoof 9y ago

I've been using TS pretty heavily now for a few years and I'm pretty happy with it (especially recent versions). I was going to disagree entirely with you, until... > it has disastrous integration with Visual Studio 2015 and 2017 Yes, this is true. TS, like ES2015+, really wants to have a complete client build system. All the attempts to integrate it into the VS build have been disastrous, from web essentials on down. And you won't learn that from MS. All the problems you mention went away for me as soon as I began to treat the client code as a first-class citizen. Move all the client code outside the solution and give it its own build, and a lot of these problems go away. I never have problems importing npm modules, and I haven't written a ///<reference> comment in over a year. > Some of the solutions proposed by the project maintainers amount to writing boilerplate It sounds like that's a problem with the project maintainers rather than the language.

theprotocol 9y ago
My first words were that it's a fantastic language. :)

mvindahl 9y ago

I've had similar experiences. It's not enough to scare me away from using TS but it comes with a price, and I wouldn't apply it to a project until it reached a certain size. First off, I really like the language design. It's typing but without the red tape or the ceremony that makes languages like Java so bloated and painful. Duck typing works nicely. Not having to name every little type is a breath of fresh air. Typing is optional and easy to add when needed. It works well with both VSCode and IDEA. On the flip side, I've found myself spending far too much time trying to find the right typings to match the libraries that I use. It's very easy to end up with odd conflicts. Reminds me of the (hypothetical, of course) experience of finding subtitle files to match a bootleg movie. More often than not, they are off by five seconds, or jump out of sync midway due to been for the director's cut or whatever. Typescript typings are a bit like that; they get you 98% of the way but the last 2% can be surprisingly frustrating. That being said, after it has become possible to install typings from npm, it has become somewhat more manageable. But yeah, there is a premium to Typescript, like there is to unit tests. It's not a premium that I want to pay for a project unless I'm pretty sure that there is a payoff down the road.