Hacker News Reader

Comment by jraph | Hacker News Reader

Isn't JSX essentially syntax sugar for function calls (to a specific "create element" function), and therefore bound to code/rendering mix regardless of React? I see JSX syntax as fancy JS expressions. It seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue.

The "opposite" approach being using a template language like the one in Svelte or Angular… or like PHP (or Velocity, or Jinja) (for me JSX is not a template syntax at all).

I think template languages are also prone to rendering / logic mix, I don't know what is an elegant solution to this problem apart from getting used to this reality. Maybe something like QML, using data models, instead of having a for loop to render lists for instance.

View on HN

> Isn't JSX essentially syntax sugar for function calls

Yes. Which makes any issues the gp mentioned entirely up to the implementation of that function call.

> seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue

If by "could apply", you mean anyone could write a function that has those issues, then yes I guess. My point was that if you want to avoid those, they're in no way inherent to JSX. Is that what you meant?

I mean, I guess "blurred line between rendering and code" is less about the function implementation, and more about project / file organisation choices (including conventions of a frontend view framework community), but it's still certainly not inherent.

> I think template languages are also prone to rendering / logic mix

True. I think you do need a lot of discipline if you want to keep a clear and consistent separation, and it's also not always worthwhile (there's a codebase-approachability trade-off with abstraction & locality of context).

For arguments' sake though here is a quick-and-horribly-dirty example of JSX syntax separation (not recommended but demonstrative): https://codepen.io/lucideer/pen/jOZvwVz?editors=0010

I think I don't agree: I think the possibility of mixing rendering and logic is inherent to JSX. While users of the syntax can probably (deliberately) avoid mixing rendering and logic too much, there's no implementation of JSX that can prevent its users from mixing the logic and the rendering if they want to do so: it will always be possible for a user to mix the JSX tags with arbitrary Javascript because the full JS language is available in JSX tags and JSX tags can be used in Javascript code.

In contrast with HTML, where there is no way one can mix the logic and the UI because it is syntactically impossible. You have to get the DOM element from a script and to fill it data (well, actually, you can with the script tag and on* attributes, but let's consider HTML without them, only allowing script tags in <head> for instance so our restricted version of HTML remains useful).

I think you need the rendering to be data, not code, to "forbid" this mix (and soon enough, you reinvent some kind of lisp I guess)

I guess I’m not sure what you want though. If you want to render things dynamically, that dynamism has to live somewhere. And wherever that is, it’s possible to abuse. For example, what does “fill in the data” really mean? For a non-trivial app it has to mean the ability to generate fresh markup from your data, and that process can mix concerns.

> there's no implementation of JSX that can prevent its users from mixing the logic and the rendering if they want to do so: it will always be possible for a user to mix the JSX tags with arbitrary Javascript because the full JS language is available in JSX tags and JSX tags can be used in Javascript code.

That's fair. If that's what you're looking for, then JSX is not the answer. I don't think we disagree though - I was merely pointing out separation is possible (even if not strictly enforced).

Personally, I am a fan of the component-driven model (criticised above for "blurring the lines"). As I mentioned, it's a trade-off, and I think any potential "blurriness" is far outweighed by the context and reduced abstraction wins from a code-readability & codebase approachability perspective. Heavily separated templating efforts often leads to codebases with deeply nested hierarchies for views -vs- controller logic that require having 4+ split pane editors open just to understand extremely local snippets of data flow. This is particularly egregious when e.g. trying to audit codebases for injection mitigation.

Hmm, I think a long time ago (around 2005 or 2006) JSX was briefly considered to be party of ES standard. It didn't make it, and shortly after FB introduced React.

Think it may have being easier if JSX is just included in ES as a standard. So yes and no, JSX introduced by FB via react is a just a syntax sugar, however the original JSX is a meant to be a ES standard, with each node as a tree structure.

https://www.ecma-international.org/publications-and-standard...

You're describing E4X. E4X and JSX are both XML-inspired syntaxes, but beyond that have relatively little in common in how they function.

E4X was supported by Firefox for a while, but I think support was removed.

The way I see it, syntax sugar can be part of the language proper.

For instance classes in JS are sugar syntax to define a function that defines fields in this and prototype members of this function.

Arrow functions are sugar syntax to define functions bound to a specific this.

async / await is sugar syntax for promises.

for..of is sugar syntax for iterating over an iterable.

Reply on news.ycombinator.com