Promises are going to solve this problem in an elegant way, expect it in next major release.

That said, I've release a client/server game (online sailing regattas) in Elm & Play/Scala with websockets, and current API was enough for me: https://github.com/etaque/tacks

Consuming data isn't hard. Creating a dashboard that displays the values sent down on an interval over a websocket is super easy.

Sending data isn't hard. Sending the mouse coordinates on a click to the server over a websocket is super easy.

There is, however, no easy way to consume data and send a response. To write an echo server, for example, you currently have to send the data to a javascript port and then read from the port to send it back.

I ended up implementing this in JavaScript using Rx, but the core concept is the same:

    Incoming requests:     --a------------->
    Requests to server:    ---b------------>
    Responses from server: -----------d---->
    Updates to app state:  ---c--------e--->

a - User "sends message" to chat room

b - Handler for that action queues a request

c - Handler for that action also queues a local update

d - Server responds with the sent message

e - Handler for that response queues a local update

Yep, it was specifically when I wanted an application that would run a game loop involving round trips to the backend for every step that I ran into a lot of difficulty. Ports were not very clearly documented and I didn't find any examples, so I wound up writing Javascript instead.

It this problem bad enough that you would consider it to be a deal breaker? Can't one shell out to JS for the pain points?

You can do stuff in JS really easily with [ports](http://elm-lang.org/learn/Ports.elm).

The TodoMVC example in Elm does this to use localStorage: https://github.com/evancz/elm-todomvc/blob/master/Todo.elm#L... and https://github.com/evancz/elm-todomvc/blob/master/index.html...

The same can be done for HTTP or WebSockets if you have needs that are not met by the existing APIs. Furthermore, the next major release is focused on drastically improving these APIs.

So there's a safety valve right now and there's a plan of how to make things excellent. I would not block on this, but I am also relatively biased :)