4 ms·

"That the author kind of misses this point makes me pay less attention to the rest of the post." Too bad. The author addressed everything you said. You just di

by timr 11y ago

"That the author kind of misses this point makes me pay less attention to the rest of the post." Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted. Nowhere does the piece imply that you should render every state change server-side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. The argument is that most people don't need React, not that they don't need AJAX or data binding.

thatswrong0 11y ago
That doesn't address the fact that, to some of us, React simplifies creating, testing, and maintaining complex UI due to its functional nature. React is simple to me, and that's why I like using it.
- timr 11y ago
  "React is simple to me, and that's why I like using it." Horses for courses. The author is merely making the argument that you don't need react, and the GP comment didn't bother to read the argument before responding.
  - thatswrong0 11y ago
    If you're going to tell me I don't need to use a library, it has to be way more convincing than, "Look how easy data binding it with native APIs! And it's not slow!" This is a weak argument in my opinion, and does nothing to address how removing abstractions will make my life easier.
    - timr 11y ago
      That's a perfectly fair counterargument to the content of the piece, but the comment to which I replied had no such content. The post didn't miss the point that "being able to just write the code once to render a UI from some state...is an incredible simplification of your code." It argued that you can do that without using React.
      - statictype 11y ago
        It argued that you can do that without using React. I actually didn't see that argument being made - two way data bindings are not the same thing. To achieve React's simplicity you either need to a) Simply tear down the entire DOM and rebuild it - works for small UIs and I've actually used this myself before react existed b) Implement something similar to the Virtual DOM that react has for any non-trivial UI that is too slow to rebuild on every user interaction.
city41 11y ago
I didn't downvote you. But I don't want data binding. I want to input parameters and get UI as output. I want to minimize state as much as possible. I want to write unit tests where I mock as minimally as possible. These are the reasons I use React.
dang 11y ago
I think I agree with you, but your comment breaks the HN guidelines twice: the first paragraph is uncivil and the final one goes on about getting downvoted. It also pretty much breaks the injunction against "did you even read the article" comments, so that's three. Please don't do these things when commenting here, regardless of how irritatingly wrong someone else may be. The middle paragraph is helpful and fine, and the comment would have been much better with just that. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- timr 11y ago
  The first paragraph wasn't uncivil. He said that he didn't read past the first few sentences of the article: "That the author kind of misses this point makes me pay less attention to the rest of the post." If they had read the rest of the post, they would have seen that their argument was addressed. You're being unfair here. The top-rated comment is from someone mischaracterizing the piece, saying he didn't read it...and you're calling me out for pointing that out.
  - dang 11y ago
    I don't see that. Actually the only bit that seems uncivil to me is just "You just didn't read past the sentence you quoted." You can't know that, and such statements are the internet comment equivalent of elbowing.
    - timr 11y ago
      I was responding to the last line of his comment, coupled with the fact that the comment completely mischaracterized the article based on a single line, early in the piece. I admit that the last line is unnecessary. I'll remove it.
      - d0m 11y ago
        (I didn't downvote you, I really don't mind, but it did sound aggressive). Here's what you wrote: >> Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted. >> Nowhere does the piece imply that you should render every state change server-side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. The argument is that most people don't need React, not that they don't need AJAX or data binding. Here's a political rewrite (Keep in mind I'm not a native english speaker): It seems that the author addressed your points later in the article. For instance, rather than rendering every state change on the server-side, it explains how you can get data-binding and partial-update behavior with web-native APIS. The main argument of the article is that most people don't need React, not necessarily that they don't need AJAX or data binding.
Dr_tldr 11y ago
The argument that React will be heavier than your own implementation is clearly true. The argument that it'll take less time to develop, document, and test your own implementation than to take advantage of the React ecosystem is clearly untrue. As the public demands higher quality images and video, code weight matters less and less. If you're not serving up 3mb+ of high-res images and/or video and making multiple AJAX calls, your site is highly specialized and outside of the mainstream. It's not an insult or a judgement, it's an easily verifiable fact by looking at Alexa ratings. If you need to save 50-100kb that badly, use a slightly smaller image file or a slightly shorter video, don't add hundreds to thousands of hours of dev time. And if you're developing for mobile, do as much server-side rendering as you can and add a debounce for potentially costly operations, it's really not that hard.
shoemai 11y ago
It's odd that nobody that's responded to you so far has pointed out that your comment is totally irrelevant to the comment you're responding to. Nowhere does GP imply that OP implies that you should render every state change server-side. The whole point of react is to render client-side.
statictype 11y ago
So, I actually did read the rest of the post. I just didn't look at it deeply. I disagree that the author addressed everything I said. He mentioned two-way data binding using mutation observers. That's not the win you get with react. React isn't about 2-way data binding - its the opposite - unidirectional data flow - which massively simplifies the mental model of how your user interface works.

by timr 11y ago

thatswrong0 11y ago

That doesn't address the fact that, to some of us, React simplifies creating, testing, and maintaining complex UI due to its functional nature. React is simple to me, and that's why I like using it.

timr 11y ago
"React is simple to me, and that's why I like using it." Horses for courses. The author is merely making the argument that you don't need react, and the GP comment didn't bother to read the argument before responding.
- thatswrong0 11y ago
  If you're going to tell me I don't need to use a library, it has to be way more convincing than, "Look how easy data binding it with native APIs! And it's not slow!" This is a weak argument in my opinion, and does nothing to address how removing abstractions will make my life easier.
  - timr 11y ago
    That's a perfectly fair counterargument to the content of the piece, but the comment to which I replied had no such content. The post didn't miss the point that "being able to just write the code once to render a UI from some state...is an incredible simplification of your code." It argued that you can do that without using React.
    - statictype 11y ago
      It argued that you can do that without using React. I actually didn't see that argument being made - two way data bindings are not the same thing. To achieve React's simplicity you either need to a) Simply tear down the entire DOM and rebuild it - works for small UIs and I've actually used this myself before react existed b) Implement something similar to the Virtual DOM that react has for any non-trivial UI that is too slow to rebuild on every user interaction.

city41 11y ago

I didn't downvote you. But I don't want data binding. I want to input parameters and get UI as output. I want to minimize state as much as possible. I want to write unit tests where I mock as minimally as possible. These are the reasons I use React.

dang 11y ago

I think I agree with you, but your comment breaks the HN guidelines twice: the first paragraph is uncivil and the final one goes on about getting downvoted. It also pretty much breaks the injunction against "did you even read the article" comments, so that's three. Please don't do these things when commenting here, regardless of how irritatingly wrong someone else may be. The middle paragraph is helpful and fine, and the comment would have been much better with just that. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

timr 11y ago
The first paragraph wasn't uncivil. He said that he didn't read past the first few sentences of the article: "That the author kind of misses this point makes me pay less attention to the rest of the post." If they had read the rest of the post, they would have seen that their argument was addressed. You're being unfair here. The top-rated comment is from someone mischaracterizing the piece, saying he didn't read it...and you're calling me out for pointing that out.
- dang 11y ago
  I don't see that. Actually the only bit that seems uncivil to me is just "You just didn't read past the sentence you quoted." You can't know that, and such statements are the internet comment equivalent of elbowing.
  - timr 11y ago
    I was responding to the last line of his comment, coupled with the fact that the comment completely mischaracterized the article based on a single line, early in the piece. I admit that the last line is unnecessary. I'll remove it.
    - d0m 11y ago
      (I didn't downvote you, I really don't mind, but it did sound aggressive). Here's what you wrote: >> Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted. >> Nowhere does the piece imply that you should render every state change server-side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. The argument is that most people don't need React, not that they don't need AJAX or data binding. Here's a political rewrite (Keep in mind I'm not a native english speaker): It seems that the author addressed your points later in the article. For instance, rather than rendering every state change on the server-side, it explains how you can get data-binding and partial-update behavior with web-native APIS. The main argument of the article is that most people don't need React, not necessarily that they don't need AJAX or data binding.

Dr_tldr 11y ago

The argument that React will be heavier than your own implementation is clearly true. The argument that it'll take less time to develop, document, and test your own implementation than to take advantage of the React ecosystem is clearly untrue. As the public demands higher quality images and video, code weight matters less and less. If you're not serving up 3mb+ of high-res images and/or video and making multiple AJAX calls, your site is highly specialized and outside of the mainstream. It's not an insult or a judgement, it's an easily verifiable fact by looking at Alexa ratings. If you need to save 50-100kb that badly, use a slightly smaller image file or a slightly shorter video, don't add hundreds to thousands of hours of dev time. And if you're developing for mobile, do as much server-side rendering as you can and add a debounce for potentially costly operations, it's really not that hard.

shoemai 11y ago

It's odd that nobody that's responded to you so far has pointed out that your comment is totally irrelevant to the comment you're responding to. Nowhere does GP imply that OP implies that you should render every state change server-side. The whole point of react is to render client-side.

statictype 11y ago

So, I actually did read the rest of the post. I just didn't look at it deeply. I disagree that the author addressed everything I said. He mentioned two-way data binding using mutation observers. That's not the win you get with react. React isn't about 2-way data binding - its the opposite - unidirectional data flow - which massively simplifies the mental model of how your user interface works.