I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
I like your posts and your writing style, I really do. In other had I don't see your point that people don't have problem with classes in TS but they have it with JS. In my experience if somebody hate classes , he/she hates them in both.
Going back to classes vs functions, the problem is that you can make the same thing in both, but classes are tools which were stateful and effectful, where functions are stateless and effectless. It means that in order to replicate class behavior you need to have some third party who does the state part and the effect part. This is exactly what does for example IO Monad or React. React calls these functions and makes them a meaning. It means that effect is rendering and state is provided by hooks.
So we have real two tools for the same thing. That is why in one codebase you can find no classes, as it has different model of state and effect, where in other you have classes and OOP behaviors.
I am not against classes, but classes are OOP construct. And if your codebase have different way of solving problems. You should use this way.
Of course you can also use classes as some framework building block, and that was the React before hooks. What they did though is that they said it was not a great building block, and gave us alternative. You can argue with their decision. But if you have two tools for solving one problem, and one is recommended, then naturally you should probably pick this one.
Still not saying classes are bad, but everything depends from the context. It's a tool, can work for you or not, can be recommended building block or not. I am not a fan and not a hater. If I would go to some language like Java I would use classes, and I have no problem with that. But in React I would not.
In other hand I don't see your point that people don't have problem with classes in TS but they have it with JS. In my experience if somebody hate classes , he/she hates them in both.
I freely admit that this post is based firmly on my current perception of TS-vs-JS. And it may be true that my perception isn't accurate. Or it may apply only to the sites/teams/regions in which I'm active - I don't know. I've just found it strange that now with me diving into TS, I'm running into a whole lotta suggestions from people... to use classes. But that may not map to your experience, or anyone else's.
As for everything else you've written here, I'm pretty much in agreement with you. Despite what you might've picked up from my previous articles, I don't love classes. And I don't hate functions. In fact, for the last couple of months, I've been writing nothing but functions - and for the vast majority of stuff, I'm completely fine with them. In some cases, I actually prefer them.
At the risk of belaboring this point, I wanna mention that your comments here got me to thinking more about the whole classes-vs-functions thing. I'll freely admit that, if you read a lotta my previous articles (and I know you have), it's easy to come away with the impression that "Adam loves classes. And Adam hates functions." And that impression is probably my fault, with regard to my writing style.
But, in my mind at least, my "gripe" isn't really about any particular architecture/tool/library/approach/etc. It's about what happens when you are already using Technique A (and, by your estimation, it's working great), then someone comes along and says, "Technique A sucks. You should be using Technique B."
My "issue" here is probably best illustrated with a traditional, simple Venn diagram:
If Technique B completely coincides with Technique A, then the natural, logical response is to say, "Well, I'll just keep using Technique A." In other words, if you want to do something a completely separate way, but that separate way provides no benefits over the original way, then switching to the new technique is nothing but an exercise in compliance. It'd be like asking you to tear down your brick house because now, everyone is building their houses with cinder blocks - and cinder blocks are just sooooo much cooler.
Of course, it's rare that two different techniques perfectly overlap with each other, right? Typically, the old technique (Technique A) has at least some features that simply aren't accounted for in the new Technique B. Similarly, Technique B presumably has at least some features that simply weren't available in the old Technique A.
So here's the question: Should you swiftly jump to Technique B, just because someone says it's the "new" way to do things??
Well, the answer is usually: Maybe?
Specifically, you'll probably wanna examine whether the things you're gaining in Technique B are more valuable than the things you're losing in Technique A. If you feel that you're losing a lotta cool stuff in Technique A, and you're not gaining much benefit from Technique B, then you'll probably be at least somewhat resistant to adopting Technique B.
With React, a tangible example of this would be class-based lifecycle methods versus the useEffect() Hook in functional components. I'm sure that reasonable minds can disagree on this, but IMHO, useEffect() really kinda... sucks. Even if you agreed with me, does that mean you should ignore Technique B?? No. There are certainly other factors to consider as well. (For example, you've pointed out that Hooks seem to be the recommended way of going forward - and I will freely admit that this is a very valid consideration.)
And this isn't meant as (yet another) defense of classes. There are many other factors to consider aside from lifecycle methods versus useEffect(). But it is at least one valid factor.
As I stated in my previous reply, the simple fact is that, for better or worse, I've actually switched almost-entirely to function-based components. But my point in highlighting the Venn diagram logic is that, in my mind, this isn't really about the benefits of classes or functions. It's about what happens when the "thought leaders" want us to switch our entire process of development - but maybe the net benefits of that switch are not readily apparent.
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.
I like your posts and your writing style, I really do. In other had I don't see your point that people don't have problem with classes in TS but they have it with JS. In my experience if somebody hate classes , he/she hates them in both.
Going back to classes vs functions, the problem is that you can make the same thing in both, but classes are tools which were stateful and effectful, where functions are stateless and effectless. It means that in order to replicate class behavior you need to have some third party who does the state part and the effect part. This is exactly what does for example IO Monad or React. React calls these functions and makes them a meaning. It means that effect is rendering and state is provided by hooks.
So we have real two tools for the same thing. That is why in one codebase you can find no classes, as it has different model of state and effect, where in other you have classes and OOP behaviors.
I am not against classes, but classes are OOP construct. And if your codebase have different way of solving problems. You should use this way.
Of course you can also use classes as some framework building block, and that was the React before hooks. What they did though is that they said it was not a great building block, and gave us alternative. You can argue with their decision. But if you have two tools for solving one problem, and one is recommended, then naturally you should probably pick this one.
Still not saying classes are bad, but everything depends from the context. It's a tool, can work for you or not, can be recommended building block or not. I am not a fan and not a hater. If I would go to some language like Java I would use classes, and I have no problem with that. But in React I would not.
I appreciate your comments!
I freely admit that this post is based firmly on my current perception of TS-vs-JS. And it may be true that my perception isn't accurate. Or it may apply only to the sites/teams/regions in which I'm active - I don't know. I've just found it strange that now with me diving into TS, I'm running into a whole lotta suggestions from people... to use classes. But that may not map to your experience, or anyone else's.
As for everything else you've written here, I'm pretty much in agreement with you. Despite what you might've picked up from my previous articles, I don't love classes. And I don't hate functions. In fact, for the last couple of months, I've been writing nothing but functions - and for the vast majority of stuff, I'm completely fine with them. In some cases, I actually prefer them.
Again - good comments all around.
At the risk of belaboring this point, I wanna mention that your comments here got me to thinking more about the whole classes-vs-functions thing. I'll freely admit that, if you read a lotta my previous articles (and I know you have), it's easy to come away with the impression that "Adam loves classes. And Adam hates functions." And that impression is probably my fault, with regard to my writing style.
But, in my mind at least, my "gripe" isn't really about any particular architecture/tool/library/approach/etc. It's about what happens when you are already using Technique A (and, by your estimation, it's working great), then someone comes along and says, "Technique A sucks. You should be using Technique B."
My "issue" here is probably best illustrated with a traditional, simple Venn diagram:
If Technique B completely coincides with Technique A, then the natural, logical response is to say, "Well, I'll just keep using Technique A." In other words, if you want to do something a completely separate way, but that separate way provides no benefits over the original way, then switching to the new technique is nothing but an exercise in compliance. It'd be like asking you to tear down your brick house because now, everyone is building their houses with cinder blocks - and cinder blocks are just sooooo much cooler.
Of course, it's rare that two different techniques perfectly overlap with each other, right? Typically, the old technique (Technique A) has at least some features that simply aren't accounted for in the new Technique B. Similarly, Technique B presumably has at least some features that simply weren't available in the old Technique A.
So here's the question: Should you swiftly jump to Technique B, just because someone says it's the "new" way to do things??
Well, the answer is usually: Maybe?
Specifically, you'll probably wanna examine whether the things you're gaining in Technique B are more valuable than the things you're losing in Technique A. If you feel that you're losing a lotta cool stuff in Technique A, and you're not gaining much benefit from Technique B, then you'll probably be at least somewhat resistant to adopting Technique B.
With React, a tangible example of this would be class-based lifecycle methods versus the
useEffect()Hook in functional components. I'm sure that reasonable minds can disagree on this, but IMHO,useEffect()really kinda... sucks. Even if you agreed with me, does that mean you should ignore Technique B?? No. There are certainly other factors to consider as well. (For example, you've pointed out that Hooks seem to be the recommended way of going forward - and I will freely admit that this is a very valid consideration.)And this isn't meant as (yet another) defense of classes. There are many other factors to consider aside from lifecycle methods versus
useEffect(). But it is at least one valid factor.As I stated in my previous reply, the simple fact is that, for better or worse, I've actually switched almost-entirely to function-based components. But my point in highlighting the Venn diagram logic is that, in my mind, this isn't really about the benefits of classes or functions. It's about what happens when the "thought leaders" want us to switch our entire process of development - but maybe the net benefits of that switch are not readily apparent.