Hacker News Reader

Comment by zero_shift | Hacker News Reader

> So JSX is pure Javascript and not, say, a dialect of XML embedded in JS?

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.

View on HN

Hooks are magic syntax without any doubt. All magic syntax is made up of non-magic parts, that's kinda the point.

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.

Hooks aren't magic syntax. The problem with hooks has nothing to do with syntax. The problem is that the React crowd has decided to overload the meaning of a term that has had a reasonably solid interpretation (at least in comparison to the React crowd).

"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.

Yes, that's exactly it. React is presented as functional but it's still just stateful components, except instead of OOP syntax and features making that clear, it's hidden away so that it looks functional without actually being so.

This happens because GUIs are inherently imperative constructs.

Yeah, well put tech wise (the ad personam part puts me off a bit, though). Personally I like hooks quite a lot, but e.g. I feel I have to check once a month or two if a memoized component (that’s „functional” in name) re-renders if its props stay the same and the only change is the state..

Aren't hooks just composable effects implemented in userland? In fact, Sebastian actually asked the ECMAScript committee for effects a la OCaml 5.0 effects (https://ocaml.org/manual/5.0/effects.html) and React only built their own when the committee said "not right now", if I remember correctly.

The thing is ... you can model effects with the Free monad (or with Haskell's Backpack as was on here just the other day - https://news.ycombinator.com/item?id=45221112), so they are definitely "functional", for most variations on the definition of "functional" that I know.

What makes it even worse is that in order to match the hidden state with the output of a render function, it has to be "reconciled" which uses usually-right heuristics to match the tree structure of the function output to the tree structure in the fiber cache.

> They are not functional, they are merely functions.

Functional literally means dealing with functions composition.

Free of side effect is not a property of functional programming. Ocaml is functional and has side effects.

Please, just give me objects back. They were so much easier to reason about. I liked writing `this.stateVar`!

> The way you know it's magic is it shatters the principle of referential identity, which tells you that a variable is itself

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++;
    }

Which predates C89, if age is an argument

You can write const [a, b] = useState('x') in vanilla js and typescript. Hence it is not magic syntax.

Yeah, that's vanilla syntax. The semantics are fairly magic though. The component function that calls useState though isn't a normal function, it's a function that must be called in a special way by the React runtime in order to line up all of the hidden state that React maintains so that it can magically infer the data that your `useState` call maps to and then there's more magic to maintain the lifetime of that data.

Some of you are really going out of your way to make this more complicated than it is.

Next you're going to complain about the fact that the compiler handles static variables with controlled allocations for you in C.

Like there's no rational basis for your complaints or critique other than grandstanding.

Yes, but it is not syntax. It's a contract with the library. React is completely usable using vanilla JS syntax. Same cannot be said for Vue and Angular. It feels a bit like talking about apples and oranges in this thread.

Your example usage only implies what I would consider the non-magic implementation behavior. I could fulfill that contract with `(initial) => { let s = initial; return [ s, v => s = v]; }`. No hidden magic there, and no chance of breaking referential identity.

> It would be best to think of it as syntax sugar for create Element() function calls

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

> Thats what makes it a new language. C is just sugar on top of assembly.

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

Syntax sugar is language syntax that improves a common pattern from the language (making it sweater). jsx, async/await - things that just abstract common patterns.

> It would be best to think of it as syntax sugar for create Element() function calls

More like syntax cilantro. Some people love it. Some can't stand it.

Reply on news.ycombinator.com