Even ignoring for a moment that I consider being highly practiced at dynamism a largely pointless skill while strongly typed languages exist, sooner or later a code base which is always growing will reach a certain size where even the very best person in the world at dynamism will have to resort to unit tests to cover what a compiler can do for free, or just accept that certain refactoring or changes to the code base are unreasonably expensive to do with any reasonable level of confidence.

I'm the guy with a huge javascript codebase, written before typescript existed, and I have none of the problems you describe. Huge refactors are also not a necessity in every codebase, if the code was written well to begin with. And so far using typescript in other projects has not produced the supposed benefits a lot of people say are inherent with typescript. There is no magic happening that saves me from writing bad code, because I wasn't writing bad code before typescript. Refactoring isn't all that difficult either, even without tests. But I guess YMMV.

Good code becomes bad when the requirements change sufficiently in ways the original design didn't anticipate.

Great, but that doesn't describe every Javascript project or use of Javascript. If you're describing big changes, chances are a refactor isn't what's needed, a rewrite is. And even when requirements change, it doesn't mean Javascript can't be refactored. It depends on the skill of the team. If you want to hire idiots then you're going to need more than strong types to get anything shipped. I doubt types would really help that much in some places because programmers love to invent their own footguns.

The fact you think that big changes more often than not necessitate a rewrite makes you sound like someone who’s never worked on a very large strongly typed code base where big changes and refactors are absolutely possible, and happen in a reasonable timeframe, without having to resort to a rewrite.

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.

>makes you sound like

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.

> In many cases, yes, it is worth a rewrite instead of trying to shoehorn something that exists

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

Thanks for your anecdotal comment, but it really only means something to you.

I could say the same about your comments. Your snarkiness is not appropriate for this website. Don't start commenting if you're not open to having your views challenged.

> Huge refactors are also not a necessity in every codebase, if the code was written well to begin with.

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.

They probably are also more beautiful too huh?