4 ms·

> Could you outline what you think makes JS more likely to turn into mud-balls compared to other languages? Plain JS is hell to refactor. Between arbitrary aut

> Could you outline what you think makes JS more likely to turn into mud-balls compared to other languages? Plain JS is hell to refactor. Between arbitrary autocasting, little tooling and no useful type system, if you don't have a very detailed test suite, you won't find the parts of your code that are broken now. Also, if you do, you now have to reimplement all those tests that did nothing else than to check your call signatures. Ease of refactoring is a major indicator for a good enterprise language, as constant refactoring is basically the main development process. If your devs are afraid to touch certain pieces of code because nobody knows what the ramifications are, your software is already dying. That's why TypeScript is taking off so nicely. People crave those static guarantees that JS doesn't have.

gbuk2013 7y ago
When you have reached the stage of mud-ball it is already too late. ;) With the appropriate amount of skill and discipline, however, this stage can be postponed for longer than the life of the application. Typescript is absolutely not required.
- adimitrov 7y ago
  But that's a truism. Good coders write good code. Heureka! The real gain is to be had in pushing the mudball stage as far into the product's life cycle in absolute terms as possible. In that sense, nothing is required, but some things help. I argue that TypeScript helps.
  - gbuk2013 7y ago
    If it helps you, great. I’m happy enough with plain JS, thanks. ;)
capableweb 7y ago
I've seen exactly the same problems with large TypeScript codebases as the JavaScript codebases have. Refactoring becomes a hassle not because there is types or not, but because there are endless of useless unit tests testing implementation details, because the architecture is highly coupled in the wrong places and because little care was made when the architecture was dynamically created (because "agile" or what ever) without considerations. Having good and smarter tests helps more for ease of refactoring than having everything mapped to types. But I might just have seen bad examples of TypeScript codebases.
- thrower123 7y ago
  Probably this is a side-effect of translating JS unit-testing techniques without adequate thought and reflection. I am sometimes amazed at the extent of trivial tests that do no more than double-check the compiler that I see from web developers that move up the stack.
  - capableweb 7y ago
    When I talk about shitty unit tests, I mean regardless of language (bad unit tests seems as prevalent in JavaScript, as TypeScript, as Ruby, as Python, Rust, Go and the list goes on)

gbuk2013 7y ago

When you have reached the stage of mud-ball it is already too late. ;) With the appropriate amount of skill and discipline, however, this stage can be postponed for longer than the life of the application. Typescript is absolutely not required.

adimitrov 7y ago
But that's a truism. Good coders write good code. Heureka! The real gain is to be had in pushing the mudball stage as far into the product's life cycle in absolute terms as possible. In that sense, nothing is required, but some things help. I argue that TypeScript helps.
- gbuk2013 7y ago
  If it helps you, great. I’m happy enough with plain JS, thanks. ;)

capableweb 7y ago

I've seen exactly the same problems with large TypeScript codebases as the JavaScript codebases have. Refactoring becomes a hassle not because there is types or not, but because there are endless of useless unit tests testing implementation details, because the architecture is highly coupled in the wrong places and because little care was made when the architecture was dynamically created (because "agile" or what ever) without considerations. Having good and smarter tests helps more for ease of refactoring than having everything mapped to types. But I might just have seen bad examples of TypeScript codebases.

thrower123 7y ago
Probably this is a side-effect of translating JS unit-testing techniques without adequate thought and reflection. I am sometimes amazed at the extent of trivial tests that do no more than double-check the compiler that I see from web developers that move up the stack.
- capableweb 7y ago
  When I talk about shitty unit tests, I mean regardless of language (bad unit tests seems as prevalent in JavaScript, as TypeScript, as Ruby, as Python, Rust, Go and the list goes on)