5 ms·

I think you may be missing the forest for the trees. The point of FP is that you can glance at a function and say 'this is obviously correct' without having to

I think you may be missing the forest for the trees. The point of FP is that you can glance at a function and say 'this is obviously correct' without having to work out the state and context of every call.

ojkelly 4y ago
But you can do that with algebraic effects. That’s kind of the point. You keep the clarity of declaring what you want to happen, and abstract the how to the effect handler.
- petilon 4y ago
  None of that is true in React hooks. The negative sentiment towards hooks that you see here is because it is weird and complicated. Want to see how much simpler code can get when you code without React or any such fat frameworks? Take a look: https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp https://github.com/wisercoder/eureka/tree/master/webapp/Clie... You just need to know JavaScript, HTML and CSS, not much else. The code is simple, and yet maintainable. No need for hooks, useEffect, useState, useMemo and all that crap.
  - _v7gu 4y ago
    How can you ever be sure that your state is valid when you’re putting it on the DOM? Worse yet, only parts of the state is stored there. I can’t really call this code simple since it had to resort to timing hacks to get its functionality in order. A random 250ms delay and bam, bugs you cannot reliably reproduce
    - petilon 4y ago
      Can you clarify what you mean here? What state is in DOM? Do you mean the state inherent in input elements? What timing hacks are you talking about?
      - _v7gu 4y ago
        The first file I looked into was the combo box. This is what I consider to be a timing hack: private onDropDownMouseOver(ev: MouseEvent): void { if ((new Date()).getTime() < this.whenScrolled + 250) { // We automatically get a hover event when we scroll, ignore it in order to keep our current highlight. return; } const element = ev.target as HTMLElement; if (element.classList.contains('combo-dropdown-item')) { addClassExclusively(element, 'combo-highlighted'); } } Some event stores the time it has been fired, and this method checks that it has not been long since the firing. With react, which item has the highlight would have to explicitly be in the state and completely remove the need to do this optimization. And this is an example of what I consider state being stored in the DOM: private isDropDownVisible() { return isVisible(this.dropDown); } The view has logic that depends on whether the dropdown is visible, which is checked by dropdown.style.display !== none. Now any element in your page has the power to modify this component’s logic by modifying the DOM
        petilon 4y ago
        The timing hack is a workaround for a browser bug. The exact same hack would be required in React as well. What is this browser bug I speak of? Browsers send a spurious "hover" event when you stop scrolling, so that the item under mouse can be highlighted. This can cause problems in some cases. > Now any element in your page has the power to modify this component’s logic by modifying the DOM If some part of your application intentionally does something wrong, it can break your application whether it is React or some other tech. In this particular example, if you prefer, you can have a member variable to keep track of whether the dropdown is visible or not. Still no need for React. As you can see, none of the complexity of React is necessary. No need for hooks, useEffect, useState, useMemo and all that crap.
        _v7gu 4y ago
        Would it, though? Keyboard event sets highlighted item key/id; scroll event pops up, sets the highlighted item again, then react does not do an additional render because the state has not changed since the keyboard event. The code does not have any complexities of hooks (which are just a javascript approximation of do notation, I don’t believe it is that complex), but what it does have is the requirement to write down all of your mutations correctly, where every “down” is an exact opposite of the “up” and does not leave any artifacts—with no way of formally checking. At least for myself, I think that level of discipline is unreasonably high so I tend to prefer stricter typed functional solutions where the view is composed purely from the state
    - creamyhorror 4y ago
      I'm not sure what timing hacks you're referring to - using setTimeout() with 0 delay? I think that's being done to defer execution of heavier functions and let other timeouts be handled first. Seems more like an optimisation rather than a hack to achieve basic functionality.
  - javcasas 4y ago
    https://github.com/wisercoder/eureka/blob/master/webapp/ClientApp/controllers/AdminController.ts#L42 https://github.com/wisercoder/eureka/blob/master/webapp/Clie... I love how you do React. I mean, what's more react-y than blanking the page then appending HTML? I'm gonna call that Rejqueryact, because it's jQuery inside React.
    - creamyhorror 4y ago
      I'm not seeing React being used, though, just TSX/JSX? All the view and state updating is being done manually, but it looks fairly well-organised. There are small optimisations like debouncing onInput with a timeout (avoiding rapid re-rendering/reacting to every character typed): https://github.com/wisercoder/eureka/blob/master/webapp/ClientApp/views/FilterControl.tsx https://github.com/wisercoder/eureka/blob/master/webapp/Clie... Is this really much more complicated to implement than the equivalent implementation in React? (It's probably a bit more responsive, at least.)
      - ojkelly 4y ago
        I think they’re referring to how Reacts mental model is to wipe the page and rerender. The earliest versions basically did that, and then they started diffing and applying the diff.
        creamyhorror 4y ago
        They're referring to a specific bit of code in that Eureka repo that sets innerHtml = "" and then does .appendChild(). They just apparently didn't notice that the code doesn't use React at all (and is meant to demonstrate the use of vanilla modern JS without React).
        ojkelly 4y ago
        Yep that’s what I was alluding to as well. I’m pretty sure they noticed it wasn’t using react. The comment was a reference to the fact that if you don’t use a framework, you’ll end up a building one anyway.
  - ojkelly 4y ago
    We’re coming at this from different mental models. The code you linked is what React helped me get away from. There’s multiple files in different folders for one screen. It’s hard to see how it composes, which is a useful boundary as it lets me know in the scope of that part of the UI. UI is _hard_. There’s complexity that needs to go somewhere, and I’m one of those who prefer to push as much if it that isn’t business logic into a framework. This becomes exponentially more important for every engineer you add. Go success is along these lines, with typically only one way to do things it’s much easier to share code. From the code you linked, I could find my way around, but piecing it all together took a lot more work than any of the frameworks. You mention only needing to know JS, HTML and CSS. But you missed that you still need to know how all that code is put together, what calls what. How it updates. React needs this too, the only difference with it being a framework is that knowledge transfers to a different project. And to be clear, I’m not saying you need to use react or a framework—going your own way is often how amazing new things are found. What I am saying is your attitude isn’t helping you here. React is still arguably the most used framework[0]. There’s a reason so many of us like using it and it’s what you described as “other crap”. Frameworks help with collaboration, in the same way programming languages do. To do anything interesting with a general purpose language, you’re either going to use a framework, create a new one with good documentation and build a community of engineers around it, or build a halfbaked one that few people understand. I’m open to other ways of doing things. It’s a good way to grow. I learnt SwiftUI a little while ago, and while I don’t use it regularly it improved my understanding of UI building. I learnt imperative UI API ages ago, and know for sure I want to avoid/contain that into a more manageable declarative approach. [0] https://trends.builtwith.com/javascript/javascript-library/traffic/Entire-Internet https://trends.builtwith.com/javascript/javascript-library/t...
    - petilon 4y ago
      It is idiomatic JavaScript. If you learned Java at the university you'll immediately be comfortable with the code. Now consider React with hooks. It is neither OOP nor functional and it looks alien to anyone who knows idiomatic Java or JavaScript. Would you recommend a youngster learning programming to learn React? I wouldn't, because it is so frankenstein. This article makes that point better than I can: https://medium.com/codex/can-we-all-just-admit-react-hooks-were-a-bad-idea-c48120c5188d https://medium.com/codex/can-we-all-just-admit-react-hooks-w...
javcasas 4y ago
No. The point of FP is "minimize state and effects so that the code is easier to understand", not "write it in FP style so that by magic is correct". For exactly the same reason OO is "put the code that manages the state near to the state and split it in manageable parts" and not "dog inherits from animal therefore the code is correct". Leave the faith at the church and approach code with science.

ojkelly 4y ago

But you can do that with algebraic effects. That’s kind of the point. You keep the clarity of declaring what you want to happen, and abstract the how to the effect handler.

petilon 4y ago
None of that is true in React hooks. The negative sentiment towards hooks that you see here is because it is weird and complicated. Want to see how much simpler code can get when you code without React or any such fat frameworks? Take a look: https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp https://github.com/wisercoder/eureka/tree/master/webapp/Clie... You just need to know JavaScript, HTML and CSS, not much else. The code is simple, and yet maintainable. No need for hooks, useEffect, useState, useMemo and all that crap.
- _v7gu 4y ago
  How can you ever be sure that your state is valid when you’re putting it on the DOM? Worse yet, only parts of the state is stored there. I can’t really call this code simple since it had to resort to timing hacks to get its functionality in order. A random 250ms delay and bam, bugs you cannot reliably reproduce
  - petilon 4y ago
    Can you clarify what you mean here? What state is in DOM? Do you mean the state inherent in input elements? What timing hacks are you talking about?
    - _v7gu 4y ago
      The first file I looked into was the combo box. This is what I consider to be a timing hack: private onDropDownMouseOver(ev: MouseEvent): void { if ((new Date()).getTime() < this.whenScrolled + 250) { // We automatically get a hover event when we scroll, ignore it in order to keep our current highlight. return; } const element = ev.target as HTMLElement; if (element.classList.contains('combo-dropdown-item')) { addClassExclusively(element, 'combo-highlighted'); } } Some event stores the time it has been fired, and this method checks that it has not been long since the firing. With react, which item has the highlight would have to explicitly be in the state and completely remove the need to do this optimization. And this is an example of what I consider state being stored in the DOM: private isDropDownVisible() { return isVisible(this.dropDown); } The view has logic that depends on whether the dropdown is visible, which is checked by dropdown.style.display !== none. Now any element in your page has the power to modify this component’s logic by modifying the DOM
      - petilon 4y ago
        The timing hack is a workaround for a browser bug. The exact same hack would be required in React as well. What is this browser bug I speak of? Browsers send a spurious "hover" event when you stop scrolling, so that the item under mouse can be highlighted. This can cause problems in some cases. > Now any element in your page has the power to modify this component’s logic by modifying the DOM If some part of your application intentionally does something wrong, it can break your application whether it is React or some other tech. In this particular example, if you prefer, you can have a member variable to keep track of whether the dropdown is visible or not. Still no need for React. As you can see, none of the complexity of React is necessary. No need for hooks, useEffect, useState, useMemo and all that crap.
        _v7gu 4y ago
        Would it, though? Keyboard event sets highlighted item key/id; scroll event pops up, sets the highlighted item again, then react does not do an additional render because the state has not changed since the keyboard event. The code does not have any complexities of hooks (which are just a javascript approximation of do notation, I don’t believe it is that complex), but what it does have is the requirement to write down all of your mutations correctly, where every “down” is an exact opposite of the “up” and does not leave any artifacts—with no way of formally checking. At least for myself, I think that level of discipline is unreasonably high so I tend to prefer stricter typed functional solutions where the view is composed purely from the state
  - creamyhorror 4y ago
    I'm not sure what timing hacks you're referring to - using setTimeout() with 0 delay? I think that's being done to defer execution of heavier functions and let other timeouts be handled first. Seems more like an optimisation rather than a hack to achieve basic functionality.
- javcasas 4y ago
  https://github.com/wisercoder/eureka/blob/master/webapp/ClientApp/controllers/AdminController.ts#L42 https://github.com/wisercoder/eureka/blob/master/webapp/Clie... I love how you do React. I mean, what's more react-y than blanking the page then appending HTML? I'm gonna call that Rejqueryact, because it's jQuery inside React.
  - creamyhorror 4y ago
    I'm not seeing React being used, though, just TSX/JSX? All the view and state updating is being done manually, but it looks fairly well-organised. There are small optimisations like debouncing onInput with a timeout (avoiding rapid re-rendering/reacting to every character typed): https://github.com/wisercoder/eureka/blob/master/webapp/ClientApp/views/FilterControl.tsx https://github.com/wisercoder/eureka/blob/master/webapp/Clie... Is this really much more complicated to implement than the equivalent implementation in React? (It's probably a bit more responsive, at least.)
    - ojkelly 4y ago
      I think they’re referring to how Reacts mental model is to wipe the page and rerender. The earliest versions basically did that, and then they started diffing and applying the diff.
      - creamyhorror 4y ago
        They're referring to a specific bit of code in that Eureka repo that sets innerHtml = "" and then does .appendChild(). They just apparently didn't notice that the code doesn't use React at all (and is meant to demonstrate the use of vanilla modern JS without React).
        ojkelly 4y ago
        Yep that’s what I was alluding to as well. I’m pretty sure they noticed it wasn’t using react. The comment was a reference to the fact that if you don’t use a framework, you’ll end up a building one anyway.
- ojkelly 4y ago
  We’re coming at this from different mental models. The code you linked is what React helped me get away from. There’s multiple files in different folders for one screen. It’s hard to see how it composes, which is a useful boundary as it lets me know in the scope of that part of the UI. UI is _hard_. There’s complexity that needs to go somewhere, and I’m one of those who prefer to push as much if it that isn’t business logic into a framework. This becomes exponentially more important for every engineer you add. Go success is along these lines, with typically only one way to do things it’s much easier to share code. From the code you linked, I could find my way around, but piecing it all together took a lot more work than any of the frameworks. You mention only needing to know JS, HTML and CSS. But you missed that you still need to know how all that code is put together, what calls what. How it updates. React needs this too, the only difference with it being a framework is that knowledge transfers to a different project. And to be clear, I’m not saying you need to use react or a framework—going your own way is often how amazing new things are found. What I am saying is your attitude isn’t helping you here. React is still arguably the most used framework[0]. There’s a reason so many of us like using it and it’s what you described as “other crap”. Frameworks help with collaboration, in the same way programming languages do. To do anything interesting with a general purpose language, you’re either going to use a framework, create a new one with good documentation and build a community of engineers around it, or build a halfbaked one that few people understand. I’m open to other ways of doing things. It’s a good way to grow. I learnt SwiftUI a little while ago, and while I don’t use it regularly it improved my understanding of UI building. I learnt imperative UI API ages ago, and know for sure I want to avoid/contain that into a more manageable declarative approach. [0] https://trends.builtwith.com/javascript/javascript-library/traffic/Entire-Internet https://trends.builtwith.com/javascript/javascript-library/t...
  - petilon 4y ago
    It is idiomatic JavaScript. If you learned Java at the university you'll immediately be comfortable with the code. Now consider React with hooks. It is neither OOP nor functional and it looks alien to anyone who knows idiomatic Java or JavaScript. Would you recommend a youngster learning programming to learn React? I wouldn't, because it is so frankenstein. This article makes that point better than I can: https://medium.com/codex/can-we-all-just-admit-react-hooks-were-a-bad-idea-c48120c5188d https://medium.com/codex/can-we-all-just-admit-react-hooks-w...

javcasas 4y ago

No. The point of FP is "minimize state and effects so that the code is easier to understand", not "write it in FP style so that by magic is correct". For exactly the same reason OO is "put the code that manages the state near to the state and split it in manageable parts" and not "dog inherits from animal therefore the code is correct". Leave the faith at the church and approach code with science.