6 ms·

The functional zealotry stink permeates every corner of React. The Ember approach seems much more aligned with my preferences.

by jtdev 6y ago

yowlingcat 6y ago
+1. I think hooks is what finally pushed me over the edge towards saying to myself, enough with this insanity.
- aphextron 6y ago
  >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.
  - jtdev 6y ago
    > "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.
    - aphextron 6y ago
      > 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.
      - awesomepeter 6y ago
        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.
        aphextron 6y ago
        >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.
      - flowerlad 6y ago
        > 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.
  - pzuraq 6y ago
    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).
  - lhorie 6y ago
    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 https://news.ycombinator.com/item?id=926140
  - nobleach 6y ago
    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.
flowerlad 6y ago
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!
- searchableguy 6y ago
  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..
- nonsense1234 6y ago
  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.
  - 6y ago
dang 6y ago
Please don't break the site guidelines like this. Make your substantive points thoughtfully. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

The functional zealotry stink permeates every corner of React. The Ember approach seems much more aligned with my preferences.

by jtdev 6y ago

The functional zealotry stink permeates every corner of React. The Ember approach seems much more aligned with my preferences.

yowlingcat 6y ago

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

aphextron 6y ago
>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.
- jtdev 6y ago
  > "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.
  - aphextron 6y ago
    > 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.
    - awesomepeter 6y ago
      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.
      - aphextron 6y ago
        >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.
    - flowerlad 6y ago
      > 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.
- pzuraq 6y ago
  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).
- lhorie 6y ago
  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 https://news.ycombinator.com/item?id=926140
- nobleach 6y ago
  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.

flowerlad 6y ago

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!

searchableguy 6y ago
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..
nonsense1234 6y ago
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.
- 6y ago

dang 6y ago

Please don't break the site guidelines like this. Make your substantive points thoughtfully. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html