4 ms·

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

by brap 4y ago

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.

Kinrany 4y ago
There seems to be an unoccupied design space for a mix between JSX and shell languages. Both effectively compose concurrent processes.
- junon 4y ago
  I don't see how JSX has anything to do with processes, much less concurrency.
  - brap 4y ago
    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)
    - junon 4y ago
      Any componentized UI system can do that though, in theory. JSX isn't special in that regard.
toastal 4y ago
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.
- brap 4y ago
  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.
  - tuukkah 4y ago
    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.
    - toastal 4y ago
      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.
rglover 4y ago
How about plain HTML, CSS, and JavaScript? [1] [1] https://github.com/cheatcode/joystick#writing-a-component https://github.com/cheatcode/joystick#writing-a-component

by brap 4y ago

Kinrany 4y ago

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

junon 4y ago
I don't see how JSX has anything to do with processes, much less concurrency.
- brap 4y ago
  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)
  - junon 4y ago
    Any componentized UI system can do that though, in theory. JSX isn't special in that regard.

toastal 4y ago

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.

brap 4y ago
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.
- tuukkah 4y ago
  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.
  - toastal 4y ago
    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.

rglover 4y ago

How about plain HTML, CSS, and JavaScript? [1] [1] https://github.com/cheatcode/joystick#writing-a-component https://github.com/cheatcode/joystick#writing-a-component