Hacker News new | past | comments | ask | show | jobs | submit login
HotDrink: Constraint-Based UI Programming in JavaScript (hotdrink.github.io)
55 points by vmorgulis on Jan 28, 2016 | hide | past | favorite | 10 comments



This would go great with a lightweight ClojureScript-based DSL to replace all those 'something, something -> something' "method" strings.


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!?


This reminds me of GSS: http://gridstylesheets.org/


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


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.


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


Let's all look :-D


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

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

[3]: https://github.com/djfm/descriptive-todo-app/blob/master/tes...

Edit: formatting



"HotDrink"? Why not call it ristretto?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: