let’s take a durable, easily‐processable, semantic, and structured markup format and let’s deal with it by ignoring all of that and substituting strings for other strings

@Lady do you personally prefer using XSLT or using string templating languages? I have some mild fondness for each, myself

@jamey well, i prefer XSLT if the data source is XML. if the data source isn’t XML then you might have issues

@jamey unrelatedly, you know a lot about Atom feeds! i currently keep the full text of my blogposts in my Atom feed, which is good, but i worry it will result in a Quite Large filesize over time. i know i can use RFC5005 to paginate the feed, but do you have any thoughts on this besides? how big is too big for Atom feeds, or is size not really a practical concern?

@Lady oh sure! I wouldn't say I'm an expert on what limits exist in deployed feed readers by any means, but I have looked for answers to this question before. I remember reading that the Windows RSS client library (everyone is surprised that this is a thing) had a file size limit, but I can't find the limit now. I also see various people talking about FeedBurner being limited to half or one megabyte, and I've heard iTunes limits podcast file sizes. In general my impression is that 0.5-1MB is probably safe for most readers but larger sizes might break some.

Separately, there are of course implications for your web host's bandwidth limits if you serve a large feed. Several popular feed readers fail to correctly implement HTTP cache validation, so they'll pull down the entire file regularly even when it hasn't changed. But even correctly implemented clients generally have to download the entire file even if only 1% of it has changed, so allowing the feed to grow unbounded can multiply your bandwidth usage by a lot.

As far as I know those are the only important considerations about feed size!

@jamey i should probably add to this that i am quite fond of GNU Make, which is (at any high level of complexity) basically built on top of string templating, so

@Lady I built a big thing with m4 once and still feel like that was a reasonable choice so… yeah, string templating is okay in my book 😂

I have often wished for HTML validators that understand modern template languages though. then I wouldn't mind that the language itself doesn't understand anything about the structure of its output and can't detect errors for me

I've also wished for both XSLT and string templating languages that I could provide an input schema and validate that the template only tries to access fields that will actually be in the input

@Lady I mean, we have many languages that exist mostly because they are more tasty syntactic sugar than their predecessors. So. I have opinions, even if you disagree. 😉

@aschmitz oh i don't mind tasty syntactic sugar, but i am bothered by taking something structured and treating it as tho it is unstructured. it feels like a lot of templating languages do this latter thing

@Lady I think JSX does this okay (though it has other problems), in that you can only template things in reasonable places, not, like, half over a tag and also body content (like a fully preprocessed templating language might do, which of course would invite various vulnerabilities).

@aschmitz i wish JSX was better standardized and less wedded to reactive rendering usecases but i’m otherwise not opposed to it!