Random JSX nugget:
JSX is a descendant of a PHP extention called XHP [1] [2]
[1] https://legacy.reactjs.org/blog/2016/09/28/our-first-50000-s...
Internally at Facebook you could also just call React components from XHP. Not very relevant on what you see on Facebook now as a user, but in older internal tools built with XHP it made it very easy to just throw in React components.
When you'd annotate a React component with ReactXHP (if I remember correctly), some codegen would generate an equivalent XHP components that takes the same props, and can just be used anywhere in XHP. It worked very well when I last used it!
Slightly less related but still somewhat, they have an extension to GraphQL as well that allows you to call/require React components from within GraphQL. If you look at a random GraphQL response there's a good chance you will see things like `"__dr": "GroupsCometHighlightStoryAlbumAttachmentStyle.react"`. I never looked into the mechanics of how these worked.
> you could also just call React components from XHP
Fascinating, I didn't know there was such a close integration between XHP and React. I imagined the history like XHP being a predecessor or prior art, but now I see there was an overlap of both being used together, long enough to have special language constructs to "bind" the two worlds.
"ReactXHP" didn't turn up anything, but XHP-JS sounds like it.
> We have a rapidly growing library of React components, but sometimes we’ll want to render the same thing from a page that is mostly static. Rewriting the whole page in React is not always the right decision, but duplicating the rendering code in XHP and React can lead to long-term pain.
> XHP-JS makes it convenient to construct a thin XHP wrapper around a client-side React element, avoiding both of these problems. This can also be combined with XHPAsync to prefetch some data, at the cost of slightly weakening encapsulation.
https://engineering.fb.com/2015/07/09/open-source/announcing...
This is from ten years ago, and it's asking some of the same big questions as the posted article, JSX over the Wire. How to efficiently serve a mixture of static and dynamic content, where the same HTML templates and partials are rendered on server and client side. How to fetch, refresh data, and re-hydrate those templates.
With this historical context, I can understand better the purpose of React Server Components, what it's supposed to accomplish. Using the same language for both client/server-side rendering solves a large swath of the problem space. I haven't finished reading the article, so I'll go enjoy the rest of it.
I'm annoyed to learn that even the original PHP version had `class=` working.
In fairness, `className` makes a lot of sense given that the native DOM uses the `className` attribute rather than `class`. In that sense, it's a consistent choice, just a consistent choice with the DOM rather than with HTML.
The bigger issue is the changes to events and how they get fired, some of which make sense, others of which just break people's expectations of how Javascript should work when they move to non-React projects.
Preact fixed that years ago and you can just use class=
It's not about "fixing" it, it's about choosing what you want to be consistent with. You can either be consistent with the DOM API (e.g. `document.getElementById().className = "hello"`) or with HTML (i.e. `class=...`). Both are valid choices — I personally prefer className because this is Javascript, so consistency with the DOM makes more sense, but JSX is designed to be an HTML-like syntax so I can see both ways.
The bigger difference that React makes from other frameworks, and from the DOM, is when it comes to events, in particular with events like `onChange` actually behaving more like the `onInput` event.
To be fair, choice would be to allow both in your JSX like Preact does. Usually I wouldn't bother as I get your point with consitency. But from a practical standpoint, whenever you paste some HTML code from somewhere else, the first thing I need to do is search/replace class= to className=. Probably more relevant for tailwind/bootstrap users than MUI.
That's true, but there are various other syntax differences that mean that pasting HTML is always going to require some fixing up. For example, JSX requires all elements to have closing tags or use the /> syntax, whereas HTML has elements like input or img where's that's not correct.
That said, "class" shows up a lot more in most html than "input", so I can see the advantage of being consistent with html there.
the only reason I can think of is for the dot notation assignment (not clashing with the class keyword). No one cares about consistency with DOM API in this context. Given the syntax, they most definitely expect consistency with HTML