34 ms·

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

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
    Angular initially solved a very small problem - forms. It just scaled really badly (by design but then it was never highlighted in the documentation) and then had second system syndrome
  - Klathmon 9y ago
    If you haven't used it, Flow is a fantastic alternative to TypeScript. They still have some hiccups about working correctly on windows, but it's a much easier way of doing typing in JS than TS.
    - jeremyjh 9y ago
      Except it is impossible to prevent it from typechecking node_modules; so if you have a dependency that was checked with a different version of flow than you are using, you may see errors that are impossible to silence.
      - insin 9y ago
        The only way I've been able to get Flow to be usable on my low-specced laptop is to tell it to [ignore] node_modules/.* and add a file to both [ignore] and [libs] which has one of these for each of my dependencies: declare module 'npm-module-name' { declare var exports: any; } I needed similar for TypeScript when trying to use noImplicitAny: false - adding "typeRoots": ["node_modules/@types"] in compilerOptions and a d.ts file with the following listed in "files": declare module "*" Typechecking third-party dependencies seems to be a bit of a crapshoot if you're not in a part of the module ecosystem where the tool you're using is either quasi-required, popular or has module authors using the same tool and shipping type definitions themselves. I've had contributed type definitions in both Flow and TypeScript "break" working, tested code.
        jeremyjh 9y ago
        Typescript is different - I can use type definitions from NPM without typechecking dependencies I don't import.
allover 9y ago
> It's such a horrible development experience that I'm looking for a way out of web dev Before you abandon web dev altogether, you'd possibly enjoy the React or Vue communities more where TypeScript is not as popular, and Babel (writing ES6/ES2015+) seems to be the default. (e.g. create-react-app and vue-cli's 'vue init' default to using Babel).
- tomelders 9y ago
  I'm a React guy. React + Redux + Reselect + Sagas + Immutable.js is my goto stack. And I like to work with React-Boilerplate when I'm working on something big. But I'm handy enough with Webpack and Babel that I can spin up a small project on my own without needing create-react-app. But I'm a "consultant". So I have to take the clients desires into consideration too. On my current project, I managed to steer them away form Angular2 (which they'd never used in anger) to React+Redux. But they tacked on Typescript (after rejecting Flow) for reasons that didn't make very much sense to me. As a result, I've got a working version of what is essentially React-Boilerplate written in Typescript, which I can't share with the community because the client isn't into sharing (but they sure do love using other people's code), but even if I could, I'd be wary of doing it because it would validate what I believe to be a massive mistake. But the moral of this story is; Often, the decision to use a library, framework, or language is not the developers choice. And it is often a decision taken for questionable reasons.
simon83 9y ago
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.

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
  Angular initially solved a very small problem - forms. It just scaled really badly (by design but then it was never highlighted in the documentation) and then had second system syndrome
- Klathmon 9y ago
  If you haven't used it, Flow is a fantastic alternative to TypeScript. They still have some hiccups about working correctly on windows, but it's a much easier way of doing typing in JS than TS.
  - jeremyjh 9y ago
    Except it is impossible to prevent it from typechecking node_modules; so if you have a dependency that was checked with a different version of flow than you are using, you may see errors that are impossible to silence.
    - insin 9y ago
      The only way I've been able to get Flow to be usable on my low-specced laptop is to tell it to [ignore] node_modules/.* and add a file to both [ignore] and [libs] which has one of these for each of my dependencies: declare module 'npm-module-name' { declare var exports: any; } I needed similar for TypeScript when trying to use noImplicitAny: false - adding "typeRoots": ["node_modules/@types"] in compilerOptions and a d.ts file with the following listed in "files": declare module "*" Typechecking third-party dependencies seems to be a bit of a crapshoot if you're not in a part of the module ecosystem where the tool you're using is either quasi-required, popular or has module authors using the same tool and shipping type definitions themselves. I've had contributed type definitions in both Flow and TypeScript "break" working, tested code.
      - jeremyjh 9y ago
        Typescript is different - I can use type definitions from NPM without typechecking dependencies I don't import.

allover 9y ago

> It's such a horrible development experience that I'm looking for a way out of web dev Before you abandon web dev altogether, you'd possibly enjoy the React or Vue communities more where TypeScript is not as popular, and Babel (writing ES6/ES2015+) seems to be the default. (e.g. create-react-app and vue-cli's 'vue init' default to using Babel).

tomelders 9y ago
I'm a React guy. React + Redux + Reselect + Sagas + Immutable.js is my goto stack. And I like to work with React-Boilerplate when I'm working on something big. But I'm handy enough with Webpack and Babel that I can spin up a small project on my own without needing create-react-app. But I'm a "consultant". So I have to take the clients desires into consideration too. On my current project, I managed to steer them away form Angular2 (which they'd never used in anger) to React+Redux. But they tacked on Typescript (after rejecting Flow) for reasons that didn't make very much sense to me. As a result, I've got a working version of what is essentially React-Boilerplate written in Typescript, which I can't share with the community because the client isn't into sharing (but they sure do love using other people's code), but even if I could, I'd be wary of doing it because it would validate what I believe to be a massive mistake. But the moral of this story is; Often, the decision to use a library, framework, or language is not the developers choice. And it is often a decision taken for questionable reasons.

simon83 9y ago

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.