3 ms·

The main issue I have with this idea is that in practice I've almost never found the difference in payload to matter all that much, even on bad connections. In

by mercer 8y ago

The main issue I have with this idea is that in practice I've almost never found the difference in payload to matter all that much, even on bad connections. In some cases, even sending the entire HTML document and diffing on that using morphdom (because redrawing does bring noticeable cost rather quickly) was a viable strategy even compared to the most optimal json payload. I'd very much like to see some examples that prove me wrong though, because while I've done some experiments, I might be underestimating how complex many web apps are. It's mostly that the apps I built in hindsight were often better off with a more old fashioned server-side, morphdom, turbolinks (or maybe intercooler?) type approach.

Geee 8y ago
It's not the payload size that matters really, but the latency of requests which you have to wait between interactions, making the UX synchronous and slow. Good examples are, well, almost any modern and popular app. Like Trello for example. Users spend lots of time on the same page making micro-interactions, creating cards, moving cards around, adding tags, etc. You want to make the in-app experience as flawless as possible in these types of apps, and the initial JS size doesn't matter so much especially when it's cached. There's also lots of shared state and you might be saving multiple things on the server at the same time or uploading multiple files in the background while editing other parts. You might want to store data offline and sync later to the server. Once you have decent complexity, JS app with framework such as React help a lot.
- mercer 8y ago
  > It's not the payload size that matters really, but the latency of requests which you have to wait between interactions, making the UX synchronous and slow. I'd use websockets if that was an issue. That said, Trello is a good example where I do agree a web app is a great solution.

by mercer 8y ago

Geee 8y ago

It's not the payload size that matters really, but the latency of requests which you have to wait between interactions, making the UX synchronous and slow. Good examples are, well, almost any modern and popular app. Like Trello for example. Users spend lots of time on the same page making micro-interactions, creating cards, moving cards around, adding tags, etc. You want to make the in-app experience as flawless as possible in these types of apps, and the initial JS size doesn't matter so much especially when it's cached. There's also lots of shared state and you might be saving multiple things on the server at the same time or uploading multiple files in the background while editing other parts. You might want to store data offline and sync later to the server. Once you have decent complexity, JS app with framework such as React help a lot.

mercer 8y ago
> It's not the payload size that matters really, but the latency of requests which you have to wait between interactions, making the UX synchronous and slow. I'd use websockets if that was an issue. That said, Trello is a good example where I do agree a web app is a great solution.