I don't think your second point is restricted to Typescript at all. Every compile-to-JavaScript language I've used lets you use existing JavaScript code. Some, like Elm, make it a lot harder (really just different, but it's not plug-and-play like TS) than Typescript does but that comes with the advantage of doing so in a type safe way.
For your third point, let's not forget that Flow's type system is more "correct" than Typescript's and is just as easy to add to an existing project.
I argue that the typing is good enough. It might not protect you from 100% of runtime exceptions, but it does protect you from maybe 95-99% if you use it correctly
I think this is where we're just going to agree to disagree. I'm scared of Typescript codebases because there are so many holes in the type system it feels just as hard to refactor as JavaScript does. You still can't be sure that something claiming to be of type A isn't actually of type B.
I know you qualified that with "if you use it correctly" but I'd argue any type system that lets you ignore it completely can't be used correctly because, at some point, someone is going to sneak a change in with some dodgy type assertions and your nice typed codebase isn't safe anymore. In a personal or open-source project that probably isn't a big risk and is easy to fix at any time, but in the average workplace it's easy to miss things when there's pressure to build more features and much harder to go back and fix things that aren't visible problems.
Funnily enough Elm does protect you from 100% of runtime exceptions — if you do manage to encounter any, they're treated as compiler bugs.
I do absolutely agree with you that Typescript is the obvious, pragmatic choice if you want a typed compile-to-JS language right now, but it's not a choice I would make. I do love Elm but it's obviously a much harder sell and I'd only feel comfortable pushing for it in a professional environment if there was buy-in from the entire team; it's probably not suitable for most companies.
I don't think your second point is restricted to Typescript at all. Every compile-to-JavaScript language I've used lets you use existing JavaScript code. Some, like Elm, make it a lot harder (really just different, but it's not plug-and-play like TS) than Typescript does but that comes with the advantage of doing so in a type safe way.
While every compile-to-JS languages enables some degree of interop, I argue that TypeScript has one of the most seamless experiences. Same import syntax, same language semantics; if there's a good .d.ts file you might not even know the difference. I was also under the impression that Flow was just a type checker and not a language, but I never really used it because I got on TypeScript early.
I think this is where we're just going to agree to disagree. I'm scared of Typescript codebases because there are so many holes in the type system it feels just as hard to refactor as JavaScript does. You still can't be sure that something claiming to be of type A isn't actually of type B.
I definitely hold the same "agree to disagree" mantra for a technology debates. There are a lot of tradeoffs and opinions, and not as much objectivity as some people pretend. But I still feel like this is a little bit of an exaggeration. I can't image having the same level of uncertainty refactoring a TypeScript application as refactoring a JavaScript application. Sure, technically an object can be anything. But I can't remember a time that has actually happened to me. I'm not saying it doesn't happen, but I am saying it is rare enough that the comparison to JavaScript refactoring is unfair.
I know you qualified that with "if you use it correctly" but I'd argue any type system that lets you ignore it completely can't be used correctly because, at some point, someone is going to sneak a change in with some dodgy type assertions and your nice typed codebase isn't safe anymore. In a personal or open-source project that probably isn't a big risk and is easy to fix at any time, but in the average workplace it's easy to miss things when there's pressure to build more features and much harder to go back and fix things that aren't visible problems.
I'm not trying to be dismissive, but I think this problem can be pretty easily solved with code standards, enforced by code review and static analysis tools. Every now and then, a bad hack might make its way into the code base due to time constraints. But if this is happening so frequently that confidence in the entire system is undermined, I think that's an organizational failure more than a technical one.
Again, I'm not trying to convince you (or anyone!) that Elm is bad. I really do like the project and I keep tabs on the development.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't think your second point is restricted to Typescript at all. Every compile-to-JavaScript language I've used lets you use existing JavaScript code. Some, like Elm, make it a lot harder (really just different, but it's not plug-and-play like TS) than Typescript does but that comes with the advantage of doing so in a type safe way.
For your third point, let's not forget that Flow's type system is more "correct" than Typescript's and is just as easy to add to an existing project.
I think this is where we're just going to agree to disagree. I'm scared of Typescript codebases because there are so many holes in the type system it feels just as hard to refactor as JavaScript does. You still can't be sure that something claiming to be of type A isn't actually of type B.
I know you qualified that with "if you use it correctly" but I'd argue any type system that lets you ignore it completely can't be used correctly because, at some point, someone is going to sneak a change in with some dodgy type assertions and your nice typed codebase isn't safe anymore. In a personal or open-source project that probably isn't a big risk and is easy to fix at any time, but in the average workplace it's easy to miss things when there's pressure to build more features and much harder to go back and fix things that aren't visible problems.
Funnily enough Elm does protect you from 100% of runtime exceptions — if you do manage to encounter any, they're treated as compiler bugs.
I do absolutely agree with you that Typescript is the obvious, pragmatic choice if you want a typed compile-to-JS language right now, but it's not a choice I would make. I do love Elm but it's obviously a much harder sell and I'd only feel comfortable pushing for it in a professional environment if there was buy-in from the entire team; it's probably not suitable for most companies.
While every compile-to-JS languages enables some degree of interop, I argue that TypeScript has one of the most seamless experiences. Same import syntax, same language semantics; if there's a good
.d.tsfile you might not even know the difference. I was also under the impression that Flow was just a type checker and not a language, but I never really used it because I got on TypeScript early.I definitely hold the same "agree to disagree" mantra for a technology debates. There are a lot of tradeoffs and opinions, and not as much objectivity as some people pretend. But I still feel like this is a little bit of an exaggeration. I can't image having the same level of uncertainty refactoring a TypeScript application as refactoring a JavaScript application. Sure, technically an object can be anything. But I can't remember a time that has actually happened to me. I'm not saying it doesn't happen, but I am saying it is rare enough that the comparison to JavaScript refactoring is unfair.
I'm not trying to be dismissive, but I think this problem can be pretty easily solved with code standards, enforced by code review and static analysis tools. Every now and then, a bad hack might make its way into the code base due to time constraints. But if this is happening so frequently that confidence in the entire system is undermined, I think that's an organizational failure more than a technical one.
Again, I'm not trying to convince you (or anyone!) that Elm is bad. I really do like the project and I keep tabs on the development.