Anyone else using Twig instead of blade?

I was never been a big fan of Twig, honestly. I feel that in the interest of making a syntax readable by non-programmers and programmers they just created something that managed to be neither. I think that most of twig's more "advanced" functionality would be better off in a presenter. I can't say I miss it that much.

That being said, I'm open to working with it if some feature I'm not aware of is especially impressive.

I'm curious if there is some syntax or feature of Twig that you're missing in Blade? I've never felt a need to switch it out.

I love Twig, for some reason much better then Blade, it feels a bit more mature. It has some easy filters and loops are better. Forelse is recently added by Blade, but things like loop variables with the loop.index/first/last etc make it just a bit easier. And of course phpStorm support, but that's just added for Blade.

I personally think Twig is a bit cleaner than Blade in syntax. Also the way it handles auto-escaping is better. It also forces you to think a bit more about seperating the logic from the templates, because it doesn't just allow all PHP code.

Twig has also wider support as the main Template engine for Symfony but also announced support for Drupal and Magento. I think it would have been better if Laravel embraced Twig, but I guess it's easier to learn. But Blade is essentially just a little different syntax then native PHP, not much added value.

And if you're thinking about trying Twig, just look at rcrowe/TwigBridge version 0.6.x, it supports everything Blade does (view composers/creators, shared variables, facades, helpers etc)

"I personally think Twig is a bit cleaner than Blade in syntax. Also the way it handles auto-escaping is better. It also forces you to think a bit more about seperating the logic from the templates, because it doesn't just allow all PHP code."

I think what Barry says here sums up why I fell in love with twig.

Everything you can do with blade you can do with twig or bare php, it's not a matter of having more features or not being able to do x or y but really really keeping php and its logic away from your views while keeping the syntax as clean as possible.

I am not fond of laravel html helpers, I think they hide a lot of html/view logic away from my views, I use twig macros instead and while I do the same thing with similar code I control how html is generated inside my views and away from my php app. e.g for inputs with labels wraped in a div.

I feel that laravel does not do a lot with blade to help us keep view logic inside our views. Macros could be added in blade to help a bit here actually.

Presenters do help a lot to keep our views clean however I have seen a lot of cases where people abuse presenters and move a lot of presentation logic away from the view and inside php code which should really be in your views.

The direction development are going are leaning more towards Single Page Applications where we leverage the plain old html instead. So I dont think the focus should be on php template engines.

The only thing I miss in Blade, are the loop variables available with Twig, otherwise Blade is perfect and so easy to extend!

Good news for the Twig lovers, rcrowe/TwigBridge version 0.6.0 has just been released, with many improvements from 0.5 and from my laravel-twigbridge :)

nice to hear that barry, been using 0.6 beta for some time now

do any one use yaapis/Theme to use multiple themes on one application with twig ?

If twig is so great why can't I use static Auth methods?

Switching to twig has completely destroyed momentum on my personal project. I am only not switching back out of pure stubbornness.

... I don't even like blade to tell the truth. Maybe I'm missing the whole point but why not just use PHP in the views? What bad things will happen?

There is a real good Template language out there that has been around for a long time and the only requirement for using it is making sure you sanitize your data like in the controller just before an update or create. It's called HTML with php. Beats any other Template language conceived by a human being.

So if you are genuinely interested, this is my write-up: https://medium.com/barryvdh/comparing-blade-and-twig-templates-in-laravel-187fde7fcac9#.51rao3hr7

@mikelovely unless you don't sanitize data being display, nothing bad would happen. Twig and blade both compile down to plain old PHP + HTML anyway.

There is noting you can't call in TWIG! Just read up on how to do stuff instead of giving up! You simply expose the facades you want to call. So you can expose your services or anything you really want or functions or anything really!

Been using twig together with Laravel and honestly i can't think of living without twig! Makes your code ALOT cleaner and give you a lot of helpers that you down get with blade. Just check the official twig documentation on the filters and stuff available.

Of course if you don't feel like using twig then don't push yourself! if you get to know twig thought then you will definitely love it. I always thought of using a tempting engine is pointless but when you get to a certain point that you feel your views code is littered with logic then you definitely need to stand back and rethink on using a template engine. blade is fine as well, but twig keeps things cleaner and simpler.

P.S. I feel that blade is catching up by recently introducing service injection! https://laravel.com/docs/5.1/blade#service-injection in twig you simply expose the facades to your services if you want and you can call it for anywhere!

Looks like Twig just messes up the code by putting in way too many features. I would source those to the controller or javascript.

Actually, Twig does the opposite. It enforces some restrictions to prevent too much logic in your views.

How will you explain the macros for example then? Or filters.

Macros are an easy way to reduce duplication and are easy for recursive/repetitive html, eg. nested menu items. You don't want to generate html in your controllers, just the data tree, and render with a macro.

A filter is usually for presentation only, eg. format a date in a certain way, limit a string for x chars, uppercase it etc.

as barry said macros and filters help you present your data, they belong in your views!

I love both about twig! actually 1 thing i hate about laravel and blade is that i see many packages that put a lot of html presentation into packages. These are all stuff that are supposed to be in your views! with twig you simply define the macros in your view so you have 0 html code in your controllers or services.

Actually laravel's own pagination code is damn hard to customize since it lives inside php code. if this was done using macros then you would have code sitting in your views that you can easily customize. I reported this to Taylor a while ago and he said he would look into it but I am guessing it's not in his priority to move presentation of the pagination into the views where it belongs.

One thing that twig helped me is have 0 html code in my app, if its html code then its in my views, and only in my views.

Interesting. What about Vue components and templates, how do you handle that?

That doesn't have much to do with the Twig/Blade/plain PHP debate.

Well, it's still a HTML and would be nice to import it from somewhere in case I put it in a package and want to deploy it but let the user edit the HTML

I love Twig and that's the first component I swap with a fresh Laravel install (shoutout to rcrowe/TwigBridge for his work). As mentioned earlier in this thread, Twig really forces you to remove any business logic from your template and I find the syntax cleaner. It's also used by many other frameworks and apps/cms and is really easy to integrate: one less syntax to learn or remember!

Just my two pence - I hate Twig with a passion. I've been doing some work with October CMS and using Twig is just awful.

@Barryvdh PyroCMS uses your Twig bridge and the whole setup is wicked cool. But Pyro does support Blade / PHP views as fallbacks and I was wondering if you had any thoughts on a way to map custom twig functions to Blade. In our case - once the entry point, the function, is taken care of we're working with objects / presenters anyways. It's just that initial connection. Admittedly I haven't looked into it too terribly much on my end but something that's been rattling around in my mind for a while and thought you might have some insight.

Cheers!

@RyanThePyro I'm not really sure what you mean. You mean the built-in functions? Or other Twig Extensions?

Most Twig functions I use are either built in (which aren't easy to open up to Blade) or just pointing to Laravel classes. Or just function calls directly.

I would just write your functions separate (eg. like a Str class) and expose that through a Twig extension. Or just plain functions which you add to the config. Or an object you can pass as global variable, which can be used the same in Blade as Twig (like user.prettyName() or $user->prettyName())