It looks a little like a logic programming approach to web UI. Not sure how much that's coincidental...

Awesome! I'll pass this on to David and the rest of the team. It's been really great to hear David's thoughts on signals, and how signia came to be, and the unique approach that it takes! I still think that the signia docs gives one of the best explanations of what signals are.

tldraw has to deal with a huge amount of state changes at high speed, which is why we needed signia (alongside React). We tried other libraries, but they all started to break down with tldraw's unusual use-case. (eg: memory leaks, eg: triggering too many recalculations, eg: too slow)

Solidjs is fairly popular and is built entirely around signals. solidjs.com

Lu Wilson yeah David's work is great, I toyed with making my own signals first but couldn't crack the dependency problem. When I read capture.ts my jaw hit the floor! Such an elegant way to do it. I was afraid I'd find Proxy usage but not at all!

I visited Steve in the office when we were in London last year and he was talking about what I now know is signia, seemed really excited about it, but I couldn't grasp the concept at the time. Glad I got to revisit and appreciate it, it's fun to use.

Chris Granger I checked out Solid a while back but bounced off for some reason, I can't remember why. I'll read their docs again. Part of what I'm curious about is why the need for a compile step, why JSX syntax, etc. I'm curious to see if the needs which drove those features emerge in my own little experiment.

From a scan of their tutorials it was probably the magic that bothered me about Solid, like how computed signals are plain functions. Perhaps in practice it feels natural, but I have a strong preference for more native-feeling code.

Where I see this going is establishing a highly extendable editor system.

I want it to be attainable for an average library author to ship with a linter, and editor plugins.

To start I need a dead simple editor system. So with embedding AST information in the html, it gives web developers a clear path how to inspect the AST & come up with custom rules, or swap out parts of the ast with something more visually interesting (imagine putting in a colour picker in usages of a color function).

I haven't realized its full potential yet, there might need to be more metadata in the DOM, but I'm starting small & seeing how far I can get.

I'd wondered about such things myself. You are lot further along than I am, though! The "ground truth" representation is still the AST, right? Do you have to do a lot of work to keep the DOM and AST in sync with each other? Are you using something like ProseMirror or…hmm…looks like your are writing your own! Cool!

The code to do the mapping from html to ast, and vice versa is here github.com/coil-language/coil-lang/blob/main/editor/src/ast.coil

The file is 67 lines of coil so its totally manageable, and I suspect it shouldn't have to grow much larger.

In terms of keeping them in sync, the data is stored in the dom, so when you edit a node, it will parse it as coil code & turn it back into dom. So I guess ground truth is html. We only turn it back into coil AST when we evaluate it.

Keeping the state in the dom lets us use query selectors for all sorts of things. Here's an example of checking for using undefined variables:

And here's the linter in coil

fn lint-unused-variables {

  let ids = document.querySelectorAll("

      [data-kind=let] >

      [data-attr=assign_expr]

      [data-text]")

    ::map(:textContent)

    ::into(Set[])



  document.querySelectorAll("[data-kind=id_lookup] [data-text]")

    ::reject(:textContent ids)

    ::each($.setAttribute["data-warn", "Use of undefined variable"])

}

I think very cool, but I must admit I can't work out how to try it out. Would you be able to do a video where you explain the keypresses you do to make edits

Admittedly it might be too early for #share-your-work but here's an attempt to show.

One thing is, its rough on mobile, you can eval it but editing is hard.

There's also a handful of crucial features missing notably

• ability to tack on an operator after a node -> going from a.b to a.b.c
• delete the upcoming node - going from a[0] to a::first() is hard/impossible right now

Also there's some awkwardness of dealing with the editor as ast nodes, you can only edit within a leaf node, to move on to the next part you must tab into.

Here's a video, hope it helps.

I believe those problems are solvable, but right now I'm just showcasing the simplicity of the model, and the benefits of storing AST as html.

When you insert a new line, its temporarily a plain text editor for that line until you focus away & it parses it

could

env | grep OPENAI_API | cut -d '=' -f 2 | ....

have been written as

echo $OPENAI_API | ....

?

yup

.. and don't forget to subscribe! Or you can grab the RSS feed by pasting the URL into your feed reader. (or I think this is it: duncancragg.substack.com/feed)