151–160 of 178 posts
I don’t know why they’re selling lack of JSX as a feature. React works without JSX too. It’s just (very convenient) syntactic sugar.
There are some oddities with react but wow jsx makes my code clean and easy
Earlier quoted context omitted.
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...
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.
Earlier quoted context omitted.
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…
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
The library looks nice dx wise but complete lack of any lifecycle hooks is a bummer. I get that minimalism is the core theme but to use any js ui lib that is not explicitly built around the same reactivity model you need to hook into component lifecycle.
Life-cycle hooks typically run as side-effects from state changes, so that would be your route to do something similar.
Earlier quoted context omitted.
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.
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!
I don’t know why they’re selling lack of JSX as a feature. React works without JSX too. It’s just (very convenient) syntactic sugar.
Build simplicity. It's nice to work with functions all the way down. VanJS could add JSX on top of it though.
Earlier quoted context omitted.
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.
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 s…
Earlier quoted context omitted.
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 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…
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.
The stargazer example leaves me with questions like- are components both async and non-async? What if the component re-renders due to other state changes, is my network request fired more than once? Do I have a "component coloring" problem where once one subcomponent is async, the entire parent hierarchy has to be?
Im sure there's answers to these questions if I read the docs, but as a curious passer-byer an example mirroring this common ui pattern would answer a lot of questions for me!