Same but I already find ajax based app very slow if they implement optimist updates, now with this system, you have to wait a round trip for each interactions. This means click a counter will round trip before updating?

You can apply this to any interaction where you have to wait for a round-trip anyway. It saves you coming up with a JSON schema and endpoint for the request, and then gluing it all together.

It doesn't mean that you don't use javascript at all, you just use it in a limited fashion for enhancing specific bits of your website. Just like it was in the 2000s when making websites was easy.

If you want to save state for the counter to the server you would do a round trip. Otherwise you’d use some light weight JS lib, most popular one for simple interactions is Alpine.js. So simple ui JavaScript use Alpine and something like form validation and showing errors will do a round trip and save you writing validation twice (on the client and on the server).

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.

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

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.