i’m not saying you should generate websites the way that i generate websites, but whenever i look at how other people generate websites i am very unimpressed

is

<element name="h1" namespace="&xhtml;">
<value-of select="atom:title"/>
</element>

really better than

<h1>{{ post.title }}</h1>

?? no. but also yes

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

Follow

@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

Sign in to participate in the conversation
📟🐱 GlitchCat

A small, community‐oriented Mastodon‐compatible Fediverse (GlitchSoc) instance managed as a joint venture between the cat and KIBI families.