3 ms·

As someone with 10+ years JS experience and now 3+ months TS I can not agree with you and the gp. It's total hyperbole what you are writing. We are converting

As someone with 10+ years JS experience and now 3+ months TS I can not agree with you and the gp. It's total hyperbole what you are writing. We are converting our huge and messy JS code base to TS, which uses a plethora of libs like jquery + plugins, bootstrap, kendo, knockout, and now React (don't ask me, I don't make the decisions), and we are not even close to done yet. So far TS has been a huge productivity boost. Refactoring is a breeze and the compiler found so many subtle bugs that our JS code had. Converting JS to TS is mostly straightforward, just a few type annotations here and there, the compiler can infer types mostly by himself. Sure, TS has it quirks, the type definitions of external JS libs is not perfect, allowJs can sometimes be a pain, but so far there wasn't really anything as bad as you make it sound. where we would say "screw TS, let's go back to ES/babel". Quite the contrary, none of our JS devs would go back to plain JS. JS is a huge pain in the ass to refactor, especially on large and complex code bases. > I fear Typescript is here to stay. If that's the case, I'm moving to Swift and iOS, or changing career completely. Good riddance then, I'd say :) I'm sure Swift or iOS development has no quirks whatsoever.

theprotocol 9y ago
When the tooling works, it has some really great things mostly related to IDE functionality. But when it doesn't it's a nightmare. It's more than just quirks. It's not hyperbole either, I just had a different experience with it than you. I sincerely hope it doesn't die on you after you convert your codebase. I wouldn't wish that on anyone. It's far worse than "the definitions for external JS libs are not perfect;" it's that the TypeScript compiler throws a tantrum when they aren't perfect, which is >50% of the time, to be generous. AllowJS is relatively recent and didn't exist when I started using it - which is shocking, because integration with the JavaScript ecosystem was a major selling point (just check the TS project site's front page). CheckJS is very recent and VS2017 doesn't even support it yet - for a language whose main selling point is tooling support, it's shocking that VS2017 doesn't let users update their TS version. Another selling point listed on the front page of its website: ES2015 features. Except it doesn't provide Promises, Map, Sets (and I can't remember if they added Object.Assign support, but it also was not supported when I was using it). When you provide your own polyfills, TSC complains unless you provide typings and add specific config values informing it what you polyfilled. Its 3 main selling points were JavaScript ecosystem integration, ES2015 features, and tight tooling/IDE integration. Each of those things failed me when I used it. The IDE part hurt me the worst, preventing my project from compiling altogether for a while. Every one of its main selling points has been a pain point for me.
- simon83 9y ago
  > I sincerely hope it doesn't die on you after you convert your codebase. I wouldn't wish that on anyone. Pretty sure the product I'm working on will die long before TS :) I think TS is here to stay, and if MS decides to drop it, for whatever crazy reason, then the source code is available. And there is still the option to take the compiled JS code, and hope for some "cleanup" tool, like Decaffeinate, or gradually clean it up yourself... Not nice I agree, but I see no dead end here. > it's that the TypeScript compiler throws a tantrum when they aren't perfect, which is >50% of the time, to be generous. Really not sure why our experience differs so much from yours. Like I mentioned, we use a shitload of popular libraries, and for every single one there was a d.ts file available. If I see a definition that is wrong/outdated/broken then I create a fork, fix it and make a pull request. Doesn't usually take longer than a few minutes (depending how outdated the definition file is). Instead of complaining, I try to actively help improve the situation. Most of those d.ts files are written by normal developers in their spare time, after all, so it doesn't help to curse those people. > Another selling point listed on the front page of its website: ES2015 features. Except it doesn't provide Promises, Map, Sets (and I can't remember if they added Object.Assign support, but it also was not supported when I was using it). When you provide your own polyfills, TSC complains unless you provide typings and add specific config values informing it what you polyfilled. Yeah it's weird, and I don't get it either. Our solution to this is to run the compiled JS code through Babel. We use webpack for this and it's pretty much hassle free. On the other hand, for someone new to TS/JS this may not be obvious. So I agree there is a tooling problem in this regard, but once you know about it, it's a non issue. So yeah, it would've been nice if the TS compiler did properly polyfill things. And don't get me even started on Visual Studio. I hate to work with it. It's nice for small projects/solutions, but we have a rather big solution, with a couple "Azure cloud classic" projects, and the whole thing is soooo fucking slow. Changing a single value in a ServiceConfiguration.cfg file will freeze VS for almost a minute, for example. There is lag and delays everywhere. The "TypeScript for Visual Studio Extension" was also very problematic, so we disabled all TS features in VS. We use Sublime/VS Code only since a very long time to edit our JS code. VS is a sad joke for a frontend developer.
  - theprotocol 9y ago
tomelders 9y ago
Or maybe - and this is what I'm honestly inferring from your comment, it's not snark, it's just a hunch based on 16+ years of web development experience - just maybe there were issues with your teams code quality that means TS has been a huge win for you. Looking at that stack, it seems like someone in your organisation likes sticking plasters over problems. I'm not a Javascript apologist by any means. I think Typescript makes an already quirky and clunky language worse.
- simon83 9y ago
  Yep, sticking plasters over problems describes it perfectly ;) Many refactoring attempts, but never completed, because JS makes it really hard. And yes, code quality is bad. Most of it was written by people who never wrote JS/HTML before, then it grew historically and here we are with this mess. But besides TS being very helpful in a messy code base, personally I would also always start a new project with TS. For me the benefits greatly outweigh the minor annoyances (I really see them as minor)
- braveo 9y ago
  > Looking at that stack, it seems like someone in your organisation likes sticking plasters over problems. glad to see I'm not the only one that got that from the post.

theprotocol 9y ago

When the tooling works, it has some really great things mostly related to IDE functionality. But when it doesn't it's a nightmare. It's more than just quirks. It's not hyperbole either, I just had a different experience with it than you. I sincerely hope it doesn't die on you after you convert your codebase. I wouldn't wish that on anyone. It's far worse than "the definitions for external JS libs are not perfect;" it's that the TypeScript compiler throws a tantrum when they aren't perfect, which is >50% of the time, to be generous. AllowJS is relatively recent and didn't exist when I started using it - which is shocking, because integration with the JavaScript ecosystem was a major selling point (just check the TS project site's front page). CheckJS is very recent and VS2017 doesn't even support it yet - for a language whose main selling point is tooling support, it's shocking that VS2017 doesn't let users update their TS version. Another selling point listed on the front page of its website: ES2015 features. Except it doesn't provide Promises, Map, Sets (and I can't remember if they added Object.Assign support, but it also was not supported when I was using it). When you provide your own polyfills, TSC complains unless you provide typings and add specific config values informing it what you polyfilled. Its 3 main selling points were JavaScript ecosystem integration, ES2015 features, and tight tooling/IDE integration. Each of those things failed me when I used it. The IDE part hurt me the worst, preventing my project from compiling altogether for a while. Every one of its main selling points has been a pain point for me.

simon83 9y ago
> I sincerely hope it doesn't die on you after you convert your codebase. I wouldn't wish that on anyone. Pretty sure the product I'm working on will die long before TS :) I think TS is here to stay, and if MS decides to drop it, for whatever crazy reason, then the source code is available. And there is still the option to take the compiled JS code, and hope for some "cleanup" tool, like Decaffeinate, or gradually clean it up yourself... Not nice I agree, but I see no dead end here. > it's that the TypeScript compiler throws a tantrum when they aren't perfect, which is >50% of the time, to be generous. Really not sure why our experience differs so much from yours. Like I mentioned, we use a shitload of popular libraries, and for every single one there was a d.ts file available. If I see a definition that is wrong/outdated/broken then I create a fork, fix it and make a pull request. Doesn't usually take longer than a few minutes (depending how outdated the definition file is). Instead of complaining, I try to actively help improve the situation. Most of those d.ts files are written by normal developers in their spare time, after all, so it doesn't help to curse those people. > Another selling point listed on the front page of its website: ES2015 features. Except it doesn't provide Promises, Map, Sets (and I can't remember if they added Object.Assign support, but it also was not supported when I was using it). When you provide your own polyfills, TSC complains unless you provide typings and add specific config values informing it what you polyfilled. Yeah it's weird, and I don't get it either. Our solution to this is to run the compiled JS code through Babel. We use webpack for this and it's pretty much hassle free. On the other hand, for someone new to TS/JS this may not be obvious. So I agree there is a tooling problem in this regard, but once you know about it, it's a non issue. So yeah, it would've been nice if the TS compiler did properly polyfill things. And don't get me even started on Visual Studio. I hate to work with it. It's nice for small projects/solutions, but we have a rather big solution, with a couple "Azure cloud classic" projects, and the whole thing is soooo fucking slow. Changing a single value in a ServiceConfiguration.cfg file will freeze VS for almost a minute, for example. There is lag and delays everywhere. The "TypeScript for Visual Studio Extension" was also very problematic, so we disabled all TS features in VS. We use Sublime/VS Code only since a very long time to edit our JS code. VS is a sad joke for a frontend developer.
- theprotocol 9y ago

tomelders 9y ago

Or maybe - and this is what I'm honestly inferring from your comment, it's not snark, it's just a hunch based on 16+ years of web development experience - just maybe there were issues with your teams code quality that means TS has been a huge win for you. Looking at that stack, it seems like someone in your organisation likes sticking plasters over problems. I'm not a Javascript apologist by any means. I think Typescript makes an already quirky and clunky language worse.

simon83 9y ago
Yep, sticking plasters over problems describes it perfectly ;) Many refactoring attempts, but never completed, because JS makes it really hard. And yes, code quality is bad. Most of it was written by people who never wrote JS/HTML before, then it grew historically and here we are with this mess. But besides TS being very helpful in a messy code base, personally I would also always start a new project with TS. For me the benefits greatly outweigh the minor annoyances (I really see them as minor)
braveo 9y ago
> Looking at that stack, it seems like someone in your organisation likes sticking plasters over problems. glad to see I'm not the only one that got that from the post.