3 ms·

Slows down what? Compile times? By a small amount sure, but with the incremental compilation we're talking maybe a few tens of seconds max. Any longer and you

Slows down what? Compile times? By a small amount sure, but with the incremental compilation we're talking maybe a few tens of seconds max. Any longer and you need to look at improving your build dependencies for better parallelism, and upgrading your hardware. Development time? Types reduce mental overhead and abstraction for the developer, speeding up development. Run time? Variables with types that stay static execute faster in JS engines. Types keep code maintainable, and protect against any accidentally implicit conversions (rife in JS). Types still exist whether you define them or not, so being explicit gives the maintainer of your code much less mental overhead when working with your code. Knowing the contract that a function follows allows them to skip over any assumptions and know exactly what the code is meant to do. Break the contract, get a compile time error. Anyone can write code, writing maintainable code is the real challenge. In my own 20 years experience this is always what separates the wheat from the chaff.

deckard1 7y ago
> 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.
hajile 7y ago
> Development time? Types reduce mental overhead and abstraction for the developer, speeding up development. React has proptypes that make contract guarantees -- ones that don't disappear at compile time. Most stuff is local to a single file. If your imports and shared objects are so poorly named and poorly understood that types become the major blocker, you have bigger issues. > Run time? Variables with types that stay static execute faster in JS engines. The biggest issue in JS engines is making functions monomorphic. Typescript is perfectly happy with every single function in your system being a slow, megamorphic call. As to changing variables, judicious use of `const` is the real answer here. There is definitely something to be said for enforcing object structure though. Adding and removing properties to an object is a significant issue. The non-type solution here is the addition of records and tuples to the system. Since they cannot be modified, the general performance will go up. https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple I like the idea of types, but dislike typescript. Most importantly, it is not a sound type system and the illusion of sound types is worse than dynamic types IMO. If I ever adopt a type system into my current project, it will undoubtedly be F# (fable) or ReasonML (ocaml) where I can gain sound types and better syntax without giving up the practical need for mutation (like with Elm where lots of garbage and poor interactions with JS libraries are the result).

deckard1 7y ago

> 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.

hajile 7y ago

> Development time? Types reduce mental overhead and abstraction for the developer, speeding up development. React has proptypes that make contract guarantees -- ones that don't disappear at compile time. Most stuff is local to a single file. If your imports and shared objects are so poorly named and poorly understood that types become the major blocker, you have bigger issues. > Run time? Variables with types that stay static execute faster in JS engines. The biggest issue in JS engines is making functions monomorphic. Typescript is perfectly happy with every single function in your system being a slow, megamorphic call. As to changing variables, judicious use of `const` is the real answer here. There is definitely something to be said for enforcing object structure though. Adding and removing properties to an object is a significant issue. The non-type solution here is the addition of records and tuples to the system. Since they cannot be modified, the general performance will go up. https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple I like the idea of types, but dislike typescript. Most importantly, it is not a sound type system and the illusion of sound types is worse than dynamic types IMO. If I ever adopt a type system into my current project, it will undoubtedly be F# (fable) or ReasonML (ocaml) where I can gain sound types and better syntax without giving up the practical need for mutation (like with Elm where lots of garbage and poor interactions with JS libraries are the result).