This content originally appeared on DEV Community and was authored by Brad Westfall
A hopefully well received and educational response to "why react sucks" - https://dev.to/jfbrennan/really-why-react-5958
JSX templates
JSX is not a "templating language", it's actually considered to be the antithesis of one. Templating languages suffer from becoming a DSL (domain specific language) whereby the "language" must recreate things like conditional logic and iterations with some proprietary "template language syntax" that will never be able to do as many things as it's host language.
JSX was added as a way to avoid using React's own createElement API.
Not at all, React.createElement
is the underlying API for React to which JSX was created specifically to compile to. It's not like JSX was created long after React to "avoid something". Instead, the main idea is that any programmatic way of building DOM nodes is messy when it comes to nesting. For example it's horrific in jQuery or vanilla JS. So instead of nesting function calls like this to make DOM nodes:
React.createElement(
"div",
null,
React.createElement("h1", null, "Hi, welcome to JSX"),
React.createElement(
"p",
null,
"It's a function call, not a tempesting language"
)
);
? You can write this which is also nested function calls:
<div>
<h1>Hi, welcome to JSX</h1>
<p>It's a function call, not a tempesting language</p>
</div>
To use JSX is to call a function:
const message = 'I teach workshops at reacttraining.com'
<div>{message && message.substr(0, 7)}</div>
// compiles to
React.createElement(div, null, message && message.substr(0, 7))
And because it is essentially a function call we can think of props as arguments. We can avoid doing DSL nonsense and have the full power of the host language (JavaScript) by way of JS expressions.
So why only expressions? ?
Because again, it's a function call. You can't do statements in JSX because you can't do them as arguments to functions:
// Nope, not allowed
<div>{if (condition) {}}</div>
// Because it would compile to this:
React.createElement(div, null, if (condition) {})
JSX is designed to be nested function calls that look familiar to us like XML or HTML so our eyes don't burn when look at actual nested function calls but also with the easy and power of a full programming language.
This is why you also can't do this and return two JSX nodes -- because they're function calls:
function App() {
return <div></div><div></div>
}
// Compiles to
function App() {
return React.createElement('div') React.createElement('div')
}
And you can't just call two functions back to back
If you ever see {' '}
in JSX, that's because in HTML (which JSX is not) white space is treated a certain way. More than one whitespace character is reduced down to a single whitespace. Because JSX is a function call, it kinda sucks I'll admin, but you have to do {' '}
in a few scenarios to create whitespace. On a really big project I might have to do that like 4 times, not a big deal.
Because of all this specialness you can't easily port JSX. That rubs me the wrong way. Template code should be easy to port because HTML is a standard.
Again, it's not meant to be HTML
For example, in JSX you do:
<div className=""></div>
<label htmlFor="" />
A lot of people who are critics of JSX will say "why does it have to be different from HTML...?"
Did you know "The class is an HTML Attribute, while the className is a DOM Property." - MDN
Turns out there's always been a difference between HTML and JS in terms of what an HTML attribute is and the corresponding way to modify that thing in JS. The same is true for <label>
. Some who don't know might complain that in JSX we do <label htmlFor="">
instead of HTML's <label for="">
. But again this is how it's done in plain JavaScript. Checkout the MDN docs for yourself ?
For example, the perfectly valid
<label for="">
will not work because for gets parsed as JavaScript. You have to use a funny JSX attribute:<label htmlFor="">
.
I think we covered that one.
Also, you have to do a funny comment syntax because HTML comment syntax is not allowed.
It's not HTML ?? The reason for the "different" not "funny" comments is because Babel would confuse these comments for being content -- like if you were documenting how HTML comments work:
<div>
<!-- HTML comment -->
</div>
And don't forget to slash your self-closing tags, e.g.
<img />
, even though HTML5 dropped that syntax more than 10 years ago.
Actually not really true. XHTML was going to be a thing in the 2000's so browsers started to implement some of it. The W3C eventually ditched the idea and did HTML5 but not before things like trailing forward slashes were already implemented by most browsers. Today, we can still do "XHTML" style self-closing tags on <img />
<-- that's valid HTML, it's not "dropped" it's just left over baggage from an old W3C idea that the browsers kept.
By the way, JSX stands for "JavaScript and XML" -- because it's a JavaScript function call (have I said that already) with XML (not HTML) syntax. In XML you do have to close your self closing tags with a forward slash.
Another one I still don't understand and don't want to understand is: Error: The style prop expects a mapping from style properties to values, not a string.
It's easier to programmatically make inline styles if we express them as an object. And again, since this is a function call™, we can do that. This feature has also played a big role in developing things like CSS-in-JS which you can decide you don't like or you just don't like that it's an object. But it's not a "ridiculous speed bump".
[React is an] "unmanageable mess" [because of] Functional or Class-based, controlled or uncontrolled, forwardRef, mixins, HOC, Hooks, etc.
That's not the point they were making. Because React lost a primitive (mixins) for sharing re-usable business logic when they switched from their original API to classes, the community (not the React library) came up with some patterns to share code, one of those patterns was HoC which has a way of double or triple wrapping your components in other components in order to solve the problem of sharing re-usable code. This meant that when you "look at a typical React application in React DevTools" there's extra wrappers in the component viewer (not the actual DOM). The React team realized for many reasons that not having a primitive way to share code was causing React developers to do things that were a little more messy, so they created hooks to give us a primitive API for sharing code.
In no way were they trying to say that React is messy because of that list. This whole section was kind of reaching for things that aren't really there to fit into a narrative.
The fact that there are so many options and types of components confuses me.
Clearly ?
There are only two ways to make components -- functions and classes. The vast majority of the React community is embracing functions because of hooks. There are three ways to make functions though in JavaScript so maybe that was confusing? But that's not React's fault.
Those other things (controlled or uncontrolled, forwardRef, mixins, HOC, Hooks) are not components, they are "features" to which components can have and some of them are alternatives to each other so it's not like all of those are used at the same time. Some are even from different time periods (mixins the first API, Hoc's the abstraction for classes we dont' use because hooks exist now. etc). So it's not like we're sitting around going "Should I use a mixin today or an HoC or a hook".
When a tool can be used in so many ways it creates doubt in its user. That's why, as the React team admits, "even between experienced React developers [there's disagreement]"
Again, there's basically one way to make components since not many are using classes anymore. React is a "library" not a framework. It's not Angular, or Knockout, or Ember (by the way how are those doing) that does the "batteries included" monolithic approach. In React, the reason why two React developers might have a disagreement is because one might want to use Redux and one might want to use context. Let's not be dramatic and act like all the other web communities are 100% on the same page with every single thing. React just lets us choose the tooling that goes on top of React for different architectures. That's a good thing. And by the way, the "disagreements" mean that there's discussion and the best ideas rise to the top. This has not been the case for the monolithic frameworks.
I stopped reading about there because like I said in the comments, practically every paragraph had wrong or misleading information.
We all have different tools like we like. That's cool ? You don't have to like React, I don't mind that. But there were many falsy or misleading things and beginners who don't know any better read this kind of stuff.
This content originally appeared on DEV Community and was authored by Brad Westfall
Brad Westfall | Sciencx (2021-08-04T20:19:56+00:00) Why React? Because it’s pretty cool actually. Misunderstood at times, but cool ?. Retrieved from https://www.scien.cx/2021/08/04/why-react-because-its-pretty-cool-actually-misunderstood-at-times-but-cool-%f0%9f%91%8d/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.