On the Utility of JSON Feed

JSON Feed is a specification by Manton Reece and Brent Simmons for a syndication format like RSS and Atom that uses JSON instead of XML. Robb Knight posed the question:

Ignoring podcasts, which has to be RSS, is there an argument for using RSS/atom over JSON feeds?

Ruben Schade responded with a thoughtful post citing several theories as to why RSS/Atom feed are still the default:

  • JSON Feed suffers the XKCD Standards Effect. Every blog has RSS support, even those that implement JSON Feed. I’ve yet to encounter the reverse. If JSON feed were offering anything more than an alternative serialisation format, maybe it’d be more compelling. But RSS does the job, and adding another standard didn’t offer much.
  • JSON Feed was mostly a redundant format. As I wrote in 2017, if the issue with RSS was XML, you could directly serialise RSS with JSON. JSON Feed was entirely new, which requires you to reimplement everything to do… what you can already do with an existing tool. Meh.
  • JSON Feed solved a problem for developers, not users. People who write material that end up in feeds, and the people who read those feeds, couldn’t give a toss what the format is written in. Those of us in the industry forget this at our peril, every single time.

These are great points and it seems unlikely that JSON Feed will displace RSS and Atom as the default syndication formats in use. However, I want to discuss that last point a little more.

Ruben is right that the typical visitor that wants to subscribe to your website doesn’t care what the format is, as long it works in their feed reader. Although I’d argue that developers that want to make use of content in a machine readable form are users too. And for that purpose JSON is way easier to handle than XML. Here’s a couple of examples of that in practice:

  • The unreleased tool that posts each new post on this site to Mastodon uses the JSON Feed as the source of posts.
  • This tutorial used the JSON Feed from Read Rust (an earlier project of mine) to build a CLI tool for the site.

It’s also easy to consume JSON on the command line with curl and jq/jaq. For example, this command line lists all the posts in the Linked List JSON Feed that are tagged with ‘retro‑computing’:

$ curl -s https://linkedlist.org/feed.json | \
    jaq '.items | map(select(.tags | contains(["retro-computing"]))) | .[].title'
"More Than You Ever Wanted to Know About the Windows 3.1 Graphics Stack"

All that is to say I think JSON Feed has utility even if it doesn’t replace XML based feeds. I think of JSON Feed as an additional representation of my website, not a replacement for RSS and Atom feeds. As I a result I offer both, so visitors can use whatever format makes sense for their use-case.

Impressions of React & TypeScript From an Elixir/Elm DeveloperPermalink

Alex Korban:

I was recently on a project where I chose to use React and TypeScript as part of the tech stack because of the existing skillset of my team. I myself managed to avoid both React and TypeScript until this year. So when I finally used them on a real project, I was looking at them as an experienced Elm & Elixir developer, coming from small niche ecosystems into the din of the real world. I think that’s an interesting perspective to share.

Reports like this based on real world experience are indeed often interesting. They can expose both positive and negative aspects of an ecosystem that go unnoticed if you’re already deeply invested, which can help drive improvements on both sides of the fence.

Perhaps unsurprising due to having already self-selected a preference for Elm, Alex found the TypeScript and React experience a bit underwhelming—although not only for technical reasons.

The Clarity and Usabilty of Standard UIPermalink

Louie Mantia lamenting the lack of standard UI in software these days:

Dan Counsell [on Mastodon]:

Screenshot of Mac OS X GUI controls.

Can we please have the macOS X Lion UI back? 😍

Yes, I would also like that. I would welcome any standard UI that gives us back some tools we lost.

There’s a refined clarity to this version of Aqua. It evolved gracefully to this point, where every element was distinctly different and yet cohesive. Consider the search field alone. Now, search fields have the same appearance of every other field: squared. The pill shape distinguished itself. Removing that characteristic introduced a level of ambiguity that is unnecessary. The same can be said for so much in modern visual design (or lack thereof).

There really is a clarity to those controls. They have decent contrast, depth is used to help make it clear they are interactive, and there’s even some colour.

It’s a shame that the idea of standard UI seems to have been relegated to the history books with the move of more software to the web. Now every application needs to build its own component library more or less from scratch because the platform lacks a decent standard UI.

Design and fashion being cyclic, I wonder if in a decade or so we’ll see a return to interfaces with depth and character in the future instead of the grey flatland we have now.

lla Is an ls Replacement That Takes File Exploration to the Next LevelPermalink

lla by Mohamed Achaq:

At its heart, lla is more than just another ls replacement – it’s a thoughtfully crafted terminal file explorer that transforms how developers interact with their filesystem. Built with Rust’s performance capabilities and designed with user experience in mind, lla strikes a careful balance between power and simplicity.

Our journey began with a simple observation: the daily ritual of file management often requires juggling multiple terminal commands to gather the information we need. Inspired by Raycast’s revolutionary approach to application management on macOS, we envisioned a unified solution that could bring the same level of integration and convenience to the terminal.

The result is lla – a tool that starts with familiar file listing capabilities but expands into a comprehensive file management platform through its extensible plugin system.

lla -l run in a terminal. The file listing includes permissions, size, last modified, user, group, and the file name. Colours are used to highlight the different parts.
lla -l run in a terminal

lla joins a slew of other alternatives to ls implemented in Rust, such as exa (unmaintained), eza (exa fork), and lsd. Most of these improve ls with more human friendly default output and additional features like icons and built-in tree views.

lla takes the ideas of these other tools and turns ls into a full blown application with features including:

  • Long, tree, table, and grid views
  • Git Integration
  • Timeline view
  • Storage analysis
  • Smart search
  • A plugin system

lla publishes releases for Linux and macOS, which suggests it should work on most POSIX systems. In contrast, lsd and eza also support Windows.

lla -G run in a terminal. The file listing includes information about the git status of each file: name, commit, author, last changed, status.
The lla git view.
lla --timeline run in a terminal. The file listing is chunked up by today, yesterday, last week, last month.
The lla timeline view.
lla -S --include-dirs run in a terminal. The output is a treemap ordered by the largest items in the directory hierarchy.
The lla storage view.

Personally I have ls aliased to lsd. I used exa for a long time, but switched to lsd when exa became unmaintained. I like that the lsd command line interface is pretty true to ls, which keeps my decades of muscle memory happy.

The Last Two Years of Servo DevelopmentPermalink

Manuel Rego Casasnovas:

As many of you already know, Igalia took over the maintenance of the Servo project in January 2023. We’ve been working hard on bringing the project back to life again, and this blog post is a summary of our achievements so far.

Nothing sums it up better than this chart:

A chart showing contributors and pull requests to the servo project. There is a big dip around 2021 and 2022, but the activity has resumed in 2023, 2024.
Nice to see the return of development activity.

I sometimes see people wishing there was a browser that was independent of advertising companies and big tech, implemented in a language that doesn’t result in a constant stream of CVEs. Servo could be that. The project exists, and is already a long way along. It just needs the support of more people and organisations. They’re aiming for US$10,000 per month and are currently sitting at US$4291. Mozilla won’t let us fund Firefox, but it is easy to donate to Servo, which I’m doing each month.

Linked List rendered in Servo running on Windows
Linked List rendered in Servo running on Windows.