Blade vs Antlers (from v3.3)

[jasonbaciulis]

TL;DR. Is it just a matter of preference at this point?

Blade now has better support in Statamic and Antlers got the missing features of Blade. I lean towards Blade because I think for some projects that are more integrated with Laravel, it makes more sense.

Or am I missing something? Are there some objective advantages of Antlers?

[duncanmcclean]

Yeah, I'd say it just depends on what you're more comfortable with.

Before 3.3, you did lose out on quite a bit of functionality going with Blade but I don't believe that's the case at all. Maybe someone else with more Blade experience can comment though.

[yabdab]

I am interested in this as well. DO all the same "antler" syntax work with blade as well?

[jasonvarga]

They are different languages so no, not everything works the same.

But, you can use the Statamic tags and modifiers:
https://statamic.dev/blade#using-tags-with-blade
https://statamic.dev/blade#using-modifiers-with-blade

[Christophvh]

I'm starting to wonder if removing Antlers might be better for statamic & the developers behind it.

• 1 unified templating engine.
• All documentation is about 1 engine
• Everybody in the laravel community already knows it
• All that extra development effort to get antlers working is not necessary anymore
• Blade has a huge community that helps with testing/maintaining it.
• Most of the things that antlers does well can be made into Blade directives + would maybe get pushed into the laravel core.
• ...

[Christophvh]

@jasonvarga I understand that, my point is not if Antlers is viable because it clearly is. My point is, with your small team it seems crazy that so much development effort is put into a templating engine next to one that works well and is integrated into Laravel. It made a lot of sense when Statamic was a separate install, but now it's a Laravel package. If people want Antlers it can be an external package that the lovers of antlers can maintain for example. Just like Twig that can be used in Laravel with the use of a package.

And 'unclear' things can still be made into Blade directives. @list($foo) which works like antlers etc. Those can even make it into the blade core if a lot of people prefer it.

[jasonvarga]

If people want Antlers it can be an external package that the lovers of antlers can maintain for example.

We'd be the ones maintaining it, so potato potato.

[jasonvarga]

Also with this logic you could say Laravel should remove Blade because Twig exists.

[Christophvh]

Also with this logic you could say Laravel should remove Blade because Twig exists.

Not really. Taylor/Laravel is not maintaining the Twig package. They only make sure Blade is working. They have chosen 1 templating engine and stuck with it. Statamic currently has 2. But ok, pointless discussion if you guys don't agree, I just think it would help Statamic as a whole if 1 path was chosen.

[jesseleite]

Taylor/Laravel is not maintaining the Twig package.

Likewise, we/Statamic are not maintaining the Blade templating engine.

They have chosen 1 templating engine and stuck with it. Statamic currently has 2.

We maintain 1 templating engine (Antlers), but offer a few lightweight helpers for Laravel users who prefer using Blade instead 🙂

[acalvino4]

I completely agree with @Christophvh. The way I see it, Statamic could choose to maintain 0 templating engines, rather than 1. Obviously there is a sunk cost there (which of course was absolutely necessary to get the project running), but I really just don't think it is necessary anymore. I understand that many people prefer the antlers syntax to blade, but for those people (of which I am one), I would think it more worth Statamic's time to just maintain a twig integration, rather than a whole templating engine.

With the example @jasonvarga gave

{{ foo }}
  {{ bar }}
{{ /foo }}

while the syntax is leaner, it is less explicit about what is going on - does {{ foo }} output an element that wraps bar? Turns out no, it's looping through the variable foo and displaying bar for each iteration. Twig is much more explicit about this sort of thing while also avoiding @Directives and sticking with template-y syntax. Add to that the fact that it has a very large community supporting it (symphony, drupal, craft, and more) and it starts to paint a picture of a worthwhile path to invest in. I'd bet the migration of templates from antlers to twig would actually be fairly straightforward and could maybe even be automated.

After working extensively with ExpressionEngine templates (which share a number of similarities with antlers), I've experienced the confusion around interpreting template code that I articulated above, as well as the frustration of working with a templating engine that struggled to keep up with modern templating features and keeping things documented well. Now there are many reasons for this in EE, but one is the simple fact that they have a small team with a whole CMS to maintain, so their templating engine and associated tooling can only get so much investment.

Now, Statamic has done a remarkable job keeping up with Antlers so far (much better than EE did with their engine), but it doesn't change the fact that it's an added burden to a small team that could be spending their time solving new problems on the cms side (or even contributing to twig, if you really have the time), or the fact that even after the big antlers engine rewrite (which is a great improvement) twig is still slightly more feature robust.

Bottom line - I get that having a "{{" based templating system is preferable to blade for many (and prefer it myself), but I would think it a more sustainable long term path to just maintain a twig integration, rather than maintain antlers.

[acalvino4]

I mean, you do you.

And I don't think anyone would suggest doing it anytime soon. The path would be to first implement a twig integration, plan a migration strategy, and only then announce Antlers deprecation. Realistically, this wouldn't be completed until probably 2 years from commiting to the path. If the team just loves working on Antlers, as well as maintaining its docs and IDE integrations, then all power to you. But I would be interested to hear any other reasons why replacing it with twig shouldn't be the long-term path.

[ryanmitchell]

I think the only reason that matters is that it’s their product and they can make that decision 😀

[jasonvarga]

The path would be to first implement a twig integration, plan a migration strategy

This alone sounds like more work/effort than to just continue supporting Antlers.

I can't imagine the amount of complaints about its removal, and the support load involved in helping people convert over to twig or blade.

[acalvino4]

Like I said, long term path. I understand the pain of migrating and how people hate change. But in the 10 yr. mindset it would almost certainly be less work and make happier devs.

Regardless, I respect the work that you all do are really do find it to be of great quality. I just offer my thoughts for your contemplation.

[jackmcdade]

There's no reason why people can't use Twig already. It's just a view engine – I know a few people already have pulled in a composer package and used it. Removing Antlers – though maybe not an enormous project by itself — would cascade to tens of thousands of developers and cause them unnecessary work. It's just never going to happen, ever. Not while I still own Statamic at least. Plus I don't like Twig at all, and I don't want to hate using my own product. 😬

[robdekort]

For what it's worth. I ❤️ Antlers and prefer it over Twig and definitely Blade. The syntax is lean and super easy to learn. Jack has stated before that maintaining Antlers isn't even that much work (regex) and now John does a fantastic job with maintaining Runtime. Me and thousands of other people prefer Antlers and its simply part of the core product. I don't understand why anyone would want it removed so badly. Simply pick whatever suits your preference. Statamic already has the biggest feature set of any CMS I know plus it offers two templating languages. One tailored for devs, the other for frontenders / designers.

[acalvino4]

I articulated a couple reasons that I personally think Twig is a better choice than antlers. I could go on, but it's pretty clear that the maintainers are entrenched in their opinion (perhaps with a reason, though I haven't heard it...), so I don't see any point in arguing, especially when the points I already brought up don't seem to be addressed. The closest thing I have found is this, which has a few bullet points halfway down, that I find pretty shoddy reasons for maintaining a whole templating language of your own rather than unifying with a great tool the community has already created (in fact, I think those bullets are arguments for twig). I'll bite my tongue from anymore detail in hopes of not turning this thread into an argument.

[stuartcusackie]

In my case, I build Laravel projects that may or may not use Statamic - A lot of my projects exist long before a CMS is required. So my templates are already written in Blade and utilise Blade components. I had a frustrating introduction to Statamic 3.0 because of my Blade requirements. Things are much better now at v3.3 but I can't help but wish that as much attention is given to Blade as it is to Antlers.

For me, the most important thing is that my templating language works alongside the framework & development tools - Blade is powerful in this respect. Antlers make Statamic stuff easier but I find it makes Laravel stuff harder. I almost never see the need for an Antlers Modifier but I have ran into many Blade related problems.

This argument will likely go on forever and intensify as more Laravel-first developers start using Statamic. I know Statamic has to stay loyal to Antlers so I guess the only option is that it will have to continue to support both engines. I do worry though that Antlers is holding back Blade and Blade is holding back Antlers, and that someday Statamic may go in the opposite direction, e.g. a focus on Antlers components or something. If your choice of templating engine is truly optional then maybe Statamic should separate itself from Antlers to some degree, otherwise important architectural decisions might be made from an Antlers perspective. Saying all this though, things are good now and long may that continue.

Let me also say that Statamic is everything that I've always wanted a CMS to be and the developers have been top-notch with communication and improvements. I'm sure that Antlers is nice to work with. I might try to give it a proper go someday, but nevertheless I am tied to Blade, and so I feel like the argument for 100% Blade support is important.

[jackmcdade]

I appreciate your feedback. Thank you.

[Christophvh]

That is exactly why I made the statement. Our projects are primarily full web-apps built with Laravel and blade. Huge fan of statamic but adding Statamic to an existing laravel app is mostly a pain because of Antlers and the Blade 'parsing' still has a lot of quirks. Convincing my fellow developers that Statamic is amazing can be hard because the blade integrations has many little bugs. Also the docs have full focus on Antlers. SEO for example has a bunch of needed 'hacks' to work with the official SEO plugin provided by statamic. Full focus on blade seems very logical because the big laravel community. But again, that is a big switch and the everybody else seems to like Antlers so.

[robdekort]

Please report any issues you run into regarding Blade.

[nickpoulos]

Agree with all of the thoughts here 1000%. I have been waiting forever for a real Laravel-first CMS. For some reason, nobody seems to be able to get it quite right. I had really high hopes for Statamic with v3 now that it was officially a Laravel package. But going through the docs, reading these type of threads make me realize we are not there yet.

With Blade, Laravel has a template engine that the entire rest of the Laravel ecosystem uses. When somebody develops a Laravel application, 99 out of 100 times, they are using Blade + JS. Antlers was fine and probably necessary when Statamic was not coupled to Laravel but to continue to maintain and have them compete against each other is really ideal. The simple fact that there are numerous threads like this on the Statamic forums/GitHub -- asking which engine to use and when -- should make this decision a no brainer? Not to mention we now have to learn an extra template syntax just for Statamic? It is really strange to me that there is so much pushback.

The engines are NOT at feature parity. Depending which one you choose CAN determine what Laravel packages or other libraries from the ecosystem you can easily use. I feel like having developers need to hack together a bunch of stuff to be able to use popular packages alongside Antlers is a bit of an anti-pattern.

With a proper deprecation timeline/plan and solid upgrade documentation to move to Blade, I would think future versions of Statmic could really benefit and make a push to turn Statamic into the de-facto Laravel CMS.

[yo-mike]

Hey, I'm new here. I just thought I would chime in...

I'm interested in using Spatie's Laravel Comment package (Livewire). I've had a heck-of-a-time getting it to work w/ Antlers. I fear that Antlers might give me some additional issues in the future. I think I prefer Blade at this point.... not sure yet though....

[ryanmitchell]

Livewire definitely works better with blade

[jackmcdade]

Nothing wrong with mixing and matching.

…

On Nov 4, 2022, at 10:51 AM, Ryan Mitchell ***@***.***> wrote: Livewire definitely works better with blade — Reply to this email directly, view it on GitHub <#6189 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAK5QZG26FC5BVDMX4J4ETWGUPGRANCNFSM5YPNK73A>. You are receiving this because you commented.

[yo-mike]

Cool. This is they way ☝️.

I ended up using a blade layout (layout.blade.php) -> to a blade template (articles/article-detail.blade.php) for the collection.

From there I called a Livewire component to fetch my Collection (livewire/article-detail.antlers.php), and another component to fetch the comments package.

Thanks for the suggestion.

It's surprisingly easy to swap between *.antlers.html/php and *.blade.php