3 ms·

> writing maintainable code is the real challenge If you think these same developers can't do it without TS, then you really haven't seen the sort of mess less

> writing maintainable code is the real challenge If you think these same developers can't do it without TS, then you really haven't seen the sort of mess lesser developers make when they try with TS. Unless the JavaScript developer has a strong background in C/C++/Java, they are going to truly fuck up a code base with TypeScript. I'm not making a static/dynamic typing argument here. I'm making an observation that thousands of developers that haven't seen what the hell a type even is are now somehow expected to operate on the level of creating coherent abstractions throughout the code. Good luck with that, once your team starts allowing "any" and "ts-ignore" everywhere. 9 out of 10 JS developers I have worked with do not know how equality and object memory references work in JavaScript. They do not understand deep vs. shallow equality. They are barely aware of type coercion. When faced with a TypeScript error, their primary concern is shutting up the compiler. By any means necessary. Getting typing correct is more nuanced than the pro-TypeScript group will ever admit, and TypeScript provides so many ways to dodge actual typing responsibility that it renders the whole exercise a colossal waste of time. tl;dr: Good developers don't need TypeScript and bad developers pull good developers down with TypeScript.

hacker_9 7y ago
I think I'm going to have make this my last comment as this is going in circles. I mean what is even your argument? Types exist whether you like it or not, implicitly or explicitly. You cannot get around this, it is simply a fact. When you have input parameters, or a return type, they follow a structure. That structure is a type. This is not nuance, this is just how things work. 'Good' developers is a subjective term, what is a good developer to you? Someone who can work without types? Wtf? Anyway, I'll keep being productive with typed languages. You do you I guess.
Silhouette 7y ago
9 out of 10 JS developers I have worked with do not know how equality and object memory references work in JavaScript. They do not understand deep vs. shallow equality. They are barely aware of type coercion. When faced with a TypeScript error, their primary concern is shutting up the compiler. By any means necessary. That sort of thing definitely happens, but the problem usually has very little to do with the choice of programming language. Front-end web development is the next generation's Visual Basic or PHP, the kind of software development that is easy to get into, but which as a result attracts a lot of people who have never really learned to program well. If you don't understand basic concepts like reference and value semantics, you're probably going to write bad code in any language, but you're also not particularly interesting from the point of view of what makes an effective language for a competent programmer.
verttii 7y ago
Typescript's inherent problem may well be that it's rules are too lax, it allows you to circumvent them conveniently. This keeps poisoning the code base piece by piece, leaving you with a false sense of trust. Maybe it's because of the compatibility with Javascript but it does kill Typescript's type soundness. Edit: rephrasing
Aeolun 7y ago
> 9 out of 10 JS developers I have worked with do not know how equality and object memory references work in JavaScript. They do not understand deep vs. shallow equality. They are barely aware of type coercion. When faced with a TypeScript error, their primary concern is shutting up the compiler. By any means necessary. I think the exact same problems exist with JS no? Except now there isn’t any compiler to shut up, and things just silently fail.
Merad 7y ago
I'm totally in favor of using TS, but I agree that lazy devs can set up an absolute mess when they try to use TS without really learning it. I think probably the fundamental weakness of TS is that you really need a good understand of how it's limited to compile time type checking, and how easily you can set up situations where the actual run time types don't match what you have in TS. For example, it feels like I'm in a constant battle with some of our front end devs about typing their models correctly... they don't seem to understand that they keep setting up the type system to lie to them. For example, if a property in our API is nullable, then the property will always be present in the json with an explicit null value, so the model should be typed `propName: string | null`... but they prefer being lazy when mocking out data on the front end, so they instead type the model as `propName?: string`. Likewise with properties that are date/times (ISO-8601 strings in the json) they love to use Date as the type for those properties, then everywhere they use that property they end up wrapping it with `new Date()` because "it doesn't work" otherwise. Yikes.

hacker_9 7y ago

I think I'm going to have make this my last comment as this is going in circles. I mean what is even your argument? Types exist whether you like it or not, implicitly or explicitly. You cannot get around this, it is simply a fact. When you have input parameters, or a return type, they follow a structure. That structure is a type. This is not nuance, this is just how things work. 'Good' developers is a subjective term, what is a good developer to you? Someone who can work without types? Wtf? Anyway, I'll keep being productive with typed languages. You do you I guess.

Silhouette 7y ago

9 out of 10 JS developers I have worked with do not know how equality and object memory references work in JavaScript. They do not understand deep vs. shallow equality. They are barely aware of type coercion. When faced with a TypeScript error, their primary concern is shutting up the compiler. By any means necessary. That sort of thing definitely happens, but the problem usually has very little to do with the choice of programming language. Front-end web development is the next generation's Visual Basic or PHP, the kind of software development that is easy to get into, but which as a result attracts a lot of people who have never really learned to program well. If you don't understand basic concepts like reference and value semantics, you're probably going to write bad code in any language, but you're also not particularly interesting from the point of view of what makes an effective language for a competent programmer.

verttii 7y ago

Typescript's inherent problem may well be that it's rules are too lax, it allows you to circumvent them conveniently. This keeps poisoning the code base piece by piece, leaving you with a false sense of trust. Maybe it's because of the compatibility with Javascript but it does kill Typescript's type soundness. Edit: rephrasing

Aeolun 7y ago

> 9 out of 10 JS developers I have worked with do not know how equality and object memory references work in JavaScript. They do not understand deep vs. shallow equality. They are barely aware of type coercion. When faced with a TypeScript error, their primary concern is shutting up the compiler. By any means necessary. I think the exact same problems exist with JS no? Except now there isn’t any compiler to shut up, and things just silently fail.

Merad 7y ago

I'm totally in favor of using TS, but I agree that lazy devs can set up an absolute mess when they try to use TS without really learning it. I think probably the fundamental weakness of TS is that you really need a good understand of how it's limited to compile time type checking, and how easily you can set up situations where the actual run time types don't match what you have in TS. For example, it feels like I'm in a constant battle with some of our front end devs about typing their models correctly... they don't seem to understand that they keep setting up the type system to lie to them. For example, if a property in our API is nullable, then the property will always be present in the json with an explicit null value, so the model should be typed `propName: string | null`... but they prefer being lazy when mocking out data on the front end, so they instead type the model as `propName?: string`. Likewise with properties that are date/times (ISO-8601 strings in the json) they love to use Date as the type for those properties, then everywhere they use that property they end up wrapping it with `new Date()` because "it doesn't work" otherwise. Yikes.