Filed an Issue

This is mostly reproduced from a Github issue I created for the new Forage WordPress theme I created. I’m thinking out loud whether or not to support a new branch with plain ‘ole PHP instead of the Blade syntax.

Laravel Blade has some notable features that help PHP developers move faster. Here are a few reasons to keep using it:

(quickly generated by ChatGPT, with edits and additions by me)

  • Layout Components: Blade offers the @component directive for defining reusable components, such as navigation menus, alerts, or forms. This promotes encapsulation and reusability for components containing HTML, CSS, and JS.
  • Escaping by Default: Blade automatically escapes output by default, helping to prevent XSS (Cross-Site Scripting) attacks. This enhances the security of your application by reducing the risk of injecting malicious code into your HTML. While PHP provides functions for escaping output, Blade handles this automatically, reducing the likelihood of accidental omissions.
  • Template Inheritance: allows you to define a base layout with placeholders that child views can fill in with their own content. This enables a more structured and modular approach to building views, reducing duplication and promoting code reusability.In other words, PHP would require explicit includes everywhere for PHP files to work with each other. Blade uses hooks like @yield as placeholders to work with various functions like @section.@yield('content") in the base file would render @section('content") in the child view file, such as page.blade.php`.
  • Control Directives: Blade provides convenient directives for common control structures, making it easier to express conditional logic and iterate over data.Example@if () as plain PHP would need PHP tags, looking like <?php if () ?>. Essentially, it’s more verbose to use plain PHP.
  • Concise Syntax: Blade offers a concise and readable syntax for common tasks such as echoing variables ({{ $variable }}), control structures (@if, @else, @endif, etc.), loops (@foreach, @for, @while), and more. This makes Blade templates easier to write, understand, and maintain compared to raw PHP embedded within HTML.
  • Template Comments: using {{-- This is a Blade comment --}}, which is not rendered in the final output.
  • Include Statements: In addition to @include, which mostly mirrors plain PHP, Blade also provides the @includeWhen and @includeFirst directives for conditional inclusion of templates.

I attempted to order the above in the order of importance, with the top few being quite more efficient than plain PHP.

My overall observation is that Blade should truly be considered if you can think of good use cases for adding components rendered by PHP. At some point, it might be less useful as Web Components find their way into the WordPress ecosystem.

Additionally, the auto-escape and inheritance for Blade is pretty great for efficiency. The benefits of these features are quite convenient.

The rest are just nice little sprinkles to clean up PHP. Nice, but not necessary.

If I review everything I’ve used with Blade, I really don’t think I have any real needs yet for PHP driven components. All the rest of the bullet points could easily have been regular PHP in my own personal work flow, but I’m really only using themes on smaller sites that don’t have a lot of complexity.

If Blade is removed from any project, you likely have the option to completely remove a dependency on Composer as well as some application methods to render the Blade syntax into PHP. I can also see this argument for those who prefer to stay as close to the original languages as possible.

At some point in the near future, decisions to support Laravel Blade might come down to whether or not you want a build step to compile a language. There’s a potential future approaching where the browser contains so much power that build steps can once again become optional. That’s a very interesting future!