If I’m writing a Go app with a JS frontend component but then I decide to use Typescript, suddenly I have NPM, Node, and realistically probably some JS build system like Grunt as dependencies of my project.
Basically, it just adds more moving parts to the project when I could get away with a) a simpler build process and b) less separation between me and the browser.
To be fair, I’ve never used TypeScript, but this is what’s kept me from using TypeScript.
For your Go code to be useful, you’ve got to set up the Go compiler right?
As much as I wouldn’t recommend it, you can even install the typescript compiler via an OS package manager (at least in most Debian distributions)
At that point (and once you’ve added it to your makefile, or however else you’re triggering your go build), surely then there’s zero additional moving parts needed to compile your front end vs your backend?
Not least of all, I’d argue having a compiler tell me I messed up immediately is a bonus too vs poking around for some time until I get an error in the JS console
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?)
You are making a lot of false assumptions about typescript and bringing in a lot of outside problems that don’t have anything to do with the language. Try working with typescript. It is a strict super set of javascript. So if you like vanilla JS, you can just keep writing it, then slowly introduce the syntactic sugar that typescript provides. I did the javascript and coffee script thing for a long while, and typescript is just the better way for most use cases at this point.
problems that don’t have anything to do with the language.
My concerns about it don’t have anything to do with the language. More the tooling that would come with it.
If browsers natively understood TypeScript, I’d use the type-safety features. But I don’t want things like the TypeScript compiler or Node to be a dependency of my build process. Not if the only payoff is type safety.
I usually write Typescript with Vue and SSR so my server and client are using the same tooling. If I was writing a basic frontend with minimal JavaScript I would just (and have) use jsdoc for typing.
But let’s be fair, what you mentioned as dependencies are development dependencies and don’t impact the end user (outside of poorly optimized build systems causing issues). Build systems can have some great benefits. Such as reducing file size by utilizing methods such as tree shaking to prune out the unused classes in a CSS library.
It just comes down to choosing the tools to suit the job. Sure, you can use a table saw to cut a stick but it’s probably easier just to use a handsaw. Whereas if you’re cutting a large plywood board you could make do with a handsaw but it’ll take longer and the result might not be pretty.
They do if I the developer am spending time maintaining my dependencies rather than implementing feature X that the end user wants.
Build systems can have some great benefits.
As does not having multiple distinct yet interacting build systems in one project.
unused classes in a CSS library.
I have yet to have a use for any CSS libraries. Maybe that has more to do with the problem domain in which I write than anything. Maybe some day I’ll run into a situation where I feel I’d be better served using a CSS library, but it hasn’t happened yet.
If I’m writing a Go app with a JS frontend component but then I decide to use Typescript, suddenly I have NPM, Node, and realistically probably some JS build system like Grunt as dependencies of my project.
Basically, it just adds more moving parts to the project when I could get away with a) a simpler build process and b) less separation between me and the browser.
To be fair, I’ve never used TypeScript, but this is what’s kept me from using TypeScript.
For your Go code to be useful, you’ve got to set up the Go compiler right?
As much as I wouldn’t recommend it, you can even install the typescript compiler via an OS package manager (at least in most Debian distributions)
At that point (and once you’ve added it to your makefile, or however else you’re triggering your go build), surely then there’s zero additional moving parts needed to compile your front end vs your backend?
Not least of all, I’d argue having a compiler tell me I messed up immediately is a bonus too vs poking around for some time until I get an error in the JS console
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?)
You are making a lot of false assumptions about typescript and bringing in a lot of outside problems that don’t have anything to do with the language. Try working with typescript. It is a strict super set of javascript. So if you like vanilla JS, you can just keep writing it, then slowly introduce the syntactic sugar that typescript provides. I did the javascript and coffee script thing for a long while, and typescript is just the better way for most use cases at this point.
My concerns about it don’t have anything to do with the language. More the tooling that would come with it.
If browsers natively understood TypeScript, I’d use the type-safety features. But I don’t want things like the TypeScript compiler or Node to be a dependency of my build process. Not if the only payoff is type safety.
To be fair, I’ve never written frontend. No doubt the problems there are a bit different.
I usually write Typescript with Vue and SSR so my server and client are using the same tooling. If I was writing a basic frontend with minimal JavaScript I would just (and have) use jsdoc for typing.
But let’s be fair, what you mentioned as dependencies are development dependencies and don’t impact the end user (outside of poorly optimized build systems causing issues). Build systems can have some great benefits. Such as reducing file size by utilizing methods such as tree shaking to prune out the unused classes in a CSS library.
It just comes down to choosing the tools to suit the job. Sure, you can use a table saw to cut a stick but it’s probably easier just to use a handsaw. Whereas if you’re cutting a large plywood board you could make do with a handsaw but it’ll take longer and the result might not be pretty.
They do if I the developer am spending time maintaining my dependencies rather than implementing feature X that the end user wants.
As does not having multiple distinct yet interacting build systems in one project.
I have yet to have a use for any CSS libraries. Maybe that has more to do with the problem domain in which I write than anything. Maybe some day I’ll run into a situation where I feel I’d be better served using a CSS library, but it hasn’t happened yet.