I’d pick this over a framework. As long as everything is lazy computed so my serverless cold starts don’t take forever initializing everything. Good video! My argument is mainly why not just import the logger directly? Like what are we truly gaining by avoiding depending on implementations directly? If every file imports from a single logger module, the esm module system already acts as a singleton pattern.
@WebDevCody I did originally intend to address this point as well. The "clean code" argument regarding compilation is indeed nonsense in most cases. You're right there. You're wrong, though, that it doesn't affect JS. It's actually worse for JS since a static language compiles only once, but an interpreted language has to lead and process all dependencies every time it runs. But the entire compilation argument makes only sense if and only if the dependency referenced is in a different compilation unit / package from both the interface / type and the user. Otherwise, it obviously gets compiled every time (except with incremental compilers). JS loads it either way since it's on the hot path, so... eh. Add to that that modern compilers are really fast and you can compile huge code bases in seconds and the argument just becomes silly... And if the package contains the composition root (DI container in this case), then it loads / compiles it either way, cause it's being directly imported by this root... so... eh. Add to this that serverless functions are supposed to be small... Dependency inversion only makes sense when and if you expect different implementations of that depency to be ever used. It's just unnecessary otherwise. We often simply don't know if that is the case, and therefore, it is often better practice to do so. Logger was just an example and tbh, in a client project I'd probably just import the logger directly and leave the logging module to sort out what logger that is based on env variables and or other configuration. But if this were a library, then I wouldn't want to force my specific logging choice on the consumer and just tell them the interface. Could this be solved via a configuration function in the logging module as well? Yes. In JS at least. So... eh. Really only matters if you intend to use the same function for different implementations, like the different writers in your example. Anywho... TL;DR; it depends.
While I'm not a particular fan of typescript, I am confused about what this statement is supposed to mean in the context of my video or what prompted it...
@@voidedname nothing against your video, it was actually very informative. My comment stems from the composition of typescript interfaces and types. It is way overcomplicated for something which should be very straightforward (typescript, not your implementation). To me, it’s just a horrible language 🥴
Thx :) I do agree that the type system suffers a lot from how cryptic it is to use. And that it's built on top of js with all of the issues js has doesn't do it any favours either.
I’d pick this over a framework. As long as everything is lazy computed so my serverless cold starts don’t take forever initializing everything. Good video! My argument is mainly why not just import the logger directly? Like what are we truly gaining by avoiding depending on implementations directly? If every file imports from a single logger module, the esm module system already acts as a singleton pattern.
@WebDevCody I did originally intend to address this point as well. The "clean code" argument regarding compilation is indeed nonsense in most cases. You're right there. You're wrong, though, that it doesn't affect JS. It's actually worse for JS since a static language compiles only once, but an interpreted language has to lead and process all dependencies every time it runs.
But the entire compilation argument makes only sense if and only if the dependency referenced is in a different compilation unit / package from both the interface / type and the user. Otherwise, it obviously gets compiled every time (except with incremental compilers). JS loads it either way since it's on the hot path, so... eh.
Add to that that modern compilers are really fast and you can compile huge code bases in seconds and the argument just becomes silly...
And if the package contains the composition root (DI container in this case), then it loads / compiles it either way, cause it's being directly imported by this root... so... eh.
Add to this that serverless functions are supposed to be small...
Dependency inversion only makes sense when and if you expect different implementations of that depency to be ever used. It's just unnecessary otherwise. We often simply don't know if that is the case, and therefore, it is often better practice to do so.
Logger was just an example and tbh, in a client project I'd probably just import the logger directly and leave the logging module to sort out what logger that is based on env variables and or other configuration. But if this were a library, then I wouldn't want to force my specific logging choice on the consumer and just tell them the interface. Could this be solved via a configuration function in the logging module as well? Yes. In JS at least. So... eh.
Really only matters if you intend to use the same function for different implementations, like the different writers in your example.
Anywho... TL;DR; it depends.
Nah, its not readable on mobile
I apologise, it is on mine, although a bit small. I'll consider bumping up the font size next time.
Typescript is proper cancer
While I'm not a particular fan of typescript, I am confused about what this statement is supposed to mean in the context of my video or what prompted it...
@@voidedname nothing against your video, it was actually very informative. My comment stems from the composition of typescript interfaces and types. It is way overcomplicated for something which should be very straightforward (typescript, not your implementation). To me, it’s just a horrible language 🥴
Thx :)
I do agree that the type system suffers a lot from how cryptic it is to use. And that it's built on top of js with all of the issues js has doesn't do it any favours either.