
HotDrink: Constraint-Based UI Programming in JavaScript - vmorgulis
http://hotdrink.github.io/hotdrink/
======
pbkhrv
This would go great with a lightweight ClojureScript-based DSL to replace all
those 'something, something -> something' "method" strings.

~~~
munro
Definitely, eDSL would be better than having to write a parser. It would make
interoperating with JS, programmatically building easier, and did I mention
you don't have to write a parser!?

------
JD557
This reminds me of GSS:
[http://gridstylesheets.org/](http://gridstylesheets.org/)

~~~
obvio
the name is similar and confusing but it does something totally different

------
djfm
Sounds very cool! Looks like a spreadsheet with a rich, intuitive UI.

I'm working on a toy project with a similar aim where I'd like to also auto-
generate the whole UI (no markup needed), definitely going to look at your
approach closely.

~~~
sethjgore
can i take a look at your toy project? i'm working on something also.

~~~
Chris2048
Let's all look :-D

~~~
djfm
Sure but there's not much to see yet [1], that's why I didn't share.

I guess the more "interesting" part would be the models [2]: My first goal is
to try and generate a Trello like app with boards and lists without writing
any code specific to the app outside of the models, and keep the models purely
declarative.

I would outline the algorithm I have in mind as:

1) Ask the root model ("Goal") for available "slots", i.e. places where user
input is required to build new objects. The tests illustrate this [3].

2) Pass this all to a function (to be written) that prioritizes the inputs to
be filled (top level inputs shown first, deeper ones maybe hidden in a
disabled next step, etc.) and generates a React UI.

3) Then once there is data in the system, introduce a notion of "user focus",
e.g. if a user clicks an existing entity, then the entity fields are passed to
the function in 2) in addition to the available "slots" needed to continue
building objects and the app will know to prioritize the inputs that have
"user focus". Then you could have various "recipes" to generate the UI,
published as plugins. E.g. "show all in one form", vs. "step by step
onboarding". Same data, same goal, different UI.

I have a feeling many apps can be analyzed as a dependency graph between
models and a _lot_ of boilerplate can be deduced from the graph.

I'm doing lots of web development and I'm tired of writing code for simple
stuff. If anyone is interested, ping me on GitHub!

[1]: [https://github.com/djfm/descriptive-todo-
app](https://github.com/djfm/descriptive-todo-app)

[2]: [https://github.com/djfm/descriptive-todo-
app/tree/master/mod...](https://github.com/djfm/descriptive-todo-
app/tree/master/models)

[3]: [https://github.com/djfm/descriptive-todo-
app/blob/master/tes...](https://github.com/djfm/descriptive-todo-
app/blob/master/test/model.js)

Edit: formatting

------
vmorgulis
My coolest example:

[http://hotdrink.github.io/hotdrink/examples/drag3.html](http://hotdrink.github.io/hotdrink/examples/drag3.html)

And not easy to find github:

[https://github.com/HotDrink/hotdrink](https://github.com/HotDrink/hotdrink)

------
frandroid
"HotDrink"? Why not call it ristretto?

