Forward Momentum

Spring is finally coming, Mattrbld’s fourth birthday has come and gone—and it’s already been a quarter since the 1.0 release. I think it’s high time for a small project update.

First and foremost, however, I’d like to thank everyone who has been sharing and recommending Mattrbld to the broader web development community. The positive feedback and heartwarming messages that have reached me go a long way towards keeping my motivation high. It just feels good to have contributed something worthwhile to the world, considering the current state it is in. So thank you, everyone!

Moving Forward

I’m hesitant calling this update a 2025 roadmap, because unlike previous years, the next few goals I have set aren’t tied to a specific time frame. As I mentioned in the 1.0 announcement, I need to carefully balance how much time I spend on Mattrbld with my other responsibilities and my health, which unfortunately has taken a bit of a hit lately.

That doesn’t mean that I won’t keep working on Mattrbld, though! In fact, we have already had a couple of releases in 2025, fixing bugs and adding small quality of life improvements here and there. There’s even a fix for the long-standing field visibility issue live on the nightly version right now, which should make its way into the stable version soon.

Improving the Field Visibility Options

Fixing that bug made me reconsider some details on how field visibility should work, especially when used in combination with rows and column fields (dynamic content areas in other headless CMS). Currently, it’s not possible to control what fields are available as children of such a field. If the field is present in the schema, it can be added to content, regardless of its visibility settings.

I find that a bit counterintuitive, and some people have asked in the past whether they could control what fields would be available in a repeating field by another property in the schema, say a template property. I’d like to make that possible.

Also, I’ve been considering whether this would be a good time to introduce chainable visibility conditions, as only being able to show a field based on one other property in the schema might not be enough. However, this poses the risk of a breaking change in the schema format, so I’m not quite sure whether I’ll implement that soon.

More Powerful URL Templates

Mattrbld has a feature that allows generating internal links based on URL templates. This feature can be very useful for non-technical content editors who need to frequently link other content within a project, as they won’t have to guess what the correct URL for the link might be. Instead, they can simply select the file from a picker and the URL will be autofilled for them.

While the feature works well in its current state, I’ve long been wanting to expand it to support optional dynamic parameters and automatic index-page replacements. This would greatly simplify linking to the home page of a project and allow for things like custom URLs for certain pages, nested URLs based on a parent-child hierarchy and more.

Tackling Git LFS

One of the biggest issues holding back Mattrbld’s adoption for large scale projects is the lack of support for Git LFS. Git and binary files like images, videos and PDF documents have traditionally not got along well, as Git has to store the full file in its history when it is updated, instead of just the changed parts.

So as a media-heavy project grows, it becomes more and more time-consuming to clone it to a new machine—and thus import it into Mattrbld. To alleviate this problem, a new approach called “Git LFS” (LFS being an acronym for large file storage) was introduced as a plugin on top of Git.

When using this plugin, binary files are not directly added to the project repository, but instead uploaded separately, while a pointer file containing the URL of the binary file and some metadata is added to the project repository instead. This approach allows for the different versions of binary files to be downloaded on demand, greatly improving the experience of an initial clone.

Unfortunately, the library powering the Git integration of Mattrbld, Isomorphic Git, doesn’t support Git LFS, and it is unlikely that it will gain full support for it anytime soon. The good news is that I think Mattrbld doesn’t need a fully fledged implementation of Git to make use of the performance improvements it brings.

Projects making use of Git LFS imported into Mattrbld already work, but instead of showing media files, they show only the pointer files for binary data. If I could get Mattrbld to fetch the original files based on those pointers and then ensure to generate a new pointer when a new binary file is added to Mattrbld, we’d have an integration working for our use-case.

Even with this reduced scope, the feature is still a huge undertaking, but I hope I’ll be able to eventually get to it.

Improved Approachability

In the short term, I’d like to keep making Mattrbld more approachable. I realise that the current Quickstart Guide can feel daunting with it being such a long wall of text. I originally wrote it as a comprehensive overview for working with Mattrbld, at a time when I didn’t have that many screenshots of the software and my technical writing skills were still rudimentary.

So over the past few months, I have been gradually improving the Quickstart Guide by making the writing more succinct, removing some unnecessary commentary and adding screenshots where appropriate. I hope I’ll be able to publish it in the near future.

On top of that, I have long wanted to record a video (series?) on how to get started with Mattrbld, as there are likely some people who would find that more inviting than having to read through a long article.

Producing good video content isn’t easy, and as always, I want to do it right. While I do have some necessary equipment, I’m still figuring out the details on how to best approach it. Perhaps I should stop overthinking and just do it—we’ll see.

Last, but not least, I’ve been thinking of creating a pre-configured playground repository that anybody can fork/clone and use to play around with some features like the real-time previews and the content editor. With this, I’m still torn on whether to provide an invite link, which would allow interested parties to skip the onboarding entirely, or leave the repository “userless” from Mattrbld’s perspective.

With the first option, users would end up with a “test user” profile which they’d have to remove / switch off of before actually starting to use Mattrbld, introducing more friction on that end. The second option, however, has more friction upfront, because users would have to go through the complete onboarding process. And in either case, users won’t be able to actually sync any changes they made unless they’d fork the repository beforehand.

I’m sure there’s a good compromise somewhere in there, but I’ll have to think about it a little longer.

Slow, but Steady

As I’ve mentioned before, none of these plans have a fixed deadline at the moment. Rest assured that I’ll keep working on them throughout 2025 and that I’ll have my eyes on the bug tracker for any more pressing issues or feature requests as they may crop up.

In the meantime, I wish you all a happy spring and lots of fun building things! 🌱