Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VanJS – A no-JSX framework based on vanilla JavaScript

vanjs.org

Post reply on HN
Print view View original

131–140 of 178 posts

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#131

Post by dimeatree »

State management seems a bit counter intuitive at a glance.

I found this statement to be confusing; https://vanjs.org/tutorial#state-val-is-immutable While you can update State objects by setting the val property, you should never mutate the underlying object of val itself.

Then beneath is an example of the following;

   const text = van.state("VanJS")
   ...
   input({type: "text", value: text, oninput: e => text.val = e.target.value})
Which looks like a mutation - after reading a bit more around it is clearer that .val has a setter; but at a glance it just isn't obvious what is happening which I feel isn't intuitive.

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#132

Post by taoxin »

dimeatree wrote: post #131

State management seems a bit counter intuitive at a glance. I found this statement to be confusing; https://vanjs.org/tutorial#state-val-is-immutable While you can update State objects by setting the val property, you should never mutate the underlying object of val itself. Then beneath is an example of the following; const text = van.state("VanJS") ... input({type: "text", value: text, oninput: e => text.val = e.tar…

States are mutable whose value can be get/set via the ".val" property. However, the value of the states should be (ideally) an immutable object (or primitives).

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#133

Post by ping-monkey »

least wrote: post #130
flying-pig wrote: post #111

Earlier quoted context omitted.

JSX is redundant, at best. VanJS demonstrated ordinary JavaScript syntax is as good as JSX, if not better. How can something feel sugar-ish if it's actually more verbose than ordinary JS code? Plus, you can't really execute JSX code in browser's developer console.

> How can something feel sugar-ish if it's actually more verbose than ordinary JS code? I personally find XML much easier to parse than a lot of nested callbacks and I especially like that content is always inside tags, rather than another argument as part of the library's functions. p("Hello, world") is readable enough, but as soon as you start adding html attributes, it becomes less legible to me: li(a({href: " htt…

tbh, you don't need JSX to know where things begin and end (if this is something really important for you):

li(a({href: "https://vanjs.org/"}, "VanJS")/*a*/)/*li*/

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#134

Post by dimeatree »

taoxin wrote: post #132
dimeatree wrote: post #131

State management seems a bit counter intuitive at a glance. I found this statement to be confusing; https://vanjs.org/tutorial#state-val-is-immutable While you can update State objects by setting the val property, you should never mutate the underlying object of val itself. Then beneath is an example of the following; const text = van.state("VanJS") ... input({type: "text", value: text, oninput: e => text.val = e.tar…

States are mutable whose value can be get/set via the ".val" property. However, the value of the states should be (ideally) an immutable object (or primitives).

Yeah I understood that better, thanks.

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#135

Post by nicoburns »

simonw wrote: post #106
mikeryan wrote: post #99

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!

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

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#136

Post by nicoburns »

recursive wrote: post #127
jfengel wrote: post #102

Earlier quoted context omitted.

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…

Jsx never achieves plain-old-html in my view. is legal but isn't.

is which matches xhtml (if not html5)

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#137

Post by ping-monkey »

earthboundkid wrote: post #124
simonw wrote: post #106

Earlier quoted context omitted.

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 b…

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?

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#138

Post by ping-monkey »

jfengel wrote: post #102
mikeryan wrote: post #99

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…

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

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#139

Post by ping-monkey »

briantakita wrote: post #119
brap wrote: post #87

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.

There is some plug-in that adds JSX support though.

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#140

Post by simonw »

nicoburns wrote: post #135
simonw wrote: post #106

Earlier quoted context omitted.

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!

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

Post reply on HN