Founder & CEO @ Wolk Software | EP @ JSConfIE | Former TypeScript Microsoft MVP, writer, speaker technology-lover and OSS enthusiast. Author of InversifyJS.
Well, I can enjoy some of the things I like about Node.js / JavaScript / TypeScript:
I love JavaScript.
I love static types.
I enjoy not having to think about threads and deadlocks (non-blocking I/O and single threaded).
I like being able to share code between my front end and my backend (e.g., some interface declarations and domain entities).
I like the speed of change of the JavaScript community (for some it is fatigue for me it is excitement).
I like the fact that Node.js is self-hosted (don't have to deal with tomcat or anything like that).
I like that the whole thing is very lightweight (except the node_modules folder xD).
I like that being able to execute client-side code on the server side (e.g., React server-side rendering)
But I also get some of the benefits of Java / C#. I had many conversations with many engineers and some of them are completely against things like dependency injection in JavaScript.
They argue that it is not needed because in JavaScript you can monkey patch everything if you need to mock something during a unit test and the same applies to languages like Ruby. For example, you can read this post.
On the other hand, you have people like me or Rob Wormald:
“Typically when I go to JavaScript conferences and I talk about dependency injection people are like ¿What?, ¿What is dependency injection? ¿Why would you do that?... I love coming Build (Microsoft conference for developers) because I can talk about dependency injection and everybody in this room is probably convinced that it is a good idea” - Rob Wormald, Developer Advocate @ Google
This is cool for me, after a long time thinking about this topic (I'm quite passionate about this topic), I have reached the conclusion that it is not right or wrong. If monkey patching works well for you and your team that is awesome. I stand on the other side: monkey patching and lack of static types don't work well for me.
I appreciate questions like yours because as I said I love thinking about this topic :) When I wrote this article I wasn't saying "This is the way you should build Node.js apps", what I was trying to say was "This is the way I've been building very large monolithic apps, with large teams and it has been working very well so far".
Yes, I totally understand what you are saying. DI it's pretty cool and it's something that I suffered while I was a working with Ruby. I mean, you can redefine methods or classes at execution time when you need it. But it could be pretty complex at the beginning.
Like you say, there's not good or right for this kinds of topics.
Thanks for your answer!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Well, I can enjoy some of the things I like about Node.js / JavaScript / TypeScript:
But I also get some of the benefits of Java / C#. I had many conversations with many engineers and some of them are completely against things like dependency injection in JavaScript.
They argue that it is not needed because in JavaScript you can monkey patch everything if you need to mock something during a unit test and the same applies to languages like Ruby. For example, you can read this post.
On the other hand, you have people like me or Rob Wormald:
This is cool for me, after a long time thinking about this topic (I'm quite passionate about this topic), I have reached the conclusion that it is not right or wrong. If monkey patching works well for you and your team that is awesome. I stand on the other side: monkey patching and lack of static types don't work well for me.
I appreciate questions like yours because as I said I love thinking about this topic :) When I wrote this article I wasn't saying "This is the way you should build Node.js apps", what I was trying to say was "This is the way I've been building very large monolithic apps, with large teams and it has been working very well so far".
Yes, I totally understand what you are saying. DI it's pretty cool and it's something that I suffered while I was a working with Ruby. I mean, you can redefine methods or classes at execution time when you need it. But it could be pretty complex at the beginning.
Like you say, there's not good or right for this kinds of topics.
Thanks for your answer!