> -Poor performance in regions far away from the server (+- 10 second lag for a > response to a button click) e.g server in US/Canada and client device in > Asia/Africa etc.
Each tool has limitations, as far as I know this approach doesn't work well in high-latency networks. One easy technic to improve user experience in such cases could be to communicate clearly what's going on, for example by showing a progress, so user realises that it's ok and need to wait a little bit. The framework actually does that, when you click on something the spinner should be shown (the CSS seems to be broken right now so it won't displayed properly right now, I need to fix it :)). > -Poor performance in low bandwith regions (partially due to websocket usage?) Strange, there should be no issue here. The high-latency is the problem but the bandwidth is not. The data sent, gzipped html is quite small. And the LiveView additionally optimises html sent (it does diff on the server, so only tiny diff is sent), so very little data is sent over network. I guess the issue is seen if someone bind keypress event in the text field with the server action. I had issue with websockets in some other project, it worked poorly on 3G network, so I had to remove it and use `fetch` and it worked well. That's why I didn't used websockets here and used plain `fetch` instead in this framework. From my understanding websockets itself is good, but too low-level, you need to write a higher-level wrapper around it that would handle reconnects, timeouts etc. I don't know such wrapper library (socket.io is too large), and don't want to write the code myself. > -High data usage (server request for every simple click, websocket usage > again?) Hmm, don't think that's an issue, any site with pictures would dwarf the gzipped html, even if it's sent for each click. > -Poor scalability (Best for internal apps/POC/simple mostly static > sites/known number of users) Phoenix LiveView does the DIFF on the Server, it requires stateful server, but it's optimised and fast. Maybe could be if the load is really high, or maybe some mistake made in the code ending up in slow code. ThisFramework does diff on the Browser, and is stateless, so it should scale same way as other plain old stateless web servers like PHP/Ruby with full page reload.
