I’m definitely not saying I don’t know how I’d go about adding TypeScript to my build process if I wanted to. (Though I might should mention that I don’t usually use any build system that isn’t just straight up part of the Go compiler. go generate specifically.) But it’s one more thing (actually at least 2 more things – the TypeScript compiler and Node, and that’s if you’re not counting the package manager) that I’d need to keep up to date and hunt down backwards incompatible changes or bugs when updating breaks my build.
There are dependencies that are pretty much absolutely necessary (the compiler or interpreter, depending on language, obviously), and if you need a feature badly enough that in practice isn’t worth writing yourself (and isn’t in the standard library), but beyond that you just kindof have to evaluate what dependencies are worth adding and what aren’t. I definitely fall on the side of eschewing dependencies in most optional situations just because adding dependencies willy-nilly has burned me so many times (though I do usually do JS/HTML/CSS minifying).
Meanwhile, build-time type safety isn’t a substitute for (automated and/or manual) testing. And whether the benefits of build-time type safety are worth the drawbacks of having TypeScript/Node/whatever is a calculation everyone has to do. Plus, let’s be honest, there are plenty of other dependences one could add for which the argument is at least as strong as for TypeScript. If you’re using TypeScript, then why not jQuery and Vue and Underscore and Handlebar and Backbone and Grunt and Require and Bower and most importantly these seven jQuery plugins etc? In proactice the alternatives aren’t so much “basically no JS-related dependencies” vs “basically no JS-related dependencies other than TypeScript.” They’re more “basically no JS-related dependencies” vs “a veritable menagerie of JS dependencies.”
What I’m going for here is also about opting out of the samsara that is the ever changing fashion-of-the-week in JS development. And about the only way to do that is to just opt not to use JS dependencies. (Not to say one would have to be absolutist about it. You could say “TypeScript and that’s all,” but if you’re drawing a line, why not draw it one dependency earlier?)
I’m definitely not saying I don’t know how I’d go about adding TypeScript to my build process if I wanted to. (Though I might should mention that I don’t usually use any build system that isn’t just straight up part of the Go compiler.
go generatespecifically.) But it’s one more thing (actually at least 2 more things – the TypeScript compiler and Node, and that’s if you’re not counting the package manager) that I’d need to keep up to date and hunt down backwards incompatible changes or bugs when updating breaks my build.There are dependencies that are pretty much absolutely necessary (the compiler or interpreter, depending on language, obviously), and if you need a feature badly enough that in practice isn’t worth writing yourself (and isn’t in the standard library), but beyond that you just kindof have to evaluate what dependencies are worth adding and what aren’t. I definitely fall on the side of eschewing dependencies in most optional situations just because adding dependencies willy-nilly has burned me so many times (though I do usually do JS/HTML/CSS minifying).
Meanwhile, build-time type safety isn’t a substitute for (automated and/or manual) testing. And whether the benefits of build-time type safety are worth the drawbacks of having TypeScript/Node/whatever is a calculation everyone has to do. Plus, let’s be honest, there are plenty of other dependences one could add for which the argument is at least as strong as for TypeScript. If you’re using TypeScript, then why not jQuery and Vue and Underscore and Handlebar and Backbone and Grunt and Require and Bower and most importantly these seven jQuery plugins etc? In proactice the alternatives aren’t so much “basically no JS-related dependencies” vs “basically no JS-related dependencies other than TypeScript.” They’re more “basically no JS-related dependencies” vs “a veritable menagerie of JS dependencies.”
What I’m going for here is also about opting out of the samsara that is the ever changing fashion-of-the-week in JS development. And about the only way to do that is to just opt not to use JS dependencies. (Not to say one would have to be absolutist about it. You could say “TypeScript and that’s all,” but if you’re drawing a line, why not draw it one dependency earlier?)