|
|
|
|
|
|
by platz
3851 days ago
|
|
|
Elm's reactive model is best suited to UI's in my opinion. There's no good way to limit the data coming at you in a push-only model, so if you can't keep up with the incoming data flow bad things happen. On the UI this case usually isnt encountered, but on the server one needs mechanisms to deal with this |
|
|
Imagine you subscribe to lots of realtime data sources (e.g. via websocket), that deliver lots of updates to your UI. Then you have a race condition whether you can draw the updates faster than you receive them.
In an eventloop environment like Javascript it could be self-regulating (http/ws stack wouldn't receive new frames until you return from drawing. But it might also be not (because a C++ background thread in your browser receives the messages and queues them until they can be pushed to JS) - then you might get out of memory. But I totally agree that it's an exception for UIs to deal with such scenarios, but it should be normal an a server.