Authoring notes

Is there anything else to be mindful of with the use of @render? Yes. There are a few things—

To re-iterate the most important: forcing JSON into an HTML parsing context means that any text that's not escaped for HTML poses a risk to whether and how the loader does its job. In the worst cases, it could lead to cross-site scripting if you act without care. It's important to escape the data to prevent this. A good rule of thumb is to treat any open angle bracket in your payload (after the @render line, that is) as an oversight that needs immediate correction, regardless of the provenance of the data.

While consistently escaping U+003C LESS-THAN-SIGN (as \u003c) in all other parts of the JSON payload is enough to eliminate the cross-site scripting threat, for good measure, you may wish to always escape U+0026 AMPERSAND (as \u0026), too, since if the input goes through multiple rounds of parsing, then the sequence <script can become <script if you are inconsistent.

Secondly, if you don't have enough influence over the server configuration to control the Content-Type header (example: you have a static site), then you'll probably want to save your data with a .json.html file extension. This is also/already more or less required for any files that you intend to share that are "unhosted" and expected to be opened straight from the file system—it's what will get the correct double-click behavior in most system file managers and hint to the browser how you want it to be parsed.

Additionally, when your loader runs, be aware that browsers will by default put any UI elements that you add to the page into a document in quirks mode rather than standards mode. This can affect layout and cause hard-to-track-down issues. It's not impossible to address, but your application logic does have to be aware of it if you hope to be able get out of quirks mode.

Lastly, be aware that, although @render heretofore has had no particular significance in JSON, we do want to play well with the JSON-LD ecosystem. It's anticipated that it will be useful to define semantics for the fragment in the script element src attribute. (It may be beneficial for the fragment to serve as shorthand for a @type annotation, for example.) For that reason, use of the fragment identifier in the script element src attribute should be avoided for now until there has been an opportunity work out the exact semantics.

Remember that wherever feasible, you should probably try to use existing standards like JSON Schema and JSON-LD attributes to describe the data, but this is not necessary for @render to work.