"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.
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.
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.
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.
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.
(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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.