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