Of course it’s not impossible to have a good JavaScript code base, it’s just much harder to have a very large one where it’s still economically feasible to make significant changes to it without having to resort to a rewrite or needing to write tests which would be covered by the compiler in a strongly typed language.
Too bad you don't know me so you're left to ad-hominem attacks on my expertise.
>without having to resort to a rewrite.
Glad you get to move the goalposts anywhere you want to justify any comment you make. You haven't worked on every codebase that ever existed, even though it sounds like you think you have.
In many cases, yes, it is worth a rewrite instead of trying to shoehorn something that exists, only because it exists but is the wrong solution for the new requirements. We're not going to get into the weeds of every kind of refactor in every kind of codebase here on HN, so instead you can move the goalposts and I'll just stop replying here. We can agree to disagree and call it a day.
I also haven't seen every codebase in existence, but I have seen enough "it's only going to take a year" rewrites that absolutely should have been refactorings and so I remain rather skeptical of the claim that rewrites make sense in "many cases".
If dynamically typed languages only worked well in absolutely pristine codebases that never saw any hacks or poorly thought out solutions, I'm not sure they'd be actually useful in most real-life settings. Of course, people refactor all the time in dynamically typed languages as well.
- Don’t have big projects.
- Have lots of unit tests to cover some of what a C# or Java compiler would have caught through static analysis.
- Don’t even consider doing certain kinds of refactoring (which would be trivial on a strongly typed language) because they have no way of knowing what will break.