Working on a low-code project for native apps. The idea is predicated on the argument that many apps are just "skins around a database". Why is declarative UI + declarative queries a bad idea? For example we create a todo app like this:

this approach is similar to one of eve’s pro types, although they were closer to datalog than sql. you might find their experience report useful:

Thanks Garth. I will check the video out.

Main challenge I think of is the scenario where an temporary edit state doesn't validate. As an abstraction, suppose you have two text fields which should contain non-negative integers that sum to 10. Honestly, I think the solution is to keep both keep both committed consistent values as well as temporary being edited values in the database. Then the UI has less to do with it, and it's more a question of when/how to commit changes.

I have developed a similar dsl + framework like this. The main challenge is dealing with async. Network data fetch is inherently async, but user expect the UI to be sync. Binding async state to UI is a open challenge still being addressed by UI framework like React. While render-as-you-fetch (https://reactjs.org/docs/concurrent-mode-suspense.html) looks promising, but React did not ship with concurrent mode yet for many good reasons. Another challenge is efficient data caching & batching. With manual I/O, developer is manually tweaking the I/O operations. Binding async expression to UI, force the developer to rely on the framework to do the right thing. It is possible to auto-optimize in many cases, but it will require the developers to "let go" some control. It requires significant trust between you and the developers using your stuff to write software.

looks like flutter, I like it

Thanks @taowen. Did you open-source the framework you built? We are working on doing these auto-optimizations. So far, we have seem some impressive results. But getting developer trust is indeed a salient issue.

@elvis chidera It is not open sourced. Framework was not enough, we implemented a DSL on top of typescript. Using typescript transformer to implement the additional semantics we need to transform sync code to async javascript generator, then using a scheduler to run those generators.

@taowen you probably already seen the React server component thingy https://twitter.com/rauchg/status/1341220660538830848?s=20

yes, yet another attempt to solve the waterfall problem