Lady @Lady@cat.family

@virtue @coriander “feels clunky for reasons i’m not sure of” is a good summary of the linguistic definition of “ungrammatical”

@coriander i am like… i see your point, but “which flowers is” is just wrong

@coriander “the gardener are planting which flowers”

@wallhackio when you don’t know about commit -a --amend --no-edit

@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.

@wallhackio @aescling @vaporeon_ notably in a traditional SPA the javascript can be cached so the only thing you are requesting on each page load is a very small JSON blob, which is much lower bandwidth than sending entire rendered HTML pages every time somebody navigates to your site, which are constantly changing and not cacheable

@wallhackio @aescling @vaporeon_ hydration is extremely a “i have fast internet and slow javascript what do i do” kind of solution

@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

@aescling @alyssa that is because you never reply to my emails