Why I'm switching to Blade from Antlers for Statamic sites

As you probably know, I am a big supporter of Statamic: it is such an incredible content management system that has been built on Laravel, meaning I get an awesome authoring experience for my users, but also all of Laravel’s development extensibility at my fingertips too.

Out of the box, Statamic comes with Antlers, its own templating engine. And I’ve been using Antlers since I started working with the platform.

But with Statamic 6 around the corner, and after a few Statamic/Laravel crossover projects this year, it has had me questioning if Antlers is the right choice for me and the projects at Mity Digital, and whether Blade would be a better fit.

I’ve been building a site in Statamic 6, that will have a large Livewire component, purely in Blade. It has been a great opportunity to help provide feedback and fixes for the v6 update, as well as start from the ground up on a Blade project within Statamic.

The internal Mity Digital starter kit (and utilities addon) we use as a foundation for all our Statamic projects has a few to-do items to be built… and they’re on the schedule for next week, but will also be a more dramatic rebuild from Antlers to Blade, and become our starting point for Statamic 6 sites.

And here’s why I’ve decided to make the switch for Mity Digital projects.

Yep, I use PhpStorm – and you may use (and love) VS Code. And we can all get along. But the fact remains, the incredible Antlers toolbox that is available for VS Code does not exist for PhpStorm. So there’s no up-to-date syntax highlighting; no reliable code auto-complete, no code formatting.

I’ve experimented with VS Code, but you know what, PhpStorm just works out of the box, and I like it. So I’m not looking to switch IDE just for Antlers… but given other parts of my work is in Blade, having these features is a great win.

I’m the Head Code Monkey at Mity Digital. Yep, I write code. And we’re a small team. And we have fun job titles because life is too short to be that serious.

Since 2024 we’ve been reviewing how we build our projects, and have made decisions and changes to our chosen tech stack.

Earlier projects have been written with Inertia and Vue (and Vuex and Vue Router before that), and this has been great: but for a small team, there is additional overhead in maintaining not only a Laravel backend, but also keeping working with Vue and the way it works (and evolves). With a small team that becomes an expensive use of time.

And yep, there’s the argument for the right tech for each project. Definitely. But also what is the point, in a small team, to be jacks of all trades and masters of none? Are there changes we can make that can help with productivity, improve workflows, and be happier developers?

Yep, and we’re making those changes now.

This year we’ve been starting new projects with Livewire, and have been really happy in that space. Sure, there’s a mental model to work around with regards to the Inertia/Vue vs Livewire switch and the way they work (and how you work with data), but a simpler tech stack makes it easier to keep your head in the game. Which leads to…

That simpler tech stack leads to minimising the mental context switching, especially with multiple frameworks and languages to keep in your head.

Inertia… Vue… Livewire… Antlers… Blade… Alpine…

By switching Statamic projects to Blade, that list is halved. Instantly.

This allows me to keep my head in the one area for longer: Livewire (then through association, Blade) and Alpine.

I truly do love Inertia and Vue – and the latest advancements that the Laravel team are producing, like Wayfinder, are so exciting – but also working with Blade for Livewire apps, and now extending that to Statamic means I don’t need to switch between Antlers and Blade and Vue – it can now just be Blade.

This helps keep me mentally in the one place, whether it is a standalone Livewire app, or a public-facing website with Statamic that has some Livewire components (or even just a standard Statamic site), the tech stack remains the same, and the context switch becomes minor.

When you build a Livewire (or plain Laravel) app, you have a folder structure to follow. Well, you should anyway.

But in Antlers, because it’s not Blade, we’ve created a folder structure for our views that works the way our sites get built in Antlers.

And it works really well… for Antlers.

But when an Antlers-based Statamic project needs to use Livewire, it gets a little more complicated.

In a Livewire app, my components live in the components folder… but in my Antlers/Statamic projects, that folder exists for template-based components that aren’t actually Blade components like you’d expect. 

And then what about the button partial I created for Antlers, that now should really be a Blade component so I can use it in Livewire? Where is that file now stored? A partial, or a component? And then extensions… yeah it gets overwhelming and unnecessarily complicated.

This goes back to the previous point: minimising context switching.

And in case you’ve missed the obvious, Livewire is such an incredible front end addition to your Statamic site. It is a perfect fit to help make a public website come alive without needing to build your own API endpoints (and everything else that goes along with it, especially for POST routes). We’re using it increasingly more in our Statamic sites to help sites be more than just a page – it is like they were made for each other..

With Blade, your components are just that. Components. Whether it is a Laravel app or a Livewire app, components have their clearly defined home. And when a Blade-based Statamic project grows and requires some Livewire, the folder structure is already set up for the Blade world, and Livewire just slides in so nicely. 

With Antlers, we’ve made up a folder structure that works for our projects, Statamic and the Antlers ecosystem. But it’s made up, opinionated but does make loads of logical sense for the Antlers space.

We already have a button component written in Antlers… but it can’t be called the same was as a Blade component when we work in Livewire. So we either access it a different way (changing mental context unnecessarily and adding longer-term code confusion) or duplicating it as a Blade version (duplicate, enough said).

But in Blade, the button component is ready to go for any use case – a Blade template for Statamic, or a Livewire component: it becomes more seamless.

If another dev comes to look at it, there’s suddenly a bigger learning curve for them to understand the code base and what lives where. Where as working with the Blade approach to components and your views folder structure leads to…

Using Blade, following the Blade-conventions for everything in your views folder, makes it easier to on-board a Laravel-first dev to a Statamic project.

Do they need to learn Statamic? Yes.

But is it easier to get them up to speed and being productive if they already know Blade? Most definitely.

This isn’t just about on-boarding developers for an existing project: but also more importantly on-boarding developers to the Statamic ecosystem.

This is the big one. Massive.

Laravel teams probably already love working with Blade. So why not extend that to their Statamic experience as well?

They’ll get syntax highlighting in PhpStorm, streamline their tech stack, minimise context switching, a predictable views folder structure, and a faster on-boarding given they don’t need to learn Antlers.

That’s 5 pretty awesome reasons why Blade can be the right choice for Statamic – and yep, you see how that all summarised nicely?

But I’ll also miss some things… modifiers in Blade are not as sleek to use as they are in Antlers – but on the other hand, you get easier access to all of Laravel’s helpers like Str and Arr too 

The Statamic docs now have examples for both Antlers and Blade too – and moving forward, I’ll be sharing more on my Blade journey.

Don’t get me wrong: Antlers is incredible, and can be the right choice for working with Statamic. If you love Antlers, that’s awesome, and you keep being you because you pick the tech that works for you, and zero judgement coming from me. With Statamic 6 coming soon (with some nice Antlers quality of life improvements), there is even more to love coming soon.

But right now, for me and the type of work I do day-to-day, Blade makes more sense, even with those Statamic 6 improvements.

I’d love to hear what you think too – reach out to me and I’d love to share a chat over this topic – it is definitely a more divisive one!

I think there will be a few more Blade posts on the way too… let me know if that’s something you’re wanting to read more about too.

But whether you’re team Antlers or Blade, or PC or Mac, or Coke or Pepsi, let’s just all get along and be friendly about it too.