First off, I’m really happy this project has come to be. It has a lot of creative as well as didactic potential, which are two fields I feel are often neglected in the ‘programmer world’ (leaving a wide and unnecessary gap between programmers, creative coders, and teachers). I’m interested in seeing how the project evolves.
Not really being a creative coder myself, I for some reason started working on a small ‘UI’ problem in one of my notebooks, trying to figure out whether this might have some nice solution, with
viewof etc… Soon enough, though, I figured out the gist of the uphill battle I was fighting: although
This is good and wonderful of course, but somehow I have the feeling that many people will try to do some kind of small UI thing, here or there, be it supporting their d3 creations, for some other thing, or just absent mindedly. And although I don’t think Observable should set it’s aim at actually working UI logic out at all, it seemed to me that there’s something we’re missing here, that might explain why I thought doing some UI thing might be fun/possible in the first place, but couldn’t.
Then it hit me: the inherent circularity in UI’s is solved through conceptually distinguishing the two flows of data. Data is what goes in, and events come back out. But this is not workable in Observable at all, because there’s a whole DOM ecosystem within a notebook already, and this would radically complicate things. But there’s another, similar yet orthogonal, conceptual distinction that is made in UI frameworks, specifically those that pieces things together with dependency graphs (I’m thinking Knockout, Vue.js, and others MVVM etc): the initial nodes, and the computed nodes. In Knockout, this is
ko.computed, and in Vue.js, it’s the
computed properties. The former are meant to be able to be changed, at any time, anyhow; the latter just compute. This distinction is notably missing from Observable, although the reactive layer is essentially the same (at least to Knockout).
viewof, and then a small standard library. But I think this one syntax addition might be worth thinking over: designating certain variables as ‘inputs’, i.e. actually stating that they are solely there to be written to by other pieces of code. One might write them with a question mark, marking their unknownness at time of writing, as such:
? x = 6 where a default value is provided as well. Input variables are distinguished from normal variables in that (1) it is not allowed to let their default value depend on any other variable, and (2) they can be written to, whereas normal variables obviously can not.
It’s late where I’m from, so maybe this is just late night gibberish, but I’d love to hear your thoughts if it’s anything more than that
Keep up the good work!