4 ms·

That solution just punts the ball down the field a bit. You still have to figure out who called setUserName to mutate the DOM.

by lowboy 11y ago

sago 11y ago
Right, and you have to figure out who changed the model in React too. You don't get magic traceability. If you want to know what caused a change, neither helps. If you want to know what changed the DOM, both allow you to do that. Only React makes it implicit (it may choose not to make any change, for example), this approach is explicit. This approach punts the ball into part of the field you can see, understand and control. React punts the ball into someone else's stadium. Framework-fetishism is being enamoured by things a framework does that you could do yourself in a couple of lines of code. Unfortunately Javascript programmers seem to be very vulnerable to it. There are good reasons to use React, but they aren't what the article wants to praise.
- stevebmark 11y ago
  You get plenty of magic traceability :) Check out redux. You get it in vanilla Flux if you use immutable data. I would also suggest using React for a toy project to learn more about it. The "pure"ity of the render function means you can trace the state of the DOM directly to a Javascript object (declarative), which was the point of the article's example. Your "down the road" code is imperative, as in someone changes the DOM independent of the state of your data.
  - sago 11y ago
    I've used React in anger, thanks. So how do I tell from React where my model was changed, in what bit of my code, that I couldn't tell just as easily in my own function? React is only declarative in as much as it provides an imperative function to convert between data structures. You can do this yourself, and should.
    - lowboy 11y ago
      You're not converting between data structures in your example, you're mutating a stateful system. Moreover, I'd rather leverage a library so that I don't have to manually do everything myself.
      - sago 11y ago
        I couldn't work out what point you're making in this response, sorry. I was referring to the claim that React is declarative. Not my code. Things aren't declarative magically. A declarative system is one where you declare a data structure, and you feed it to a separate bit of imperative code that operates on that declaration. In react's code, the 'declaration' is a set of HTML templates and the 'operation' is to create a corresponding DOM. > you're mutating a stateful system Both approaches do. React mutates state too. > Moreover, I'd rather leverage a library Good for you. For some things React is a big time saving. But for many things it is a waste of bandwidth, a waste of development time and a waste of programmer education. Just like any library that isn't required. Using libraries is not free. If you want the kinds of benefits the post highlights, you can get them much cheaper with a few lines of code. If you want to import a full library to save a few lines of code, that's your prerogative, of course. React shines when you need a templating system and you can benefit from the performance of a virtual DOM. If you want a basic virtual DOM, then you can do it very easily yourself (a few lines of code in the simplest case), but as things get more complex, it becomes a better tradeoff in favour of React. If you want a comprehensive system, React becomes a very useful tool, one I rely on myself. But it is important to understand what you need and why. If you don't need a virtual DOM, then using React seems pretty foolish, to me. Javascript is full of frameworks, and full of programmers who use them without knowing what they're for.
        lowboy 11y ago
        React encourages declarative usage. You declare some data and how it will be rendered in JSX templates, and React does its thing. As a consumer of a library I shouldn't have to care about what goes on under the hood, as long as I know the API and its proper usage. > Both approaches do. React mutates state too. Right, but I don't have to concern myself with the stateful system (the DOM). I can delegate that responsibility to React. As to your other points, I agree that people should put more thought into their selection of tools.
- lowboy 11y ago
  I've found it cleaner and easier to track changes to your model data and let the view be a declarative representation of said model. YMMV though. I'd much rather punt the ball into a stadium with some properties/parameters than run the logistics of a game myself (security, ticket sales, refereeing, etc). It's saved me gobs of time as a developer. Again YMMV.
  - sago 11y ago
    I agree on the first line. I think there are very simple cases where hardcoding HTML in Javascript might be okay, but it is dubious. We use templating (both an internal simple templating system which is literally 20 lines of code, and in some cases React, when it is warranted). But I don't think you're getting what I was trying to say. Sorry, for the confusion. On the second point, it depends on how hard you think the logistics are. Often the logistics consist of a couple of sweaters for a goal, and a ball. Knowing when you need a 100,000 person stadium, and when a back yard will do is the trick. Which gets lost in framework-hype. And when a post lauds a stadium because 'it has grass, guys!' then it sounds like they're buying into the hype rather than the reality. If the OP had said 'it has a kick-ass virtual DOM - never write DOM synchronization code again!' then that's a different matter. But it didn't. See what I'm saying? I'm definitely not being anti-React or anti-Framework.
    - lowboy 11y ago
      I agree that people should think about the proper tool for the job. And that hype can lead to poor decisions.

That solution just punts the ball down the field a bit. You still have to figure out who called setUserName to mutate the DOM.

by lowboy 11y ago

That solution just punts the ball down the field a bit. You still have to figure out who called setUserName to mutate the DOM.

sago 11y ago

Right, and you have to figure out who changed the model in React too. You don't get magic traceability. If you want to know what caused a change, neither helps. If you want to know what changed the DOM, both allow you to do that. Only React makes it implicit (it may choose not to make any change, for example), this approach is explicit. This approach punts the ball into part of the field you can see, understand and control. React punts the ball into someone else's stadium. Framework-fetishism is being enamoured by things a framework does that you could do yourself in a couple of lines of code. Unfortunately Javascript programmers seem to be very vulnerable to it. There are good reasons to use React, but they aren't what the article wants to praise.

stevebmark 11y ago
You get plenty of magic traceability :) Check out redux. You get it in vanilla Flux if you use immutable data. I would also suggest using React for a toy project to learn more about it. The "pure"ity of the render function means you can trace the state of the DOM directly to a Javascript object (declarative), which was the point of the article's example. Your "down the road" code is imperative, as in someone changes the DOM independent of the state of your data.
- sago 11y ago
  I've used React in anger, thanks. So how do I tell from React where my model was changed, in what bit of my code, that I couldn't tell just as easily in my own function? React is only declarative in as much as it provides an imperative function to convert between data structures. You can do this yourself, and should.
  - lowboy 11y ago
    You're not converting between data structures in your example, you're mutating a stateful system. Moreover, I'd rather leverage a library so that I don't have to manually do everything myself.
    - sago 11y ago
      I couldn't work out what point you're making in this response, sorry. I was referring to the claim that React is declarative. Not my code. Things aren't declarative magically. A declarative system is one where you declare a data structure, and you feed it to a separate bit of imperative code that operates on that declaration. In react's code, the 'declaration' is a set of HTML templates and the 'operation' is to create a corresponding DOM. > you're mutating a stateful system Both approaches do. React mutates state too. > Moreover, I'd rather leverage a library Good for you. For some things React is a big time saving. But for many things it is a waste of bandwidth, a waste of development time and a waste of programmer education. Just like any library that isn't required. Using libraries is not free. If you want the kinds of benefits the post highlights, you can get them much cheaper with a few lines of code. If you want to import a full library to save a few lines of code, that's your prerogative, of course. React shines when you need a templating system and you can benefit from the performance of a virtual DOM. If you want a basic virtual DOM, then you can do it very easily yourself (a few lines of code in the simplest case), but as things get more complex, it becomes a better tradeoff in favour of React. If you want a comprehensive system, React becomes a very useful tool, one I rely on myself. But it is important to understand what you need and why. If you don't need a virtual DOM, then using React seems pretty foolish, to me. Javascript is full of frameworks, and full of programmers who use them without knowing what they're for.
      - lowboy 11y ago
        React encourages declarative usage. You declare some data and how it will be rendered in JSX templates, and React does its thing. As a consumer of a library I shouldn't have to care about what goes on under the hood, as long as I know the API and its proper usage. > Both approaches do. React mutates state too. Right, but I don't have to concern myself with the stateful system (the DOM). I can delegate that responsibility to React. As to your other points, I agree that people should put more thought into their selection of tools.
lowboy 11y ago
I've found it cleaner and easier to track changes to your model data and let the view be a declarative representation of said model. YMMV though. I'd much rather punt the ball into a stadium with some properties/parameters than run the logistics of a game myself (security, ticket sales, refereeing, etc). It's saved me gobs of time as a developer. Again YMMV.
- sago 11y ago
  I agree on the first line. I think there are very simple cases where hardcoding HTML in Javascript might be okay, but it is dubious. We use templating (both an internal simple templating system which is literally 20 lines of code, and in some cases React, when it is warranted). But I don't think you're getting what I was trying to say. Sorry, for the confusion. On the second point, it depends on how hard you think the logistics are. Often the logistics consist of a couple of sweaters for a goal, and a ball. Knowing when you need a 100,000 person stadium, and when a back yard will do is the trick. Which gets lost in framework-hype. And when a post lauds a stadium because 'it has grass, guys!' then it sounds like they're buying into the hype rather than the reality. If the OP had said 'it has a kick-ass virtual DOM - never write DOM synchronization code again!' then that's a different matter. But it didn't. See what I'm saying? I'm definitely not being anti-React or anti-Framework.
  - lowboy 11y ago
    I agree that people should think about the proper tool for the job. And that hype can lead to poor decisions.