4 ms·

Ok, so the trade off is a less snappy UI as soon as you have a state, because you can't do optimistic updates on the view, send the request, then deal with the

Ok, so the trade off is a less snappy UI as soon as you have a state, because you can't do optimistic updates on the view, send the request, then deal with the error. But you write only the code of the validation, and the vue, once, so it's more productive, and the state is always consistent. I assume this means no PWA mode, although I don't really miss this.

jjdeveloper 5y ago
The round trip is very quick, websocket with a tiny payload in most cases. This video does a great job of discussing the advantages (skip forward to 6:50) https://youtu.be/8xJzHq8ru0M https://youtu.be/8xJzHq8ru0M
- BiteCode_dev 5y ago
  Payload size doesn't matter that much, a ping is ping. Currently my ping to this website is 167 ms: ping news.ycombinator.com PING news.ycombinator.com (209.216.230.240) 56(84) bytes of data. 64 bytes from news.ycombinator.com (209.216.230.240): icmp_seq=1 ttl=49 time=167 ms 64 bytes from news.ycombinator.com (209.216.230.240): icmp_seq=2 ttl=49 time=167 ms 64 bytes from news.ycombinator.com (209.216.230.240): icmp_seq=3 ttl=49 time=167 ms Which means it's a cost I have to pay, before payload matters, before parsing matters, before rendering matters. I'm at home, on fiber, on an ethernet cable, so ping should be very fast. And it can be: ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=5.63 ms Unfortunately, the network is not uniform. It's of course, worse on Wifi, and even worse on mobile phone, on the go. Depending on your location, YMMV quite a lot as well. Then you have hardware quality playing a role, the user may use other software (torrenting, streaming, playing) that can also affect that. Bottom line, you cannot assume the internet connection is snappy. Or stable (which is a problem with websocket, as you have to implement robust automatic reconnect, and it is slow and expensive, but then your use cannot use your software). So knowing the trade off you make is important. On a local network in the corporate world, life view seems like a terrific deal. On a heavy mobile user centric app, it will probably hinder your app ergonomics.

jjdeveloper 5y ago

The round trip is very quick, websocket with a tiny payload in most cases. This video does a great job of discussing the advantages (skip forward to 6:50) https://youtu.be/8xJzHq8ru0M https://youtu.be/8xJzHq8ru0M

BiteCode_dev 5y ago
Payload size doesn't matter that much, a ping is ping. Currently my ping to this website is 167 ms: ping news.ycombinator.com PING news.ycombinator.com (209.216.230.240) 56(84) bytes of data. 64 bytes from news.ycombinator.com (209.216.230.240): icmp_seq=1 ttl=49 time=167 ms 64 bytes from news.ycombinator.com (209.216.230.240): icmp_seq=2 ttl=49 time=167 ms 64 bytes from news.ycombinator.com (209.216.230.240): icmp_seq=3 ttl=49 time=167 ms Which means it's a cost I have to pay, before payload matters, before parsing matters, before rendering matters. I'm at home, on fiber, on an ethernet cable, so ping should be very fast. And it can be: ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=5.63 ms Unfortunately, the network is not uniform. It's of course, worse on Wifi, and even worse on mobile phone, on the go. Depending on your location, YMMV quite a lot as well. Then you have hardware quality playing a role, the user may use other software (torrenting, streaming, playing) that can also affect that. Bottom line, you cannot assume the internet connection is snappy. Or stable (which is a problem with websocket, as you have to implement robust automatic reconnect, and it is slow and expensive, but then your use cannot use your software). So knowing the trade off you make is important. On a local network in the corporate world, life view seems like a terrific deal. On a heavy mobile user centric app, it will probably hinder your app ergonomics.