My Reaction to React

More specifically, he's manually adding and keeping track of all DOM elements. Once elements need to be updated, he would need to go back in the DOM and manually add/remove/change elements.. welcome back to the jquery messy world. Whereas with React, the render function doesn't change because it gets smartly rerendered.

Also, as far as I'm concerned, jsx is a big part of what I like about React. Basically, being able to add html from javascript instead of using all kind of hacks.

I once read an article [1] that argued Lisp did not reach the same level of industrial popularity as other programming languages due to the fact that Lisp enables you to program in a lot of different ways for different reasons. I'm admittedly not very familiar with Lisp, and I don't know if I fully agree with the article, but it made me wonder if ease-of-collaboration can be considered a useful perk for languages/frameworks.

[1] http://locklessinc.com/articles/why_lisp_failed/

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.

Ruby and Python have Rails and Django which goes a LOOOOONG way in fixing this problem. Not many languages have that one, dominant framework and usually that's because people keep inventing new ones to deal with shortcomings of current ones OR that the frameworks do so little on top of what the language already offers that it's easy to create your own. Javascript and PHP are clear cut cases for the latter since both languages are out of the box built for the web. jQuery was the last real unification in the Javascript world.

I don't entirely care which framework becomes dominant as much as I just want A framework to become dominant. React looks like it is gaining that momentum, but you immediately see the problem play out when there's a thread about how great React is followed by 100 "X is better because it doesn't handle Y the way that React does" followed by another post about how "X is worse because of the way it handles Y". There's something about the Javascript world that seems ready to create new frameworks instead of contributing to existing ones.

I took a sales class years ago and the biggest takeaway from it was "People buy pain relief". jQuery was dominant because it solved a huge pain point, cross browser compatibility, in a way that made natural sense for people working in the browser by using CSS references...AND it was built to run side by side with any other JS library (Prototype, Mootools, etc) so you could safely invest in learning it and know you'd be able to use it on any project that came along. During a time when IE6 compatibility was a big deal this was huge. During a time when a lot of people were trying to solve the problem and you'd inevitably end up on a project that chose one of the other dozen options, side by side compatibility was huge.

These were major points of pain relief that jQuery brought to the table and that's how it won.

mod_python didnt come around until 2000. by then php4 was already out