#ActuallyAutistic web dev. Does front of the front-end. Loves perf and minimalism. Prefers HTML, CSS, Web Standards over JS, UX over DX. Hates div disease.
I think the awful part of the Rise of FP is how it keeps happening over and over again right now. My professional worklife has lasted only seven years, but I'm experiencing a second wave of it. It first happened with CoffeeScript: if you found someone using CS it was very likely they were also very "fond" of FP, and had a very bad attitude towards everything else.
These days we have TypeScript. It is better and more usable tool than CoffeeScript ever was (you can actually read what you wrote the last time!), but somehow it seems to have a link to this same kind of fondness to FP. It is a bit odd as there is nothing FP about TypeScript, but I guess it goes with how people want to use new things.
The thing about React's hooks is that you can clearly see it being helpful and easier to reason about than the old classes. With classes you didn't have as clear path managing state and you just had to know what to do in constructor, componentDidUpdate and componentWillUnmount. It might be an interesting exercise to try and make a custom wrapper over the class logic that would let you make something similar to hooks; not exactly like hooks, instead just make it prettier and easier to reason about state.
Now that was a side step. What I was thinking originally... ah yes, hooks. I guess that pattern made more people aware of FP and thus caused a new additional spike to it, and here we are with another wave of newly found FP enthusiasts that give more credit and value for it than it deserves. Especially if they're at the beginning of their programming career.
It is very troublesome when this happens to individuals who are loud speakers with strong opinions, and no ability to listen.
I guess that pattern made more people aware of FP and thus caused a new additional spike to it, and here we are with another wave of newly found FP enthusiasts that give more credit and value for it than it deserves. Especially if they're at the beginning of their programming career.
FWIW, I'll state again that I use Hooks. I write code just like the sample shown above. I have no problem with the general concept of Hooks. However, I do have a bit of annoyance over how I believe Hooks came to be.
The crowd that believes FP === puttingYourCodeInFunctions && allCodeInsideFunctions === FP was getting themselves in a tizzy over "standard" class-based components in React. On one hand, they sang the praises of "pure" functions and desired to get all of their React code into functions. On the other hand, there was much about React that you simply could not do inside a function declaration.
So they "solved" this by creating Hooks. Now, all their code could be inside those beauteous functions. And they never had to write another one of those scary class keywords again. And they could feel content in the (misplaced) knowledge that they were now truly writing in an FP style.
Some comments have been hidden by the post's author - find out more
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 think the awful part of the Rise of FP is how it keeps happening over and over again right now. My professional worklife has lasted only seven years, but I'm experiencing a second wave of it. It first happened with CoffeeScript: if you found someone using CS it was very likely they were also very "fond" of FP, and had a very bad attitude towards everything else.
These days we have TypeScript. It is better and more usable tool than CoffeeScript ever was (you can actually read what you wrote the last time!), but somehow it seems to have a link to this same kind of fondness to FP. It is a bit odd as there is nothing FP about TypeScript, but I guess it goes with how people want to use new things.
The thing about React's hooks is that you can clearly see it being helpful and easier to reason about than the old classes. With classes you didn't have as clear path managing state and you just had to know what to do in
constructor,componentDidUpdateandcomponentWillUnmount. It might be an interesting exercise to try and make a custom wrapper over the class logic that would let you make something similar to hooks; not exactly like hooks, instead just make it prettier and easier to reason about state.Now that was a side step. What I was thinking originally... ah yes, hooks. I guess that pattern made more people aware of FP and thus caused a new additional spike to it, and here we are with another wave of newly found FP enthusiasts that give more credit and value for it than it deserves. Especially if they're at the beginning of their programming career.
It is very troublesome when this happens to individuals who are loud speakers with strong opinions, and no ability to listen.
This. Sooooo much this!
This is really my entire point - about any mythology.
FWIW, I'll state again that I use Hooks. I write code just like the sample shown above. I have no problem with the general concept of Hooks. However, I do have a bit of annoyance over how I believe Hooks came to be.
The crowd that believes
FP === puttingYourCodeInFunctions && allCodeInsideFunctions === FPwas getting themselves in a tizzy over "standard" class-based components in React. On one hand, they sang the praises of "pure" functions and desired to get all of their React code into functions. On the other hand, there was much about React that you simply could not do inside a function declaration.So they "solved" this by creating Hooks. Now, all their code could be inside those beauteous functions. And they never had to write another one of those scary
classkeywords again. And they could feel content in the (misplaced) knowledge that they were now truly writing in an FP style.