and it would compile that into a continuous data binding expression (auto lifting was also useful for defining shaders in C#, they use similar techniques in JS/WebGL). But you are absolutely right: the book keeping was too much, and if you had say a chart with 100x100 cells each individually bound, your startup time would really suck. Glitch (my current work) has a much lower cost per state read (where you install listeners), and, like React, does not require lifted operations: so you read some state into values, operate on some values, and store the values in some state somewhere else. Each read is traced as it happens, each write is logged as it occurs, everything in between is just normal code; no lifting is necessary (I think React is like that for reads and doesn't allow for state writes outside of DOM updates that appear immutable).
The only question now is about granularity, and that is completely tweakable. There are some issues with state cycles, which have to be rejected (otherwise, non-monotonic changes might not work correctly in an incremental context), and keeping state separate helps prevent "false" cycles from occurring, but I'm looking at ways to separate cycle detection with state update granularity, and anyways, none of that applies to React since writes aren't handled in the framework.
What I'm interested in is expressiveness; as a PL person I have a cliche benchmark: can you implement a compiler in React? A compiler, after all, is just a "view" of flat text into some other form (e.g. a typed AST that can be used as a model in a language-aware editor). For React, I think the symbol table would stop you (everything else in a compiler is pretty much functional), but I might be wrong.
I'm definitely interested in React and will keep looking at it. Unfortunately, I don't do any web work so finding a proper context is hard.
http://bling.codeplex.com/
So you could write something like:
and it would compile that into a continuous data binding expression (auto lifting was also useful for defining shaders in C#, they use similar techniques in JS/WebGL). But you are absolutely right: the book keeping was too much, and if you had say a chart with 100x100 cells each individually bound, your startup time would really suck. Glitch (my current work) has a much lower cost per state read (where you install listeners), and, like React, does not require lifted operations: so you read some state into values, operate on some values, and store the values in some state somewhere else. Each read is traced as it happens, each write is logged as it occurs, everything in between is just normal code; no lifting is necessary (I think React is like that for reads and doesn't allow for state writes outside of DOM updates that appear immutable).The only question now is about granularity, and that is completely tweakable. There are some issues with state cycles, which have to be rejected (otherwise, non-monotonic changes might not work correctly in an incremental context), and keeping state separate helps prevent "false" cycles from occurring, but I'm looking at ways to separate cycle detection with state update granularity, and anyways, none of that applies to React since writes aren't handled in the framework.
What I'm interested in is expressiveness; as a PL person I have a cliche benchmark: can you implement a compiler in React? A compiler, after all, is just a "view" of flat text into some other form (e.g. a typed AST that can be used as a model in a language-aware editor). For React, I think the symbol table would stop you (everything else in a compiler is pretty much functional), but I might be wrong.
I'm definitely interested in React and will keep looking at it. Unfortunately, I don't do any web work so finding a proper context is hard.