71–80 of 177 posts
It is amazing how much react resembles php and classic asp from 15 years ago. I guess that's what happens when you don't hire anyone over 30.
And I've been around before PHP was a thing.
Earlier quoted context omitted.
While old school PHP might look like this it is not the same thing by far. The code in this screenshot is a stateful component and is supposed to encapsulate all the logic on how it should be displayed in one place. It is close to a view in a MVC framework than true old-school spagetti code. But unlike a view component in an MVC framework the stateful components can update themselves automatically when data changes m…
Curious on your take; for a component, why do I need the virtual dom diffing? If I'm working on a component level, it's already granular enough where I can easily understand the changes that need to be made and I can just update those DOM elements myself (e.g. Oh, I should add this class here and update my shopping cart total). The DOM diffing for small components seems so... heavy handed. "Don't worry React, I got t…
If you don't do DOM diffing for small components then you have to keep control of the whole logic state AND view state of your app.
Complete diffing allows for automatic one way bindings and easier to reason UIs.
It's like functional programming.
It is amazing how much react resembles php and classic asp from 15 years ago. I guess that's what happens when you don't hire anyone over 30.
So I think I can say with some confidence that everything you have written is completely nonsense.
> It is amazing how much react resembles php and classic asp from 15 years ago.
Yes, it's amazing how it's nothing at all alike.
Earlier quoted context omitted.
While old school PHP might look like this it is not the same thing by far. The code in this screenshot is a stateful component and is supposed to encapsulate all the logic on how it should be displayed in one place. It is close to a view in a MVC framework than true old-school spagetti code. But unlike a view component in an MVC framework the stateful components can update themselves automatically when data changes m…
Curious on your take; for a component, why do I need the virtual dom diffing? If I'm working on a component level, it's already granular enough where I can easily understand the changes that need to be made and I can just update those DOM elements myself (e.g. Oh, I should add this class here and update my shopping cart total). The DOM diffing for small components seems so... heavy handed. "Don't worry React, I got t…
Earlier quoted context omitted.
The critique is in the title. There are good reasons presentation and logic are separated.
And how often are the presentation and logic changed in isolation of each other... they aren't separate concerns at many levels. The concern is sepearated in React at a component level... how a component is rendered is just as important as how it raises/accepts changes outside of itself, and often interacts. Also, having JSX in my JS is much easier to deal with than remembering some abstract DSL for how to iterate th…
He knows that what he's said has been said a thousand times before, and he knows that every time it's said a bunch of people will reply with "separation of concerns, not seperation of technology", and he knows that's a very valid counterargument which can't be refuted in a tweet, which means he also knows how pointless this is. Which in turn means that he's not doing this to start a discussion, but just to get a rise out of people. Giving him the benefit of the doubt, he might actually have an interesting point to add to the debate...but we'll never know, since he thinks a better use of his time is trolling React developers than actually making his case for...whatever it might be.
One of the tweets in reply to him hit the nail on the head: https://twitter.com/chrisbarless/status/810918115601158145
Sad.
Edit: Scroll through Fuchs' twitter feed right now; he's basically just non-stop trolling. "This is why we can’t have nice things" "Q: What is React? A: It’s PHP, but on the client." "I can see how react is awesome if you build todo apps that do nothing. :)" Then when noting how a million people are disagreeing with him: "I think that means that I’m on to something." No attempt at dialogue, no acknowledgement that there might be alternative viewpoints. Almost every tweet is another dollop of smug arrogance.
It must be nice to have so much confidence that you never have to stop and wonder if there might be something new you don't yet know.
This is a complaint I've heard often about React, and usually it's by someone that's never actually tried it (myself included before I first used it). But it's a visceral response. Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong . Separation of concerns refers to responsibilities, not languages. If you're building a static website, sure, you probably don't need R…
- Model is props/state.
- View is render().
- Controller is everything else (lifecycle, handlers, etc.)
IMHO it's also best-practice to separate view from presentation using CSS modules for component-level styles, and sprinkling namespaced classes here and there so that the component can be styled externally using application-level CSS.
We didn't get the separation of concerns wrong. React is the same we've been doing for 15 years, but we finally understood we had to modularize and encapsulate it to encourage reusability and true separation of concerns.
I'm never going back to traditional code that violates the single-responsibility principle. I'm never going back to manual DOM mutation. Give me modular, namespaced, declarative HTML+CSS+JS and I'll stop using React.
Now with web applications it's not necessary makes sense to separate some concerns. Functionality, design, markup — it's all glued together, like it or not. Remove CSS and there won't be anything but bunch of pointless divs. Remove JavaScript and it'll be just a garbage.
The images of the 2000 line long JS and CSS monoliths didn't fit into a tweet. :-) Seperation should be by the responsibilities a component, not by language. So the trend to components in frontend dev is right despite some unfamiliar mangling of html and js.