Hacker News Reader

Comment by mikeryan | Hacker News Reader

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.

View on HN

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!

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.

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?

Have you used esbuild? It’s a transpiler without the faff.

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

You can trim down those notes a lot, like instead of `npm install`, I write a shell script called `script/prepare-env`, instead of various scripts written in a package.json file, I've standardized on `script/start`, `script/build`, and `script/deploy`. Now, no matter the language or package manager used, my workflow is the same.

And you could clean up the GitHub Actions file by just passing the base url to your build script, IE `BASE_URL="/${{ github.event.repository.name }}/" script/build`.

I mean no offense, these notes aren't that extensive, and most of the content is for setting up GitHub Actions / GitHub Pages. npm install / npm run dev / npm run build aren't very esoteric, and can all be documented inside the repo.

I'm actually a little shocked to find out you're a co-creator of Django.

The title of that page is "Serving a JavaScript project built using Vite from GitHub Pages" - that's what those notes are meant to cover, the Vite part is a subset of what I learned in that particular TIL.

Thanks for the BASE_URL environment variable trick - that was very non-obvious to me! I found the documentation for that just now: https://vitejs.dev/guide/env-and-mode

I'm not sure what you mean by "trim down" those notes - if anything I'm always looking for ways to bulk this kind of document up, in order to capture as many of the details of how things work as possible.

I tried the script/x pattern for a bit but I've found that Justfiles fit my brain better - I have a TIL about those here: https://til.simonwillison.net/django/just-with-django

I use TypeScript exclusively over Javascript so being pure JS is a con not a pro to me.

The library does have Typescript definitions available to use.

https://github.com/vanjs-org/van#typescript-support

…you can use React without a transpiler. Without JSX React’s syntax is pretty much identical to this.

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.

Jsx never achieves plain-old-html in my view. <div /> is legal but <br> isn't.

<br /> is which matches xhtml (if not html5)

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.

XHTML5 is a thing.

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

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.

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

If you like JSX, good for you. But tbh it's neither necessary nor the best solution...

Writing the dom cleanly with code with native data structures using clojurescript's hiccup is definitely an improvement.

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

Reply on news.ycombinator.com