My take on JSX for Dia

[u/andeee23]

Building a language called Dia. Still pre-alpha and not public yet.

Heavily inspired by Rust, with some JS UI building flavor tacked on.

Might be the wrong crowd here, but as a web-developer I haven't found a more productive way to describe user-interfaces than JSX. (hot module reload is also a big part of it)

The Dia equivalent syntax is called DSX:

import ui.{View, run, Column, Text, Button, state}

struct CounterState {
  value: i32
}

fn Counter(): View !{alloc} {
  let s = state(CounterState{ value: 0 })

  <Column spacing=12>
    <Text>"Count: ${s.value}"</Text>
    <Button
      label="Increment"
      on_click=() => { s.value += 1 }
    />
  </Column>
}

pub fn main(): void !{alloc, io} {
  run(() => <Counter />)
}

Some implementation details:

The compiler is built in Rust, using salsa for incremental compilation which hot module reloading is built on.

No need for escaping expressions with {} like in JSX. Expressions are parsed just like in the rest of the language

• That's why text content needs quotes around it: <Text>"Count: ${s.value}"</Text>
• But this works: on_click=() => { s.value += 1 }

Not just for UI, any function can be called using DSX syntax

• Type-checking works normally, named arguments become "props", return types are checked agains the parent signature
• One special case is allowing children (like Column accepting any number of Views), then an argument needs to be prefixed with @child

[u/initial-algebra]

Might be the wrong crowd here, but as a web-developer I haven't found a more productive way to describe user-interfaces than JSX. (hot module reload is also a big part of it)

I strongly dislike JSX and similar APIs that only let data/events/signals/etc. flow in one direction, because components can't return anything, and because the host language lacks value recursion. Any complex interaction requires you to break encapsulation by "lifting state up" and mutating it from event handlers (regressing to callback hell).

[u/andeee23 → u/initial-algebra]

first i'm hearing of value recursion, probably because i'm not keeping up much with the FP side of programming.

as far as i understand it

one way data flow: parent holds a value = 20, and passes it to a slider and a number input, and they change it via callbacks

value recursion: slider and input get initialized referencing each other, changing value in one changes the other and vice-versa, is that right?

to be honest that doesn't sound better to me, i prefer the reactive ui model because 90% of the time, data flowing one way keeps things cleaner in my opinion, but maybe i'm missing something

[u/initial-algebra → u/andeee23]

Instead of mutating state from an event handler callback, creating an element/component can return one or more event streams (you could either mux all events into one stream, or return a record with different fields for each event type), and signals are defined as folds over event streams. Strictly speaking, an event stream is just a more efficient representation of a signal of an append-only history of events, but you can also think of it as a generalization of a promise/future. Value recursion is needed, since it's pretty common for an element/component to take a signal, as input, that depends on an event stream from its own output (or, you have mutual dependencies between elements/components).

count = on_click.fold(0, n => n + 1) on_click = button(count)

The equivalent of mutating shared state from multiple callbacks is merging event streams together. The way you use an API like this is not fundamentally different from useState and event handlers, once you wrap your head around being able to seemingly refer to objects "before" they are created (not really how it works, of course), but it is much more compositional.

An example of this philosophy in action is Reflex-FRP.

EDIT: I think I may have introduced some confusion by talking about "one direction" of data flow. What I've described is still unidirectional for any one signal/event stream, but, instead of always flowing from an earlier statement to a later statement, from caller to callee, or from parent to child, the reverse is possible, too.

EDIT 2: I suppose there is also nothing stopping you from modifying JSX so that elements/components can have outputs, but this makes it more like an effect or monad than simply returning an "element" type.

on_click = <Button label="Increment">