If you aren't aware, text posts here can also be viewed and shared in a blog/article format. I made a few stylistic improvements. If you happen to be reading this in the text-post mode, you can read the article version here.

The primary goal was centered on making the title pop more. I darkened the background, I brightened the title, and most importantly, I made the titles larger in a clever way.

Recently a new library went viral by Chang Lou called Pretext. Its strength is being able to calculate text offsets insanely fast without interacting with the DOM. The key insight is that because we are a Reddit-like site, titles can vary in length significantly. Some titles look best with a larger font size if they are short, or a smaller font size if they are long. And because we aren't primarily a blog with a small core of authors, making manual adjustments per article/text post is not realistic or practical. We don't have a full CMS for this to be edited in. It just needs to look good automatically despite a huge variation in title lengths.

To look the best, these criteria should be met. The title should be as large as possible. The title should not exceed two lines. The title should not be wider than the article body. Line breaks in the title should not lead to the second line significantly overhanging the first line. We don't want titles that look like James William Bottomtooth III. Last, there should be a fixed maximum size to accommodate single-word titles.

And Pretext makes it easy to get there with a simple binary search outside of the DOM, assessing what outcomes we will get.

The last trick is to avoid unwanted hydration effects. Personally, I hate that hydration is something that end users have ever become aware of. Solving this on the server side can't work because we don't know everything about the user's browser at the time the request is made. But we want to display the title as quickly as possible without it loading after everything else, and without a redraw, even if it would be fast.

The solution we came up with is caching the result on the server. So for the majority of users, the title will have the correct initial font-size property. This works because the articles are a fixed width. As long as the binary-search, server provided initial value, and container width are specified in the same units, each client should calculate the same result, with exceptions. For those few exceptions, they will see an element resize during the page load, which isn't that uncommon to see on websites today. Each client reports their calculated font-size value back to the server. We could always reduce the percent that reports if this were to send us too much redundant data, but it is trivial regardless. The server then uses the modal average for that post in the server-side render. The client then makes its own calculation, likely producing the same number.

There are improvements we could make, but we'll cross that bridge when there is demand. I've added logging for what kind of numbers come back, along with user-agent values, to see if any mobile clients are producing a different result. If we decide to, we could compartmentalize different user-agents into separate buckets. If that happens, it may turn into a fun classification problem. I look forward to it if the data that comes out of this creates a good excuse to work on that kind of problem.

Besides this, and less interestingly, there is also more space between the title and author information, better article date formatting, a lower contrast <hr> separating the title section and the body, and the nature banner has been removed, giving us a more jet black look. The sort links remain, even though they aren't very relevant to the article, because they draw some curiosity and hint at the reality that the reader is on a link aggregator site. The invitation they offer for exploration makes them worth keeping.