am I missing something or is hydration (the web development concept) just frameworks originally invented to make SPAs reinventing the wheel????
☭
@wallhackio > hydration (the web development concept)
The what now? 
@vaporeon_ @wallhackio when loading a webpage from a site developed in react in such a way that it uses what they call “server-side rendering” (SSR), you initially receive a page in an intermediary stage where the HTML is rendered. (befur SSR was the norm, client side JS was fully responsible fur rendering the entirety of the HTML on the page.) “hydration” refurs to the effect of loading extra JS to load the react runtime into the client, so that the page can do all the interactivity and client side rendering and client side routing expected of a react-based website
@vaporeon_ @wallhackio this is not limited to react
@aescling @vaporeon_ it just seems like something that should have always been there in the first place
@wallhackio @aescling @vaporeon_ transmitting a json blob over the wire and rendering it with javascript is faster than transmitting HTML over the wire and making it post facto dynamic, if your JS is fast and your rendered HTML is complex and your internet is slow
@Lady @aescling @vaporeon_ is this because the same content that could be represented in HTML can be represented in a much smaller file size as a JSON blob?
@wallhackio @aescling @vaporeon_ JSON is neither smaller nor more efficient than well-designed XML https://balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html
however your average React frontend is not well-designed XML. it is messy XML designed for rendering to users rather than clear internal representations of data. naive hydration probably depends on large numbers of unique and possibly opaque classes and identifiers in order to orchestrate interactivity. it is encoding more information: not only the data, but also how to render it. more information = more bandwidth, necessarily
for a single request, arguably there is no difference between conveying rendering information in markup and conveying it in javascript. but note that:
• javascript can be cached across multiple requests, whereas prerendered content cannot, so encoding rendering information in javascript [and CSS] reduces the size of subsequent requests. request 1: data+rendering. requests 2+: data only
• hydration requires supplying rendering information in javascript anyway (otherwise you just have boring old serverside rendering), so it requires conveying rendering information twice, once in markup (uncached) and a second time in javascript (cached). the benefit to this duplication is it means request 2+ can still be data only, but only insofar as the user never navigates away from the page
what this means is that hydration is only a little worse than serverside rendering in the worst case (on a fresh load with nothing cached, rendering information must be supplied twice), but competitive with SPA design in the best case (so long as the user does not navigate away from the page, only data needs to be transmitted and not rendering information). in the middle case (fresh page loads, but with the javascript already cached) it is no different from server side rendering
but the best case is just what SPA offers all of the time. the advantages to hydration over SPA are not in efficiency but in being more friendly to robot crawlers (who no longer need javascript to index the page) and in having lower startup time (since the browser can start rendering immediately without waiting for JS to load). the second of these benefits suggests a deeper problem in the design of the application, though, since it is 2026 and JS should be fast.
@Lady @wallhackio @vaporeon_ the few XMPP developurrs left are very frustrated by JSON dogma because XMPP clients have long known how to do fast and memory efficient streaming parsing of XML data