6 ms·

So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? Because it sure looks like the former even though it compiles to the latter. React isn

So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? Because it sure looks like the former even though it compiles to the latter. 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.

zero_shift 1y ago
> 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.
- burnerzzzzz 1y ago
  > 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
  - zero_shift 1y ago
    > 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
  - rafaelmn 1y ago
    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.
- conartist6 1y ago
  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.
  - imtringued 1y ago
    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.
    - mike_hearn 1y ago
      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.
    - TomaszZielinski 1y ago
      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..
- TrnsltLife 1y ago
  > 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.
tayiorrobinson 1y ago
> 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. 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
gloosx 1y ago
JSX is just a syntax extension to JS, and it's not even required to create a React app. 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
- sensanaty 1y ago
  > 5 straightforward hooks `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-12-dashboard-and-api-outage/ https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-...
  - gloosx 1y ago
    Well, that is really embarrassing for Cloudflare... A recursion in a side-effect via dependencies is a rookie mistake, it's hard to imagine it could slip into production with a proper due process. Maybe they should stop vibe-coding and deploying things to production without any tests or review?
    - sensanaty 1y ago
      If after nearly a decade swarms of people are still making the exact same mistakes with how they use a specific method exposed by the library, then the problem isn't with the hundreds/thousands of people making the mistake, the design of the method is broken. This type of issue simply does not exist in Vue or Svelte even if people abuse watchers (which I've anecdotally noticed tends to happen from React devs writing Vue code). Also I just want to point out again that Dan Abramov had to write an insanely long guide to using useEffect [1]. This piece is around 10k words explaining in-depth how useEffect works. That is insane for one of the fundamental, core methods exposed by a library. [1] https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/
lerp-io 1y ago
um....react is literally js and its not a language, you can write react with or without jsx which is just syntax sugar to make it look more like html.
- burnerzzzzz 1y ago
  “syntax sugar” means its a new language. It has a new syntax.
  - rkomorn 1y ago
    This is the first time I've seen someone argue that adding syntactic sugar means creating a new language.
    - bryanrasmussen 1y ago
      it really depends on how much syntactic sugar you add. You could go back 13 years, show somebody some JSX and ask them what language they think it is and nobody would be well that's obviously JavaScript with a bit of sugar on top.
      - rkomorn 1y ago
        Sure, if I'd been replying to a comment that had anything resembling nuance, that would be applicable. It did not.
  - theshrike79 1y ago
    So Python with type definitions (syntax sugar) is a new language?
    - TrnsltLife 1y ago
      They should call it Typhon
bastawhiz 1y ago
JSX isn't and hasn't even been necessary to use React. The first version of my company's site didn't have a build step and called createElement manually. 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.
- michaelcampbell 1y ago
  If you also have experience using JSX in a React app, I'd love to hear any opinions/experiences you have with doing the JSX style vs createElement() style coding. 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.
  - b_e_n_t_o_n 1y ago
    I'm a fan of this lib [0] (with some personal modifications). It's prefer it over JSX, but I use JSX because it's usually simpler. 0: https://github.com/sultan99/react-on-lambda https://github.com/sultan99/react-on-lambda
  - bastawhiz 1y ago
    It's verbose, but it's not all that bad for small applications. Especially when you don't want a build step or tooling. In today's day and age, you can have your favorite LLM do the verbose parts for you if you really want.
TomaszZielinski 1y ago
I can’t recall a single time where I would want to put JSX in an „if” statement.. In fact I can’t recall a single time where I would want to use JSX in a different context than the return value of a render phase. So from my personal experience the things you mentioned are non-issues in practice. Do you have a different experience?
- jitl 1y ago
  yes
- mike_hearn 1y ago
  I was actually meaning the hooks and memoization stuff not JSX. I think JSX can be put inside conditional logic and loops.
  - TomaszZielinski 1y ago
    Ah OK, I see it now—I focused too much on the „magic syntax”. 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.
threatofrain 1y ago
Everything has compilers now and we definitely want to go that direction. The no build people aren’t close to building any popular consensus, like not close at all. Even plain JS is compile heavy because browsers are just compile targets.
- recursive 1y ago
  > Even plain JS is compile heavy because browsers are just compile targets. No. Plain JS requires no compilation.
unconed 1y ago
>The semantics of React code are very different to imperative straight line code. 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.
looneysquash 1y ago
JSX is how someone who knows only HTML and no programming languages would go about writing some Javascript. Which is a good thing IMO.
eawgewag 1y ago
> So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? 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

zero_shift 1y ago

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

burnerzzzzz 1y ago
> 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
- zero_shift 1y ago
  > 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
- rafaelmn 1y ago
  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.
conartist6 1y ago
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.
- imtringued 1y ago
  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.
  - mike_hearn 1y ago
    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.
  - TomaszZielinski 1y ago
    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..
TrnsltLife 1y ago
> 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.

tayiorrobinson 1y ago

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

gloosx 1y ago

JSX is just a syntax extension to JS, and it's not even required to create a React app. 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

sensanaty 1y ago
> 5 straightforward hooks `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-12-dashboard-and-api-outage/ https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-...
- gloosx 1y ago
  Well, that is really embarrassing for Cloudflare... A recursion in a side-effect via dependencies is a rookie mistake, it's hard to imagine it could slip into production with a proper due process. Maybe they should stop vibe-coding and deploying things to production without any tests or review?
  - sensanaty 1y ago
    If after nearly a decade swarms of people are still making the exact same mistakes with how they use a specific method exposed by the library, then the problem isn't with the hundreds/thousands of people making the mistake, the design of the method is broken. This type of issue simply does not exist in Vue or Svelte even if people abuse watchers (which I've anecdotally noticed tends to happen from React devs writing Vue code). Also I just want to point out again that Dan Abramov had to write an insanely long guide to using useEffect [1]. This piece is around 10k words explaining in-depth how useEffect works. That is insane for one of the fundamental, core methods exposed by a library. [1] https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/

lerp-io 1y ago

um....react is literally js and its not a language, you can write react with or without jsx which is just syntax sugar to make it look more like html.

burnerzzzzz 1y ago
“syntax sugar” means its a new language. It has a new syntax.
- rkomorn 1y ago
  This is the first time I've seen someone argue that adding syntactic sugar means creating a new language.
  - bryanrasmussen 1y ago
    it really depends on how much syntactic sugar you add. You could go back 13 years, show somebody some JSX and ask them what language they think it is and nobody would be well that's obviously JavaScript with a bit of sugar on top.
    - rkomorn 1y ago
      Sure, if I'd been replying to a comment that had anything resembling nuance, that would be applicable. It did not.
- theshrike79 1y ago
  So Python with type definitions (syntax sugar) is a new language?
  - TrnsltLife 1y ago
    They should call it Typhon

bastawhiz 1y ago

JSX isn't and hasn't even been necessary to use React. The first version of my company's site didn't have a build step and called createElement manually. 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.

michaelcampbell 1y ago
If you also have experience using JSX in a React app, I'd love to hear any opinions/experiences you have with doing the JSX style vs createElement() style coding. 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.
- b_e_n_t_o_n 1y ago
  I'm a fan of this lib [0] (with some personal modifications). It's prefer it over JSX, but I use JSX because it's usually simpler. 0: https://github.com/sultan99/react-on-lambda https://github.com/sultan99/react-on-lambda
- bastawhiz 1y ago
  It's verbose, but it's not all that bad for small applications. Especially when you don't want a build step or tooling. In today's day and age, you can have your favorite LLM do the verbose parts for you if you really want.

TomaszZielinski 1y ago

I can’t recall a single time where I would want to put JSX in an „if” statement.. In fact I can’t recall a single time where I would want to use JSX in a different context than the return value of a render phase. So from my personal experience the things you mentioned are non-issues in practice. Do you have a different experience?

jitl 1y ago
yes
mike_hearn 1y ago
I was actually meaning the hooks and memoization stuff not JSX. I think JSX can be put inside conditional logic and loops.
- TomaszZielinski 1y ago
  Ah OK, I see it now—I focused too much on the „magic syntax”. 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.

threatofrain 1y ago

Everything has compilers now and we definitely want to go that direction. The no build people aren’t close to building any popular consensus, like not close at all. Even plain JS is compile heavy because browsers are just compile targets.

recursive 1y ago
> Even plain JS is compile heavy because browsers are just compile targets. No. Plain JS requires no compilation.

unconed 1y ago

>The semantics of React code are very different to imperative straight line code. 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.

looneysquash 1y ago

JSX is how someone who knows only HTML and no programming languages would go about writing some Javascript. Which is a good thing IMO.

eawgewag 1y ago

> So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? 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