JavaScript is integral to this. I suppose there is a need for a, "This is what the page is about if you don't have it turned on" bit.

This isn’t a demos page--they are just static docs where the only interactive part is some JS to make it quicker to copy/paste. Right now these docs aren’t accessible to many reading options or search indexers since there is nothing on the page.

True I suppose. But if the reader is a "I disable JavaScript" type of person, isn't this pretty far from something they'd be interested in? I will preface the following with an, "OK yea kind of a joke but you get the point" comment, but I mean you don't use QR codes as a marketing strategy for the Amish.

I don’t know I agree with this perspective. The internet is in many ways an unsafe space & surfing it with JavaScript in allowlist mode (e.g. blocking by default) should be in the bag of tricks users can use to mitigate some potential issues. One may also want to automate scraping these docs to put in another tool or in a new, independent search engine whose MVP isn’t including a whole JavaScript runtime (and can be trick to read from the source code if using a tool that generates docs from comments instead of a generic file so the output HTML is easier to consume).

Setting a good example & being a good steward of the net is something docs like these could/should provide; that is to say, the author could make the static parts static & offer a <noscript> with a brief description of the interactivity the user might be missing. The docs are likely coming from dog-fooding the library, but came at the cost of making static content maximally available & providing a noscript message.

It's not just static content. It's Markdowns loaded right into HTML.

The content is static. The fact that you’re loading it dynamically is immaterial and a bug, not a feature, at least at this scale. If you serialised the resultant DOM and shipped that minus the now-superfluous pieces (ehtml bundle, template, preloads), the result would be identical but it’d load significantly faster and more consistently for everyone. (I say “more consistently” in part for user agents that don’t support, or that disable, the scripting, but also for agents that do support it but it fails to load properly due to network conditions, which is way more common than most developers realise.)

For bonus marks, inline all the subresources (SVG, CSS and utils.js) and strip dead styles, and you can probably squeeze the entire thing into the 14KB TCP slow start window (compressed), so that it would have completely loaded for me in about 430ms at most (though it should have been closer to 200ms) instead of 1.7s, and with no reflow due to the logo not having been given dimensions.

Slow down pal. How am I supposed to have SSG and hydration and hook with such a simple setup!? I need my system to be webscale™, not maintainable with minimal moving parts.