Rainer is a passionate software developer and loves to work with Angular and Spring. He is a trainer and consultant at AngularArchitects.io and runs ng-news, a weekly Angular newsletter.
Hi Patrick, I've tried out FP with Clojure in larger applications. It turned out that with growing application size it was getting more and more harder to maintain it.
Further more, I see that many JavaScript devs are using TypeScript so that they can have a better support for OOP (and typings of course).
Quite possible, that we weren't simply not able to apply FP property, but in my experience OOP beats it at a certain application size.
Why not have both? I really enjoy the type system provided by TypeScript (which can support both OOP and FP styles) and have begun to use it in all JavaScript projects that aren't one-off scripts. It does make reasoning about one's code much easier.
You will still run into situations where you are better served without classes and you can reach for FP in those scenarios. Anytime I find myself needing to make a class with only static methods for example, I end up just writing a module composed of simple FP-style functions. Anything that requires state I use classes and OOP for. And even within OOP, you can take the knowledge of FP and try to limit the data you mutate.
I'm all for Typescript, especially at scale for the typings, but that has nothing to do with using OOP. The beauty of Typescript is that it's completely opt-in. You can use as much of it, or as little, as you like, depending on what suits your conventions and preferences.
Granted, if you want to go the OOP route, TS will enhance your JavaScript, just as it would for the FP route, depending on how you use it.
Typical FP concepts such as mapping, reducing, currying etc., are all greatly improved by statically defining the types of parameters and return values, for example.
If somebody really likes to embrace the full OOP world, JavaScript isn't ideal. I'd recommend Java, or better yet: Kotlin for that approach.
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.
Hi Patrick, I've tried out FP with Clojure in larger applications. It turned out that with growing application size it was getting more and more harder to maintain it.
Further more, I see that many JavaScript devs are using TypeScript so that they can have a better support for OOP (and typings of course).
Quite possible, that we weren't simply not able to apply FP property, but in my experience OOP beats it at a certain application size.
Why not have both? I really enjoy the type system provided by TypeScript (which can support both OOP and FP styles) and have begun to use it in all JavaScript projects that aren't one-off scripts. It does make reasoning about one's code much easier.
You will still run into situations where you are better served without classes and you can reach for FP in those scenarios. Anytime I find myself needing to make a class with only static methods for example, I end up just writing a module composed of simple FP-style functions. Anything that requires state I use classes and OOP for. And even within OOP, you can take the knowledge of FP and try to limit the data you mutate.
I'm all for Typescript, especially at scale for the typings, but that has nothing to do with using OOP. The beauty of Typescript is that it's completely opt-in. You can use as much of it, or as little, as you like, depending on what suits your conventions and preferences.
Granted, if you want to go the OOP route, TS will enhance your JavaScript, just as it would for the FP route, depending on how you use it.
Typical FP concepts such as mapping, reducing, currying etc., are all greatly improved by statically defining the types of parameters and return values, for example.
If somebody really likes to embrace the full OOP world, JavaScript isn't ideal. I'd recommend Java, or better yet: Kotlin for that approach.