3 ms·
Typescript programming invariably results in time spent figuring out how to properly type otherwise valid JavaScript code, ie debugging code that doesn't wind u
by schwartzworld 6y ago
Typescript programming invariably results in time spent figuring out how to properly type otherwise valid JavaScript code, ie debugging code that doesn't wind up in your app. In a large app, the types can be their own special form of spaghetti. The typing system is clunky and inelegant compared to Elm, which is what I would use for a non-JavaScript frontend. I'd never greenfield a project with TS if I could avoid it.
- emilecantin 6y ago> In a large app, the types can be their own special form of spaghetti. I have a relatively neutral opinion of Typescript, but oh boy does that quote ring true. TS can be a very nice safety net when refactoring (just fix all the type errors, and the app should mostly work as it did before), but you can also very well paint yourself in a corner with similar-but-slightly-different types all over the place that'd just work if it was in JS.
- stank345 6y agoYeah, agreed, but it's nice that it gives you the flexibility to be able to throw a `// @ts-ignore` in there and tell the compiler not to worry about it. I've definitely done that when consuming wonky libraries with messed up type definitions.
- stank345 6y agoI agree that TypeScript's type system is clunky compared to Elm, but being able to add a good amount of type safety with such a small learning curve and a large ecosystem at your disposal is a massive win. And Elm has its own problems (breaking changes, awkwardness of ports, lack of libraries).