I'm not really fighting you on the merits of frameworks (which should be obvious to everyone), but are you implying that implementing a design pattern is equivalent to building a framework?
Not at all but what is the end goal of this if we consider that the code base will increase in size? You'd likely start adding more and more things to it to make it easier to work with and eventually you've unintentionally rolled your own framework.
React could also still be implemented as part of the author's view because they haven't covered any of the problems with large cascading data updates. So there's literally no argument against React in this post. It's basically just a post about how to implement a design pattern in a language, React doesn't even need to be mentioned. I might even call it click bait.
He's not trying to make an argument against React. I take him at his word here, mostly because it was indeed helpful for me:
"If you want to use React, fine, I am not trying to convince anyone not to. I just want to show that components in a JavaScript application are quite simple to do and do not require any framework at all to do so."
There are a lot of less experienced web developers being steered towards react that can gain a lot by understanding what is being laid out here, whereas I think more advanced developers like yourself have so much assumed knowledge that its hard for you to see past what from your perspective are glaring differences/inadequacies in the approach he's taking in the article.
>He's not trying to make an argument against React.
I disagree. He actually is making an argument against React but disguising it with a passive-aggressive writing style. That said, it doesn't mean his article is not helpful because like you said, it did help you.
I interpreted the following paragraph as passive-aggressive:
"If you want to use React, fine, I am not trying to convince anyone not to. I just want to show that components in a JavaScript application are quite simple to do and do not require any framework at all to do so."
It follows the very familiar template of X-is-overkill-so-let-me-enlighten-you-young-grasshopper. Another example would be, "Hey, if you want to use a bazooka to kill a house fly, don't let me stop you but I just want to point out you can take a plain old rolled up newspaper and just swat at with a quick motion of the arm."
That type of rhetorical construct has been common sport in technical discussions for decades.[1]
Why interpret his paragraph like that? Look at his previous 2 paragraphs about seeing another "react, angular, ember", etc and how it's just tiring. (In other words, he's telegraphing to readers that he's intelligent enough not to have to learn them or need them.)
Yes, he does show the underlying skeleton of a "view" by showing some homegrown Javascript code but notice how he leaves out the concept of "DOM diffing algorithm". The virtual DOM is one of the features that makes React perform better with many components and changes.
Now if the author starts implementing more and more things that React does to achieve feature parity, he will end up inventing his own Pseudoconcurrentthought-framework. At that point, someone else will come along and write "the Pseudoconcurrentthought framework is not necessary. You can do it with plain old Javascript" At the point, the cycle of critique will have repeated itself.
[1]E.g. "Angular is overkill when you can just use JQuery"; "JQuery is overkill when you can just use plain Javascript getelementbyid()"; "Using Javascript on the web page form is overkill to compute sales tax since you can just issue a POST and have the server send back another HTML page with the new sales tax amount", and so on and so on.
I don't really think we disagree on that much here. I think the only place we veer off is that I feel as though he's just trying to talk to his audience, vs being passive-aggressive.
The intended reader, as I interpreted it, would be the someone that reads Javascript Fatigue articles and goes "hell yeah". For this person the abundance of frameworks probably does feel tiresome. The person for whom this kind of advice would be patronizing doesn't seem to be who this article was meant for (although now I see what you mean by the title being click-bait)
Problem is that people use big frameworks even for cases where code base will not grow significantly in complexity (or even size). I believe that was the author's idea, not that React is bad in specific use cases that it handles, just that you need to make sure that you really will have the problem, before trying to solve it. For a lot of folks out there using react or angular is a form of premature optimization, and we all know what Donald Knuth used to say about it...
Yes. It frames how you work, with state, components etc. Besides, nearly everybody who uses React also uses Router and Flux, which make for a fuller framework.
