3 ms·

I remember there was some ridiculous article here where the author claimed to build world's fastest web app with PReact. It was a hierarchical list of HTML5 fea

I remember there was some ridiculous article here where the author claimed to build world's fastest web app with PReact. It was a hierarchical list of HTML5 features with some tick-boxes. Out of curiosity I converted the giant JSON blob to <ul><li> list. HTML was about 15% smaller than JSON. You could also do most of the "logic" of the app via styling and normal HTML controls.

Geee 8y ago
The benefit of JS comes in incremental updates. When you update that list with a new item, you can use optimistic update and small payloads in JS, while in HTML you have to load the whole page again, which is slower.
- e12e 8y ago
  You have to load the whole page again. It may be slower.
- gambler 8y ago
  Firstly, the application I was talking about[1] didn't have real updates. Secondly, no one stops you from doing incremental updates with HTML except they way you design your data structures and UI. In fact, HTML has something that JSON doesn't. Semantics. This means you can create a generic setup for incremental updates based, say, on element IDS. --- [1] https://hackernoon.com/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7 https://hackernoon.com/10-things-i-learned-making-the-fastes...
- 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.

Geee 8y ago

The benefit of JS comes in incremental updates. When you update that list with a new item, you can use optimistic update and small payloads in JS, while in HTML you have to load the whole page again, which is slower.

e12e 8y ago
You have to load the whole page again. It may be slower.
gambler 8y ago
Firstly, the application I was talking about[1] didn't have real updates. Secondly, no one stops you from doing incremental updates with HTML except they way you design your data structures and UI. In fact, HTML has something that JSON doesn't. Semantics. This means you can create a generic setup for incremental updates based, say, on element IDS. --- [1] https://hackernoon.com/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7 https://hackernoon.com/10-things-i-learned-making-the-fastes...
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.