Besides the click bite title, I find the problems you're describing are not a thing that typescript itself is a solution too.
All of them are tooling and design problems.
Finding Existing 'Linking' Issues
This is solved by VSCode or Webstorm
You just have to use Import/Export's
Strongly-typed Variables
typeof is your friend here
Okay typeof has it strange behaviors
Also TypeScript also has its quirks here Promise<MyType<T>>. Is this more helpful maybe?
Catching silly mistakes with ESLint
Not related to Typescript
Introducing Classes
Not related to TypeScript
Putting everything into classes can also tend to code overhead and bad design and structure. Look at any more significant Java project
Eliminating Global State
Not related to TypeScript
Can be solved with ESlint
Testability
Not related to TypeScript
Testing is hard
In general, it sounds more like what the most significant difference here is that the team is more experienced and knows better what is needed. I'm not against TypeScript. It has its good things, but also it has its downsides. Like no abstract classes. Even OOP fanatics now say that composition is a better way then class inheritance (SOLID principle).
Yep.
I am against TS (i think its more an obfuscator and a distraction than anything else) and tihs is exactly what i was expecting going into this link. That most likely it will be all fixed by other things, but TS brings clicks, so here we are.
Typescript adds expressive compile time type info. typeof doesn't compare. I think the main point was that the extra safety from types made the other refactoring possible. That's not surprising since types are basically a kind of formal proof of program code.
I hear this from the first time I ever coded and still, I have never seen a study/scientific proof of that being true. Most of the time it is just gut feeling.
The example in the code was about how == and === works in JS and that '1' === 1 is not good.
In all of that discussion what people tend to forget: In the end, it is Javascript that runs.
To say typeof doesn't compare is absurd. Compile-time type-checking definitely has its uses; but people seem to forget that (unless I am very much mistaken) no type checking is being carried by the compiled code at run time. In which case you absolutely must do type-checking on data coming from sources outside your application. Typescript is not a replacement for proper data validation for which typeof is pretty much essential.
You are correct - TypeScript's checks are entirely at the transpilation level. You do occasionally need to do some checking at some boundaries, but things inside of your systems can generally be trusted to be properly typed if you have proper validation at the boundaries and rely on tsc to catch the other issues.
Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.
The nesting on comments maybe isn't clear - but I think only one of my comments was directed specifically to you ;)
edit: And just to be clear: I thought your article was interesting; but the focus on TS as the solution to the problems you described could be inferred by some to mean that JS was the cause of those problems.
You are correct in the experienced aspect. However, the point in question here is that given a specific JS file with thousands of lines with existing issues, you need a way of making sense of it. TypeScript was that way, and the conversion process was what closed a multitude of bugs.
You'd be surprised what WebStorm has trouble interpreting with enough global state and dynamic code.
So, if there was a more efficient way of removing all bugs from the file, I'd love to hear it, but I will not debate that this was the answer I chose, and that it was extremely effective and needed.
Of course the ideal is to create a big project with best practices from the beginning. I think the post is about a time that didn't happen, and how TS was the shortest path to a more robust codebase. Not that it's a holy grail, but that it helps make sense out of spaghetti.
Yeah exactly! The goal was: clean up the code and create best practices at least this is what I get from that post!
My argument was: As far as I can see for the reasons mentioned here in the post is not fully typescript but also eslint and the most important thing: the team! The team now has a better base to do great work! They are now more experienced and know their domain better! I can guarantee if they would rewrite it in plain javascript with eslint they would be as good as they are now with typescript. The only thing they have no bigger job security because 2 3 years from now we as a community will agree that typescript is not the thing we needed. Like it happened before with CoffeeScript and flow.
But maybe I'm completely wrong.
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.
Besides the click bite title, I find the problems you're describing are not a thing that typescript itself is a solution too.
All of them are tooling and design problems.
Finding Existing 'Linking' Issues
Strongly-typed Variables
typeofis your friend heretypeofhas it strange behaviorsPromise<MyType<T>>. Is this more helpful maybe?Catching silly mistakes with ESLint
Introducing Classes
Eliminating Global State
Testability
In general, it sounds more like what the most significant difference here is that the team is more experienced and knows better what is needed. I'm not against TypeScript. It has its good things, but also it has its downsides. Like no abstract classes. Even OOP fanatics now say that composition is a better way then class inheritance (SOLID principle).
Yep.
I am against TS (i think its more an obfuscator and a distraction than anything else) and tihs is exactly what i was expecting going into this link. That most likely it will be all fixed by other things, but TS brings clicks, so here we are.
Thanks for the feedback. I'll let product know we're reverting to last year's version of the code and going with a new approach.
This is a testimonial as to how a language helped me. Please keep hate out of it.
Typescript adds expressive compile time type info.
typeofdoesn't compare. I think the main point was that the extra safety from types made the other refactoring possible. That's not surprising since types are basically a kind of formal proof of program code.I hear this from the first time I ever coded and still, I have never seen a study/scientific proof of that being true. Most of the time it is just gut feeling.
The example in the code was about how
==and===works in JS and that'1' === 1is not good.In all of that discussion what people tend to forget: In the end, it is Javascript that runs.
To say
typeofdoesn't compare is absurd. Compile-time type-checking definitely has its uses; but people seem to forget that (unless I am very much mistaken) no type checking is being carried by the compiled code at run time. In which case you absolutely must do type-checking on data coming from sources outside your application. Typescript is not a replacement for proper data validation for whichtypeofis pretty much essential.You are correct - TypeScript's checks are entirely at the transpilation level. You do occasionally need to do some checking at some boundaries, but things inside of your systems can generally be trusted to be properly typed if you have proper validation at the boundaries and rely on
tscto catch the other issues.I am not mistaken. From Typescript design goals:
I feel like you're really wanting to talk.
Is that a problem?
The nesting on comments maybe isn't clear - but I think only one of my comments was directed specifically to you ;)
edit: And just to be clear: I thought your article was interesting; but the focus on TS as the solution to the problems you described could be inferred by some to mean that JS was the cause of those problems.
You are correct in the experienced aspect. However, the point in question here is that given a specific JS file with thousands of lines with existing issues, you need a way of making sense of it. TypeScript was that way, and the conversion process was what closed a multitude of bugs.
You'd be surprised what WebStorm has trouble interpreting with enough global state and dynamic code.
So, if there was a more efficient way of removing all bugs from the file, I'd love to hear it, but I will not debate that this was the answer I chose, and that it was extremely effective and needed.
I mean the first red flag for me here was: having a file with thousands of line. Again bad design or bad practice.
My point was again not saying that typescript itself is bad but it is not the holy grail.
Team communication, team standards and aiming for best practice are.
I'm not debating the answer here. For me it just looks like the wrong conclusion what helped is mad here.
But this is just my view and both are okay.
Of course the ideal is to create a big project with best practices from the beginning. I think the post is about a time that didn't happen, and how TS was the shortest path to a more robust codebase. Not that it's a holy grail, but that it helps make sense out of spaghetti.
Yeah exactly! The goal was: clean up the code and create best practices at least this is what I get from that post!
My argument was: As far as I can see for the reasons mentioned here in the post is not fully typescript but also eslint and the most important thing: the team! The team now has a better base to do great work! They are now more experienced and know their domain better! I can guarantee if they would rewrite it in plain javascript with eslint they would be as good as they are now with typescript. The only thing they have no bigger job security because 2 3 years from now we as a community will agree that typescript is not the thing we needed. Like it happened before with CoffeeScript and flow.
But maybe I'm completely wrong.