Hacker News Reader

Comment by brap | Hacker News Reader

This is pretty neat. I think being lightweight, and having a very small API is important.

But honestly, at this point function-style JSX/TSX is hard to beat in terms of API. There's basically no DSL to learn (`x-for`, `x-if` and so on), you just use plain old JS with all of its existing capabilities. And it's just a JS function, in come props, out comes HTML. You technically don't even need JSX to do this, it's just syntactic sugar over plain JS function calls.

Sure, React is bloated, its full API has huge surface area (that you almost never need), and there are some icky parts (state, side effects, basically the whole hook system is ehh and doesn't fit the functional paradigm).

There's definitely room for improvement there, but I think it will probably not come from React, but some other JSX-based framework (Preact and SolidJS suffer from some of the same issues).

In any case JSX is going to be super hard to beat IMO.

View on HN

JSX gives you the appearance of HTML with a boat-load of unexpected rules/exceptions to learn further hidden behind a compile step. Because of the rules, it's harder to onboard and riddled with complexity. To top it off, being XML-like it's hard to read and write. I miss the days when the docs had a toggle to show it as simple, trinary functions. If JavaScript had better function application syntax (like spaces), it'd be easier to reason about and read/write.

Which rules/exceptions are there that are an inherent part of JSX (and not React)?

The only ones I can think of are className instead of class (unfortunately a reserved word in JS), and the addition of convenient event handler attributes (like onClick), which aren’t real attributes in HTML (where handlers are attached to elements manually via JS). Other than that, it’s just like HTML, no?

(Now that I think about it, I’m not even sure that those are parts of JSX and not the React API)

Regarding being XML-like, it’s a matter of personal preference I suppose, but I prefer it that way since it’s basically HTML with tags that you can make yourself.

className and onClick are not part of the JSX spec though.

The biggest differences between JSX and HTML5:

1. In JSX, all elements need to be explicitly closed whereas in HTML5 elements like img and br should not be closed.

2. In JSX, attribute values are quoted strings, JS expressions in curly braces, or nested JSX expressions. In HTML5, you can leave e.g. numbers unquoted.

3. In JSX, you can use the 242 character entity references from HTML4 but not the 2231 from HTML5.

A topic not mentioned in the JSX spec is how whitespace between tags is handled, but HTML5 errs on the side of including too much whitespace in the output whereas a React app sometimes includes too little.

What we so though is there exists obvious differences. This means you need to understand HTML but also intimately understand JSX and how it differs. It does not match expectations, and looking like HTML doesn't make it more approachable. The original function syntax (more often I seen referenced as hyperscript now) was a simple DSL of functions that took 3 arguments: string name of the element, object of attributes, array of children (technically varg with keys needed for arrays). These functions are understandable by anyone with a cursory understanding of JavaScript.

Don't forget about htmlFor. And to to camelCase your attributes. And style attributes need a double curly brace (never mind the obtuse error message if you only put one!). Fix all those <br> elements, they're no longer acceptable. width=100, nope. What's that funny looking <></> for? Good luck Googling it. WTF did they put {foo && bar} everywhere?

Everyone likes to complain about the DSL that Vue or Angular use, but by the time you learn all the exceptions and oddities of JSX you could have easily learned how to use Vue's templating system.

And the fact that it's common for someone to have no idea whether a feature is part of the JSX syntax, or the framework they're using, or the HTML spec itself is problematic. It's very clear where the v- directives come from.

{foo && bar} is just JavaScript.

Yes, but it's not pragmatic or intuitive to use the && operator as a stand in for an inline if statement in non-JSX-land. Doing this is something of an ugly anti-pattern, `let foo = bar > 12 && "there are dozens of us!"`. The fact that it works as an inline if for JSX is almost an accident that has now been abused into convention.

Just because it's an abused accident doesn't mean it's not just JavaScript. There's nothing JSX-specific about it.

`className` bit is React specific. Preact, Solid JS and others allow you to use `class` (and sometimes both) no issue. Some just opted to follow React's lead there

How about plain HTML, CSS, and JavaScript? [1]

[1] https://github.com/cheatcode/joystick#writing-a-component

There seems to be an unoccupied design space for a mix between JSX and shell languages. Both effectively compose concurrent processes.

I don't see how JSX has anything to do with processes, much less concurrency.

I think what he meant was that the style of JSX does lend itself well to parallelism (e.g different subtrees can execute in parallel), though to the best of my knowledge no such implementation exists (maybe something can be done with WASM or WebWorkers)

Any componentized UI system can do that though, in theory. JSX isn't special in that regard.

Reply on news.ycombinator.com