>         Unfortunately I think the load time can be a deal breaker (for
>
>     Please! Let me argue that it depends on the app. For long running apps
>     like gmail, it makes sense to wait a little bit...

OK, point taken :) It's definitely worth waiting a couple seconds for a
big app. But most apps are small and the faster they load the better.

>     forward.scm deviates a little bit from purely functional elm
>     architecture in
>     the sense that XHR is done inline in update procedure (called
>     controller)
>     instead of relying on a continuation.
>
> There is other issues with forward.scm about html input that I never
> worked
> around. That's why I moved to reactjs in cons (the above proposal that is
> somewhat slow)

Do you mean the input issues involve just hacking around browser quirks
instead of some fundamental problem with the library's architecture?

How much time and interest do you have for this browser/JS work? You
could start creating <https://docs.schemers.org/> as a real world
application of the libraries you are working on :) But if you're busy
with other stuff, I understand. I also have so many projects that I
don't mind if other people do most of the work on the API clients. We
can also collaborate on any of these.