# BladeOne: the Blade template engine as one dependency-free PHP file

> BladeOne gives you Blade-style templates, template inheritance, components, stacks and pipes without Laravel and without Composer dependencies, in a single PHP file. The author is candid that PHP 7 support is on its way out and that dynamic Blade components are deliberately unsupported.

**EFTEC/BladeOne** — The standalone version Blade Template Engine without Laravel in a single php file and without dependencies

- Repository: https://github.com/EFTEC/BladeOne
- Website: https://www.escuelainformatica.cl/
- Stars: 830 · Forks: 124
- Language: PHP
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/eftec-bladeone

## One file, no dependencies, no framework

BladeOne is described as a standalone version of the Blade Template Engine that uses a single PHP file and can be ported and used in different projects, allowing you to use Blade template outside Laravel. That is the whole idea. BladeOne takes the compiler and the runtime and puts them in one file you can drop into a project, with no Composer dependencies of its own. The repository layout backs this up. The package ships lib/, examples/, tests/, a phpunit.xml and a composer.json, and the documentation is split across separate markdown files per feature, BladeOneCache.md, BladeOneHtml.md, BladeOneLang.md and BladeOneLogic.md, so each subsystem is documented on its own rather than in one growing manual. The repository also carries an AI_GUIDE.md at the root, which is a signal that the project is being maintained with tooling in the loop rather than by hand alone.

## The feature set is Blade's, minus one deliberate omission

The documentation index lists the template tags Blade developers already know. There is a page for template variables, one for template inheritance, one for template components, one for template stacks, one covering template assets, relative, base, current and canonical links, one for calling methods from a template, one for template logic, one for the template loop, and one for template pipes, which are the filter syntax. Alongside those there are pages for custom controls, for the methods of the class, for injecting logic before the view through a composer, and for extending the class. That is a substantial surface. The one explicit gap is stated in a callout near the top of the README: dynamic blade components are not supported, with the reason given as performance purpose, and the note adds that custom features aimed for Blade are not supported either, while everything else is. So the trade is deliberate. You get the compiler and the runtime, and you give up the feature that requires per-request class resolution, which is also the feature you are least likely to use if you are not running a full framework.

## The Twig comparison is measured, and the test is narrow

The README includes a comparison table with Twig, and it is worth reading the methodology rather than just the verdict. The table reports first time compile, first time memory, overload first time, second time and second time memory. For BladeOne those figures are 1962ms, 2024kb, 263, 1917ms and 2024kb, and for Twig they are 3734ms, 2564kb, 123, 3604ms and 2327kb. The README then says what it was tested: two features, the ones that are the most used, tested with an array of 1000 elements and tested many times. So the claim is roughly half the compile time of Twig with a comparable memory footprint, on a two-feature benchmark with a large array. The table also carries a spoiler line saying Twig is slower. The numbers do support that within the stated scope, but they are not a general statement about template engines, and the overload figure goes the other way, 263 against 123, which the table does not explain. A fuller write-up lives in the project wiki page on the Twig comparison. Treat this as one author's benchmark rather than a settled result.

## Getting it means a package on Packagist, not a build step

There is no build step and no compilation to run. The project is published on Packagist as eftec/bladeone, and the README's badges record the requirements: composer greater than 1.6, PHP 8.1 or later, and a PHP 8.x badge alongside. The repository also carries an examples/ directory with a set of runnable scripts, which is where the fastest orientation is. The files named in that directory tell you what the library is meant to do. example_composer.php and example_composer2.php show the Composer-based integration, example_extends.php and simpleextend.php show subclassing the engine, example_customcontrol.php and example_customcontrol2.php show custom controls, examplerelative.php and the relative1/ folder show relative path handling, the lang/ and lang2/ folders show the localisation support, the service/ folder shows the service layer, and compilefile.php plus the compiled/ and compiles/ folders show the compile cache in use. The docs/ directory holds the generated documentation, and the readme.template.md at the root is the template used to produce the README, which tells you the README itself is generated rather than hand-maintained.

## The maintenance story is the author being direct about PHP 7

The most distinctive section of the README is not a feature list but a statement of intent. It opens with a section called the situation so far, dated 2026, and argues that it makes little sense to continue using PHP when C# works on Linux too, and that C# brings features including MVC out of the box. Then it explains the practical consequence for this library: the library started with PHP 7.0 and now the target is PHP 8.4, PHP is not adding features that could change this library drastically, so there is little to change. The conclusion is that it is a matter of time until PHP 7.x support is killed. That is a maintainer telling you the project is in maintenance mode with a defined end point, not a project in active development. The versions tell the same story. The 5.0 release is dated 2026-10-03 and matches the last push, while 4.19 and 4.19.1 are from July and September 2025. The repository is not archived, and there is a CHANGELOG.md at the root, so the history is documented, but a major-version bump from 4 to 5 with a large gap between 4.19 and 5.0 is exactly the kind of change to read about before upgrading.

## A custom licence you have to read yourself

The licence is recorded as a custom one that GitHub cannot classify, with a LICENSE file at the repository root. That means the terms are whatever the author wrote, and they are not necessarily MIT, BSD or Apache. If your organisation runs a licence allowlist, this repository will not pass an automated scan and will need a human to read the file. The distinction from the many PHP libraries with an MIT badge is worth making explicitly, because a single-file template engine that people copy into their own project tree is exactly the kind of dependency whose licence terms you want settled before it ends up in a commercial codebase. The README does not summarise the terms anywhere, so there is nothing to evaluate from the documentation alone. That is not an accusation, just the practical shape of the gap. The project home listed in the repository metadata is escuelainformatica.cl, and the badges link to the Packagist package and the wiki rather than to a separate marketing site.

## How the project wants to be used

The support note at the end of the README is a small thing that says a lot about how the maintainer intends the project to be used. For inquiries, doubts and bug reports you can open an issue on GitHub, and you are asked not to email the author or send a private message directly with questions or reports. You are welcome to reopen a report, and the author says he will try to answer all and every question in his limited time. The contributing section of the project page lists a set of example applications built with the library, including a ticket system, a cupcake site, a search example and an editable grid example, each in its own repository, which doubles as a set of working references for the feature set. There is also a separate BladeOne Manual in the wiki. The overall shape is a mature, self-contained library with a long feature list, a single maintainer, a manual, and a stated intention to keep the codebase small by not chasing PHP changes. That combination is coherent, and it is also the honest reason to check the version numbers before you depend on it.

## Conclusion

Adopt BladeOne if you are building a PHP application without Laravel and you want Blade syntax, template inheritance and components rather than plain PHP templates, and you can live without dynamic Blade components. Do not adopt it if your application already runs Laravel, since that is the case the original engine already covers, or if you rely on dynamic components, which the project states are unsupported for performance reasons. Before you commit, check the version on Packagist against the 5.0 release, confirm your PHP version is 8.1 or later, and read the custom licence in the LICENSE file, since it is not one of the licences GitHub can classify.

## FAQ

### What is BladeOne?

It is a standalone version of the Blade Template Engine that uses a single PHP file and can be ported across projects, letting you use Blade template outside Laravel. It is published on Packagist as eftec/bladeone and requires PHP 8.1 or later.

### Does BladeOne support dynamic Blade components?

No. The README states that dynamic blade components are not supported, with the reason given as performance purpose, and that custom features aimed for Blade are not supported either, while everything else is.

### How does BladeOne compare to Twig?

The README's table reports a first compile of 1962ms for BladeOne against 3734ms for Twig, with memory of 2024kb against 2564kb, and states the test covered two features with an array of 1000 elements, tested many times. The overload figure goes the other way, 263 for BladeOne against 123 for Twig.

### What licence is BladeOne released under?

A custom licence that GitHub cannot classify, with the terms in the LICENSE file at the repository root and a badge pointing at the project site. The README does not summarise the terms, so the file itself is what needs reading. The newest release is 5.0 from 2026-10-03.

## Sources

- [EFTEC/BladeOne on GitHub](https://github.com/EFTEC/BladeOne)
- [Issues](https://github.com/EFTEC/BladeOne/issues)
- [Project website](https://www.escuelainformatica.cl/)
- [README](https://github.com/EFTEC/BladeOne/blob/master/README.md)
- [Releases](https://github.com/EFTEC/BladeOne/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eftec-bladeone