I see why people might hate Lua. Especially for game dev!

https://correspondence-chess-production.up.railway.app/

making a move should automatically copy the new url to your clipboard. you can still keep the ascii charm by server side rendering the ascii chess board as an og description.

1. It's really nice that it's so easy to make a `createSignal`

2. I didn't realize that in Solid you had to update all the usage sites too, so now I'd rather stick to the Svelte usage. Nested reactivity is not as effortless as I thought in Solid.

  get done() { return done },
  set done(value) { done = value },
  get text() { return text },
  set text(value) { text = value }

This might be common enough that some syntax sugar might be worth it?

The short hand for:

  todos = [...todos, {
    get done() { return done },
    set done(value) { done = value },
    get text() { return text },
    set text(value) { text = value }
  }];

  todos = [...todos, {
    $done,
    $set
  }];

You can do it project wide or per component: https://svelte-5-preview.vercel.app/docs/runes

This is exactly what SolidJS already does, and SolidJS is #1 in almost all performance benchmarks.

See this for a real example: https://svelte-5-preview.vercel.app/docs/fine-grained-reacti...

Here is the same thing in SolidJS with more explanation: https://www.solidjs.com/tutorial/stores_nested_reactivity

Let's compare Svelte's and Solid's approach to nested reactivity. Both of them implement the same nested reactivity todo example:

Svelte: https://svelte-5-preview.vercel.app/docs/fine-grained-reacti...

Solid: https://www.solidjs.com/tutorial/stores_nested_reactivity?so...

In Solid, converting something to use nested reactivity is one step. In Svelte, it is two steps. And that second step is really verbose and annoying:

  todos = [...todos, {
    get done() { return done },
    set done(value) { done = value },
    get text() { return text },
    set text(value) { text = value }
   }];

It is nice that runes allows nested reactivity in Svelte, but it feels nicer to use in Solid.

Example: https://www.solidjs.com/examples/counter

`onMount` and `onDestroy` feel like really useful, dependable callbacks. `$effect` is scary because if you add a reference to state in it, you can't depend on it being called like `onMount`.

Crazy theory: esrap will be part of a transpiler that converts Svelte 4 code to Svelte 5 code. I'm not sure if that's actually the case or if it's even technically possible. But it would be really cool!

[1] https://github.com/Rich-Harris/esrap

Comments URL: https://news.ycombinator.com/item?id=36961331

Points: 2

# Comments: 0

Yeahh, looks like you'd have to connect to all these signals and be able to access sizing/position from C++. Not sure how possible this is, you probably know better than me.

On the web it's common to animate the size of flexbox items with CSS animations. These animations are entirely implemented by the browser, and I imagine much of it is even GPU accelerated. No JavaScript is executed for this on the browser. But with this library, you would be running the `Flex.qml`'s `updatePositions` function every frame of the animation. Isn't that wasteful when compared to how flexbox works in the browser? It seems like a browser would be much faster at computing layout for flexbox elements than this, especially when that flexbox's size is being animated with CSS animations.

[1] https://github.com/tripolskypetr/qml-flexbox/blob/master/qml...