4 ms·

It is really an odd flex. As soon as you need a transpiler, which many modern JS devs are going to want and need for the benefits they provide (Typescript bein

It is really an odd flex. As soon as you need a transpiler, which many modern JS devs are going to want and need for the benefits they provide (Typescript being huge) then using JSX seems a benefit not a problem to solve.

jfengel 3y ago
JSX does seem to fit that niche better than any other alternative I've tried. It pulls off a rather remarkable trick of avoiding the "uncanny valley" that you usually get from starting with a language and contorting it to do something different. JSX manages to feel just about right: it's plain-old-HTML when you want it to be, and plain-old-Javascript when you need an out. Still... I wouldn't mind writing in a truly standard language. You're "really" writing the DOM, and HTML and DOM are this godawful bastardization of a user-interface description language. I'd be slightly less grumpy to have a good DOM-writing library, and deal with its ugliness, rather than mix-and-match the domain-specific-language in with my actual coding language. I'd written myself a good Java version of this type of thing, and I found it kinda pleasant -- especially since it let me do HTML structure checking via the Java type checking. Typescript is -- God help me -- actually a pretty good language, and I'd be OK with actually writing my user interface structure in it, with the help of a good library. At least then I'm writing in only one language. That saves me time to go out and learn the godawful bodge of CSS to make it look pretty.
- recursive 3y ago
  Jsx never achieves plain-old-html in my view. <div /> is legal but <br> isn't.
  - nicoburns 3y ago
    <br /> is which matches xhtml (if not html5)
    - recursive 3y ago
      Html 5 has displaced XHTML for decades. And notably, XHTML is not html. <br /> is valid html5, but the trailing slash is meaningless. In JSX, it's required.
      - jraph 3y ago
        XHTML5 is a thing.
        recursive 3y ago
        This is news to me. From what I can find (which is not much), it seems like XHTML5 is a further constraint on HTML5. So legal XHTML5 is legal HTML5. https://en.wikipedia.org/wiki/HTML5#XHTML_5_(XML-serialized_HTML_5) https://en.wikipedia.org/wiki/HTML5#XHTML_5_(XML-serialized_... If that's true, that means <div /> is not valid XHTML5 because 1) trailing slashes don't close tags in html and 2) div elements require a closing tag. And if that's true, then it's still different from JSX. But this XHTML5 thing might be surpassing my comprehension.
        jraph 3y ago
        > So legal XHTML5 is legal HTML5. Almost. You would need to make sure to write polyglot markup [1]. > And if that's true, then it's still different from JSX Absolutely. [1] https://www.w3.org/TR/html-polyglot/ https://www.w3.org/TR/html-polyglot/
- ping-monkey 3y ago
  If you like JSX, good for you. But tbh it's neither necessary nor the best solution...
- Hammershaft 3y ago
  Writing the dom cleanly with code with native data structures using clojurescript's hiccup is definitely an improvement.
simonw 3y ago
Not needing to use a transpiler is genuinely the thing that excites me most about VanJS. If you're not a daily JavaScript developer, any form of transpiler / build mechanism seems almost guaranteed to break in the gaps between when you are working on a specific project. The projects I have that are transpiler/build free are SO MUCH more pleasant for me to intermittently hack on!
- earthboundkid 3y ago
  Sure, I think that's a very real consideration, but if you're not a daily JS developer, I'm not sure why you'd use a function-call syntax to build up a template either. Something like Alpine.js where you just mark up your server side HTML is a lot easier than putting a bunch of logic into JS to build up a template. Or you could use lit-html or a million other things. This is an idea that's been done a million times but never catches on because it's not better than the alternatives.
  - ping-monkey 3y ago
    FWIW, for HTML template: 1. How easy is it to support loops? 2. How easy is it to compose (defining small components that can be used in larger components)? 3. How easy is it to make the UI reactive to client-side state changes? > because it's not better than the alternatives What is the alternative you're refering?
- nicoburns 3y ago
  Have you used esbuild? It’s a transpiler without the faff.
  - simonw 3y ago
    I've used it via Vite, and it worked fine. I did write myself EXTENSIVE notes such that when I return to that project in the future I have a fighting change of figuring out how to build it again: https://til.simonwillison.net/github-actions/vite-github-pages https://til.simonwillison.net/github-actions/vite-github-pag...
briantakita 3y ago
JSX is still a dependency with different variants which can cause issues. For example, SolidJS uses JSX but a different variant of JSX, which is a bit more slimmer (innerHTML instead of dangerouslySetInnerHTML). I experimented with VanJS integrating into Astro. No plugin was needed & getting the SSR HTML is as simple as calling `.render()`. I wrote a fork of VanJS called relementjs & took this concept further, using `.toString()` instead of render. Now SSR components can be rendered inside a template string. ` <div>${my_component()}</div> `

jfengel 3y ago

JSX does seem to fit that niche better than any other alternative I've tried. It pulls off a rather remarkable trick of avoiding the "uncanny valley" that you usually get from starting with a language and contorting it to do something different. JSX manages to feel just about right: it's plain-old-HTML when you want it to be, and plain-old-Javascript when you need an out. Still... I wouldn't mind writing in a truly standard language. You're "really" writing the DOM, and HTML and DOM are this godawful bastardization of a user-interface description language. I'd be slightly less grumpy to have a good DOM-writing library, and deal with its ugliness, rather than mix-and-match the domain-specific-language in with my actual coding language. I'd written myself a good Java version of this type of thing, and I found it kinda pleasant -- especially since it let me do HTML structure checking via the Java type checking. Typescript is -- God help me -- actually a pretty good language, and I'd be OK with actually writing my user interface structure in it, with the help of a good library. At least then I'm writing in only one language. That saves me time to go out and learn the godawful bodge of CSS to make it look pretty.

recursive 3y ago
Jsx never achieves plain-old-html in my view. <div /> is legal but <br> isn't.
- nicoburns 3y ago
  <br /> is which matches xhtml (if not html5)
  - recursive 3y ago
    Html 5 has displaced XHTML for decades. And notably, XHTML is not html. <br /> is valid html5, but the trailing slash is meaningless. In JSX, it's required.
    - jraph 3y ago
      XHTML5 is a thing.
      - recursive 3y ago
        This is news to me. From what I can find (which is not much), it seems like XHTML5 is a further constraint on HTML5. So legal XHTML5 is legal HTML5. https://en.wikipedia.org/wiki/HTML5#XHTML_5_(XML-serialized_HTML_5) https://en.wikipedia.org/wiki/HTML5#XHTML_5_(XML-serialized_... If that's true, that means <div /> is not valid XHTML5 because 1) trailing slashes don't close tags in html and 2) div elements require a closing tag. And if that's true, then it's still different from JSX. But this XHTML5 thing might be surpassing my comprehension.
        jraph 3y ago
        > So legal XHTML5 is legal HTML5. Almost. You would need to make sure to write polyglot markup [1]. > And if that's true, then it's still different from JSX Absolutely. [1] https://www.w3.org/TR/html-polyglot/ https://www.w3.org/TR/html-polyglot/
ping-monkey 3y ago
If you like JSX, good for you. But tbh it's neither necessary nor the best solution...
Hammershaft 3y ago
Writing the dom cleanly with code with native data structures using clojurescript's hiccup is definitely an improvement.

simonw 3y ago

Not needing to use a transpiler is genuinely the thing that excites me most about VanJS. If you're not a daily JavaScript developer, any form of transpiler / build mechanism seems almost guaranteed to break in the gaps between when you are working on a specific project. The projects I have that are transpiler/build free are SO MUCH more pleasant for me to intermittently hack on!

earthboundkid 3y ago
Sure, I think that's a very real consideration, but if you're not a daily JS developer, I'm not sure why you'd use a function-call syntax to build up a template either. Something like Alpine.js where you just mark up your server side HTML is a lot easier than putting a bunch of logic into JS to build up a template. Or you could use lit-html or a million other things. This is an idea that's been done a million times but never catches on because it's not better than the alternatives.
- ping-monkey 3y ago
  FWIW, for HTML template: 1. How easy is it to support loops? 2. How easy is it to compose (defining small components that can be used in larger components)? 3. How easy is it to make the UI reactive to client-side state changes? > because it's not better than the alternatives What is the alternative you're refering?
nicoburns 3y ago
Have you used esbuild? It’s a transpiler without the faff.
- simonw 3y ago
  I've used it via Vite, and it worked fine. I did write myself EXTENSIVE notes such that when I return to that project in the future I have a fighting change of figuring out how to build it again: https://til.simonwillison.net/github-actions/vite-github-pages https://til.simonwillison.net/github-actions/vite-github-pag...

briantakita 3y ago

JSX is still a dependency with different variants which can cause issues. For example, SolidJS uses JSX but a different variant of JSX, which is a bit more slimmer (innerHTML instead of dangerouslySetInnerHTML). I experimented with VanJS integrating into Astro. No plugin was needed & getting the SSR HTML is as simple as calling `.render()`. I wrote a fork of VanJS called relementjs & took this concept further, using `.toString()` instead of render. Now SSR components can be rendered inside a template string. ` <div>${my_component()}</div> `