3 ms·
Where I've found that TypeScript is a hindrance is where I want to code fast/lazily. E.g. if I need to add a Bar property to a Foo object, in plain JS you just
by mattlondon 7y ago
Where I've found that TypeScript is a hindrance is where I want to code fast/lazily.
E.g. if I need to add a Bar property to a Foo object, in plain JS you just do it as and when you need to without any extra hassle. This makes hacking something together really fast and low-friction which is nice.
Typescript wont let you do that though - you need to go off and define the Bar property on Foo which you might argue slows you down, or seems inappropriate if you only need Bar in certain circumstances and not every time or whatever.
Personally I find that the extra rigor that Typescript forces is way worth the extra hassle - it prevents so many subtle bugs, makes refactoring a lot easier, helps multiple people work together on the same code in a sensible way, and IDEs work so much better (in my experience at least).
Most popular libraries by the way all have the types defined already - check out https://definitelytyped.org/ https://definitelytyped.org/
- Humphrey 7y agoI'd disagree with that - and say this scenario is where TypeScript saves me time. I just want to add a property to an object. All I have to do is add it to the definition, and TS will show me every location I have forgotten to set the Bar property, which means I can be confident it is set, so I do not need to write extra code that tests whether Bar is set.
- mattlondon 7y ago> TS will show me every location I have forgotten to set the Bar property Yeah this is what I was getting at - e.g. say I have 5 functions that all return Foo object, and for just one of them I need to add in an extra Bar property then I need to make sure that all 5 functions also do the Bar property, even if only 1 needs it (or make it optional, but that might screw with the semantics of the one function that does need it). So now I have a Bar on all Foos, even though only 1 function needs it - things start to get messy. The alternative to changing all 5 functions is just to create a separate type for just that one function that needs Bar Either way it is "extra work" if you are used to the fast and lose javascript way of just adding it there and then and not caring about the others. I agree though that TypeScript is way superior as you point out it would just tell you where you screwed up and I would always start with a new TS project rather than JS today, but I still think there is a place for the raw & dangerous world of untyped JS for rapid and unsafe prototyping and hacking where TS can slow you down.
- wildpeaks 7y agoIf it's just one property, you could specify it's optional using a question mark instead of creating an additional type: type Foo = { Hello: string; Bar?: string; }; But if you really need separated types, the extension syntax is so short that you could define it in the function definition directly: type Foo = { Hello: string; }; function hello(myparam: Foo) {} function world(myparam: Foo & {Bar: string}) {}
- true_religion 7y agoI run the type checker separately from the compiler, which is set to ignore type checking. So in development, I am hack together things and though the type checker complains and my IDE shows plenty of red marks, it will still compile. Once I’m don’t experimenting, I fix the type errors, and refactor.
- lioeters 7y agoMe too. My "dev" script compiles regardless of type check (often I do have it display warnings/errors), and the "build" script explicitly does not compile unless it passes all type checks. It works well for my workflow, sketching quickly until it shapes up, then fill in the details to edit and refine.