Came across this article:
https://www.pandastrike.com/posts/20150311-react-bad-idea
If any of you have read it, please share your “current” take on this write-up from March 11, 2015.
I believe that all “types” of write-ups are good for the ecosystem; if the “arguments” in the write-ups are backed by sound research into the topic…
I disagree that using web standards is better than using frameworks which use the browser merely as an implementation. I think it’s fantastic that tools like Babel, React, LESS, and more use the browser simply as a runtime, rather than trying to adhere to what browser vendors have chosen to implement. I’m so excited that the days of waiting for browser support for some new feature you want are mostly over (except for CSS, where polyfilling is much harder, and you can see how CSS development seriously suffers as a result - when will we have a unified flexbox API??)
I’d take anything PandaStrike writes about Facebook with a huge grain of salt. There’s obvious negative bias there, and it’s not even founded on any legitimacy. For example:
A good framework supports separation of concerns. Web components do not impose a way of representing views or attaching event handlers or rendering to the DOM. A bad framework couples those things together so that you can’t use one without the others. That’s what React does.
The thing is, React does separate concerns, and quite well. I can break down my app in a way that a particular component can be pulled out and dropped into a completely different app, and still work exactly as I expect it to. And everything that is concerned with that component migrates together. Merging design with code is not violating separation of concerns, because the design and code are both concerned with the same purpose. The author is using the wrong terminology.
Have a read of https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51#.y4omvfppi
especially the end bit…the advantages of React. I think some of the criticisms are from people not really understanding the advantages of pulling HTML into javascript rather than the other way around. The article says JSX is the worst part because they think it means you are going to do crazy coupling ( you don’t ) without recognizing that JSX unleashes the power of javascript on HTML rather than having to invent weird markup languages to inject javascript into HTML
A lot of the authors argument and conclusion is that good coders are going to write BAD code. They are going to have BAD designs… reality is different and people are proposing nice and clean separation of concerns ( check out Mantra for instance, or the Meteor Guide ).
Small request: could you please change the title of this topic to something more descriptive? Just so we know what this topic is about if we look through the archives in about 50 years. 