## Origami inspired prototyping

* TOC
{: toc }

### Origami

Over the last week, I've fallen smitten for Facebook's Origami prototyping tool, which was originally built on top of Apple's Quartz Composer, but is now a standalone Mac app. It suprised me because I don't usually expect much from node-and-wire coding environments. I think the main feature that got me is that you can see the live-updating intermediate values of all computations. It's amazing. It makes looking at static code unbearable. Additionally: there's no run button - it's hot-realoading. And they have a great way to add nodes (they call them "patches") via the keyboard.

### Node-and-wire prototyping

This morning, I had the idea of prototyping the Origami UI in Woof. I had a fun few hours doing it: http://woofjs.com/create#origami

I had to come up with techniques for managing lots of things I'd never had to do before in Woof, mostly around nested components and layout. Stuff that HTML and CSS does for you in annoying ways. Turns out it's pretty annoying to calculate widths and paddings manually too...

### Thoughts on a new language...

The idea in my head is that you have a dependency graph of all the values. The trick, of course, is sequential evaluation and events. Mostly events.

#### Pure expressions

These are simple. They should always have live-updated values.

They are normally things you'd want nested internally (which is a common complaint of node-and-wire tools), but when "proccessing" a thing, you want vertical or horizontal sequencing, such [as in Elm](http://elm-lang.org/docs/syntax#infix-operators).

#### Sequential evaluation

I think we can do away with it entirely. If you actually need it, you can model it explicitly as [I show in this demo](http://woofjs.com/create.html#animate-via-frames).

#### Events

Can we do without and just have reactive values? Clicks are reactive list of all clicks, and you can get last one and check timestamp a la http://futureofcoding.org/prototypes/streamsheets/.

Potentially, this will be too conceptually difficult, for the same reaons it was to do [CycleJS Flappy Bird without centralized state](https://gist.github.com/stevekrouse/85f350eb82ebbf5b2c244aa9aeffc453) and we'll need a reducer. But maybe nested state via statecharts could save the day.

### Follow up questions

1 - What do I not like about cyclejs and elm (and what's the difference again)?

1a - Is the main reason that it's terrible to code in streams and elm, and thus streamsheets?

1a1 - Idea to make cycle better: swap it: make value be values and have a history function that gets the stream on it?

2 - Is the main difference explicit modeling of time and explictly listing all state?

2a - We don't really need explicitly listing state, just reactively defined

2a1 - What is reactively defined state? wont it eventually bleed into everything depends on everything else and we're back where we started? in other words, the reducer thingy seems stinky for some reason ... it's annoying to use, but making it easier to use just gets rid of the benefits of using it

2a2 - Can we make a calculus for how we want this to work to simplify things? Such as what I was trying to do with [Reactive Woof](http://futureofcoding.org/journal#reactive-woofjs) ... Or is this a cyclejs data structure?

3 - How to statecharts keep track of state...? .. go to Ian's book

3a - Can you do statecharts without events?

4 - Difference between hot and cold streams?

5 - At the end of the day, can we really realize my perception of Anre's vision in [this article](https://staltz.com/unidirectional-user-interface-architectures.html) that all things contain all the ways to modify that thing? Or is it impossible because we want to branch in too many ways in our code, not sequentially, but just with nested cases? Would it at all be possible to define things in one place only? Or would that just hurt our brains even if we could do it?

Author: Steve Krouse