Hacker News Reader

Comment by simonw | Hacker News Reader

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!

View on HN

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?

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.

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

Reply on news.ycombinator.com