React isn't Javascript. It's a franken-language that looks superficially like a mix of JavaScript and XML whilst following the rules of neither. That's why there is such a thing as a React compiler - a good sign that you're not writing JS, which doesn't have compilers.
The other hint should be all the new rules you have to follow. React is full of magic syntax that looks like functions, but e.g. you can't call them inside an if statement, or you have to redundantly declare the 'dependencies' (variables you read) and so on. The semantics of React code are very different to imperative straight line code.
It would be best to think of it as syntax sugar for create Element() function calls. You enter JSX with angle tags and insert expressions in braces
> React is full of magic syntax that looks like functions, but e.g. you can't call them inside an if statement, or you have to redundantly declare the 'dependencies' (variables you read) and so on
That's not magic syntax. That's just functions that must be processed in regular order between render ticks.
It's not a difficult exercise to write a "plain JS" function that works that way. If you've worked much with closures you can visualise how that would play out.
The way you know it's magic is it shatters the principle of referential identity, which tells you that a variable is itself. It pretends you can use a simpler mental model but you really cannot and must not.
"React Functional Components" have nothing to do with conventional functional programming. They inherently (intentionally?) violate the spirit of functional programming through hidden global variables, while pretending that it is still functional, when in reality they should be doing the opposite. They should be upfront about the hack that hooks are. They are not functional, they are merely functions. In all other respects they operate as if the function was a method inside a class and that all hook calls are with respect to an invisible "this" keyword that contains the component's context. Since hooks are not named (which would expose their inherently pseudo-OOP nature), they associate their state through a hidden incrementing counter. It's like you're sweeping all the OOP parts under the rug to pretend to be functional so you can be a cool functional hippie too.
When you do a useValue() it is clear you are grasping at something with a larger lifespan than your function.
Conceptually it is not much different than
int counter() {
static int x = 1;
return x++;
}
Thats what makes it a new language. C is just sugar on top of assembly.
Its so strange that jsx needs a buildstep, but misses ton of obvious ergonomics that one could have added. Why className instead of class? With a buildstep, it would surely be possible to determine if class was a keyword or not based on context
I think that's a bad example. C isn't a sugar for assembly: For example what assembly code does a function prototype desugar into? Sugars have 1:1 mappings with host code
Maybe you're just being rhetorical about the spectrum of macros, sugars, and languages, though.
(In my opinion, a better target for that criticism, in JS land, is the Jest test framework, because of all the reordering magic it does that break fundamental ES semantics)
> Why className instead of class?
This hasn't been a constraint since... I want to say React 18, six or seven years ago? I might be misremembering the history but I think that was only a problem in the Early Days when there was paranoia about whether JSX needed to be conservative with reserved keywords
More like syntax cilantro. Some people love it. Some can't stand it.
You say that like it's a bad thing - but it didn't stop Babel or TypeScript from being popular, both of which need a compiler. And being honest, I don't like extra tools in my chain, which is probably why I don't use React proper, but that proves you don't need anything React specific for anything other than optimisation
The only syntax you really want for React is JSX. Which is just because writing React.createElement("div" ...) every time is unergomomic. JSX isn't specific to React. It could easily be a language feature, in fact it is an OOTB language feature of TypeScript.
> React is full of magic syntax that looks like functions, but e.g. you can't call them inside an if statement
They look like function calls, because they are. They're not "magic syntax", and in fact, those rules are explicitly because theres no way around that without implementing special syntax
And in the decade I've been writing for React, I've never used the React compiler. But saying that it's proof that it's not JavaScript it's like saying that V8 is proof that JavaScript is too complicated because otherwise it would be fast enough not to need a JIT.
And all those rules? You don't have to follow them either. Use class components. They're still there, and they work fine.
I understand how they map to each other but I've only done JSX. That said, I'm old so calling functions all over the place is in my wheelhouse, and I'd love to hear from folks who have done both.
This is actually the selling point to me. As someone who started learning pure HTML, JSX just makes a lot of sense to me intuitively. It feels like intelligent HTML
React "compiler" is in fact a transpiler, which is a very common thing in JS.
>React is full of magic syntax that looks like functions
Full of magic syntax meaning 5 straightforward hooks? Surely they are not true free-form JavaScript, but at least the syntax itself is not turned into a DSL
https://react.dev/learn/react-compiler/introduction#what-doe...
The React cinematic universe has a habit of repurposing existing terminology, but they're both transpilers, to the extent that "transpiler" is even a word.
`useEffect` is straightforward? Cloudflare recently (like, literally 4 days ago)[1] had a pretty big outage because of the improper use of `useEffect` (surprise, surprise, it was the dependency array), a hook so infamous if you search "When should I use `useEffect`" you'll get approximately 9 trillion hits, with nearly all of them telling you something different, including Dan Abramov himself having to chip in with multiple blog posts telling people to NOT use it because of how much of a dumpster fire of a API it is.
[1] https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-...
useEffect usage needs to die, yes. I don't think it's a case against React, given its age.
Otherwise, using React is straightforward. I started coding in it without reading any docs. As someone who used Dojo, prototype, ext.js, jQuery (+UI), Backbone.js, knockout (still has a special place), Mithril, the classic angular, vue (2), svelte, Marko and even Solid (I'm not totally sold on signals), React is the most straightforward by a mile.
Is it the most performant? Hell no. Is it the one with the least gotchas/warts? Nope. Concise? A giant no. Batteries included? It depends on what you're looking for...
But I can just be productive with it, and it makes sense.
Yes and all you have to do is learn why those semantics exist in order to do react well.
Unfortunately too many programmers still think they can just mimic other code to figure it out.
So from my personal experience the things you mentioned are non-issues in practice. Do you have a different experience?
As for hooks, I guess I mentally treat them as magic that lives in its own lane, and so I've never really thought that I could do anything with them, other than what the manual prescribes.
No. Plain JS requires no compilation.