Please don't break the site guidelines like this. Make your substantive points thoughtfully.

https://news.ycombinator.com/newsguidelines.html

I don't get why so many JavaScript developers thing functional is cool. Functional has been around for 30+ years. OOP won against functional because OOP is easier to understand and leads to more maintainable code. These days people are taking a second look at functional because functional avoids state, which makes it easier to write concurrent code with no locks. (This has suddenly become important because Moore's law is coming to an end, and CPUs are adding more cores instead of making cores faster and faster.) But this advantage of functional is not applicable to JavaScript because there are no locks in JavaScript in any case!

JavaScript is also an extremely bad functional language unless you don't mind ridiculous memory bloat and inefficiency. To be even reasonably efficient you're basically forced to use classes because the primary ergonomic alternative is objects that contain functions that close over lexical scope. This is ridiculously inefficient because functions that would normally have a single instance on the prototype chain are now duplicated for every single object. Modern JavaScript engines can't optimize this without breaking the spec which they obviously won't do. You can resort to just using plain functions and objects that contain nothing but data but this quickly becomes quite ugly without a pipeline operator.

The standard library is also filled with mutating methods and doesn't include proper functional data structures and pure JavaScript implementations of functional data structures, such as immutable.js, are so slow that you might as well just use arrays and objects and repeatedly do shallow copies.

Programs that stress functional purity in JavaScript are becoming hard to meaningfully benchmark because instead of having a few hotspots absolutely everything is incredibly inefficient and slow. Death by a thousand cuts.

To be fair, JavaScript is also an extremely bad OOP language.

And I’m not complaining about its prototypical inheritance either (I actually like it), but the fact that it tries to hide its prototypical nature under a Java like veneer.

It’s hardly JS developers who think functional programming is cool. Scala became huge in the JVM world because of its functional nature. Kotlin includes a lot of functional programming, and Java itself continues to add functional capabilities.

And if you look at the .Net side of things, C# has basically been on a path to look increasingly like F# with every release. And of course, LINQ, one of C#’s most popular features, is little more than a functional subset of C#.

Arguably its backend developers moving to the front end who have been trying to bring functional concepts to front end programming.

Functional programming actually brings some benefits to backend code. To take advantage of the extra cores in a CPU you add threads, but if these threads are continually needing to lock in order to access shared state then concurrency is diminished. The more cores you have, the more threads you have, and then the more you have to lock. Functional style solves this problem by not having mutable state, thus eliminating the need to lock.

But when it comes to JavaScript these benefits don't exist. That's not to say there are no benefits at all to incorporating some functional style into JavaScript code, but wholesale replacement of OOP with functional style is not warranted.

Yeah. I have noticed few instances of badly optimised functional code.

something like

  examples.reduce((accumulator, example) => {

    // logic
   
    return {...accumulator,[example.name]: example.value }

  }, {})

Object spreading and destructuring combined with fancy immutable array methods smell..

+1. I think hooks is what finally pushed me over the edge towards saying to myself, enough with this insanity.

>I think hooks is what finally pushed me over the edge towards saying to myself, enough with this insanity.

Did you actually build anything with Hooks? I was pretty turned off by it at first sight as well. It doesn't jive with the sensibilities of a class based OOP developer's natural instincts. But once you start using pure functional components it all makes sense and your code becomes so much cleaner and easier to reason about. No more component lifecycles and massive class files.

Isn't that just comparing old code (i.e. code that has grown organically) vs new code (code that hasn't yet)? Surely given enough time you'll end up with just as large/complex a function as an olden class?

The proposition of hooks is that they do accomplish the same things as class lifecycle methods do, just in a different way, so all the underlying complexity must still be there by definition.

This discussion reminds of this little parable[1]

> The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

> On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

[1] https://news.ycombinator.com/item?id=926140

When hooks first came out and I started playing with the API, I had the same feeling! It felt refreshing, but I couldn't quite nail down why.

I don't think it's that you don't have to worry about lifecycles, in the end. You still do - you have to understand the lifecycles of your functions which are different than those of a component class, but they are lifecycles in there own way. What I think really makes hooks feel nice is you can _close over_ the small, self-contained lifecycles, and introduce them at any point in the program in a composable way. That's pretty neat actually, and what we've taken away from hooks currently.

Maybe that's not the only benefit they have, but it's a pretty large one, so I'm glad hooks decided to explore this new direction, even if I'm not completely sold on it (as in, wouldn't introduce it in Ember just yet).

> "once you start using pure functional components it all makes sense and your code becomes so much cleaner and easier to reason about"

This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I guess I'm among the ranks that can't see the clothes.

> This is the "Emperor's new clothes" argument that the FP zealots march out over and over again.

I wouldn't call myself a zealot. We chose functional components for a new project on my team as a direct response to problems we were having with maintainability of larger React applications. Specifically that class components tend to get massively bloated over time with business logic, lifecycle based rendering logic, and local state. I was skeptical at first as well. But it turns out that once you start fully separating things out into reducers and actions, the class becomes little more than boilerplate. When you enforce that there are no class members or local state allowed in UI components, it pushes people into proper separation of concerns. The project becomes much more maintainable as you don't have to dig around through components to find out what's going on.

> Specifically that class components tend to get massively bloated over time with business logic

You have been doing it wrong. Don't put business logic into visual components. UI technologies tend to be a fad. Business logic needs to live longer than UI technologies, and needs to be separated from UI components for testability, maintainability, reusability and longevity.

Couldn't you do the same thing with class components though? From what you've mentioned it seems you've mostly moved complicated logic into reducers. I may misunderstand though.

>Couldn't you do the same thing with class components though?

Sure. But the point is that the entire class syntax becomes superfluous once you do that. Everything becomes a pure functional component, and you can just throw in a `useEffect` wherever the need for lifecycle based side effects arises.

What I like about hooks: They ask us to question some long-standing "best practices". I feel like we should do this every so often as it promotes progress in our thinking.

What I dislike: They promote patterns that go against long-standing "best practices". (Should we really be defining functions over and over and over again?)

So, the biggest advantage, is also my biggest gripe.