Idea Title
Use Handlebars templates for rendering in TYPO3
What is my idea about?
Ever wondered why you’re rebuilding existing Frontend templates using Fluid, repeating steps like structuring your templates, separating templates and partials in files, testing and quality assurance while the Frontend team did 80% of the work already – just in a different templating language? Stop wondering! Instead of rebuilding everything with Fluid, save those extra steps by using the Frontend team’s templates directly: Our extension “handlebars” enables TYPO3 to use templates in Handlebars format for rendering the Frontend of your page.
What do I want to achieve by the end of Q4 2025?
Gaining experience with this approach in several projects and teams brought up some new ideas and simplifications, so parts of the (already existing) extension need an overhaul to ease the team’s initial learning curve and overall usability and we want to reach compatibility with TYPO3 v14. In general, we aim to reach these specific goals in the upcoming Q4/2025: * Development of a HANDLEBARSTEMPLATE content object, whose configuration options are close to the ones available with the FLUIDTEMPLATE content object * Compatibility with well-known and established components, e.g. Content Blocks * Interoperability with third-party extensions, e.g. to enable Handlebars template rendering in third-party Extbase controllers * Documentation with a complete configuration reference and various guides to lower the entrance barrier, including an easy-to-understand “Getting Started” chapter, especially targeted for newcomers and beginners * Support for TYPO3 v14.0 (long term goal: Compatibility with TYPO3 v14 LTS)
What is the potential impact of your idea for the overall goal?
The implementation should enable cross-functional teams to work together more effectively and ultimately save time. However, our solution also aims to enable TYPO3 integrators who have already worked with Fluid & TypoScript to use an alternative templating engine that is easy to use and has a similar configuration structure as the familiar Fluid template rendering. It should enable continuous parallel rendering of Fluid and Handlebars templates, which is generally possible thanks to modern, established interfaces for template rendering in TYPO3. Thus, EXT:handlebars can also serve as a “showcase” for the use of an alternative templating engine; however, we do not treat it as a replacement or alternative to Fluid, but rather as a supplement to the established template rendering in TYPO3.
How does your Idea align with the strategic goals for TYPO3 v14.
It makes long term support and maintenance easier – eliminates the need to keep Fluid templates aligned with Frontend team’s changes and bugfixes. The simplified workflow reduces time spent for rebuilding, testing and debugging templates, supporting customer and agencies financial success.
Thanks a lot for the idea! I didn’t know that there is a real usage of handlebars in the PHP world as template engine?! However I wonder if it would not be more logical to use twig (from symfony world) or maybe even blade (from laravel)?
Other templating engines like Twig or Blade are of course a good alternative, especially because they are written for PHP and are tailored to the special use cases PHP provides. There’s already GitHub - SomeBdyElse/typo3-pti (with an available Twig adapter), which acts as prototype for integrating a various set of templating engines in TYPO3. We plan to provide a Handlebars adapter for EXT:pti as well, in order to provide full compatibility and flexibility for TYPO3 integrators, and to enable them to choose their preferred integration method.
First of all, both as a maintainer of Fluid and also personally, I want to thank you for this idea submission. I see this project both as a good testbed for the Core APIs related to templating and as helpful competition in the ecosystem. It will be very interesting to see how many people are interested in this and are willing to (partially?) switch templating engines.
I have a few points that would be interesting to me, and I think also to other people that potentially support this with their vote:
Do you already know which parts of TYPO3 you can cover with your approach? And are there any known shortcomings, for example in Extbase? Which leads to my next question:
Are there any parts of the implementation where you already have a feeling that a change in the Core might be necessary to provide a solid integration?
Do you plan to cover the most common ViewHelpers, like URI generation, image rendering or form elements?
From my point of view, it wouldn’t be necessary to have clear answers to all of these questions yet. I just want to get a feeling how “certain” you are of the scope. I think the money is also well spent if there are still areas where some exploration is necessary, as long as we know that beforehand.
thank you for your reply and your kind words, which motivate me (and us) to continue our work in this area. Let’s talk about you questions
Do you already know which parts of TYPO3 you can cover with your approach? And are there any known shortcomings, for example in Extbase?
In general, we want to cover as much areas as possible – in short: Mostly everything, which is also renderable by Fluid. As you’ve written, the extension should also demonstrate the flexibility of TYPO3 + Fluid and its available interfaces which makes integration of an alternative templating engine possible.
That means:
Everything related to FLUDITEMPLATE rendering should also work for HANDLEBARSTEMPLATE.
Template views of Extbase controllers (own controllers and third-party controllers) should be renderable by Handlebars.
Forms delivered by the Form Framework should be renderable (this is a long-term goal, as it turns out that the Form Framework is less flexible in this case).
We’re also testing out rendering of backend module templates with Handlebars, but we consider this a non-recommended way, since backend modules are normally not part of the template stack a Frontend developer would provide.
Are there any parts of the implementation where you already have a feeling that a change in the Core might be necessary to provide a solid integration?
With TYPO3 v13, most templating-related parts are already covered by very good, descriptive and easily adaptable interfaces. However, we found that integrating another templating engine to existing (third-party) Handlebars controllers turns out to be not that easy as expected (although we currently have workarounds in place, we’d like to ease this integration path a little bit and try to play possible implementation changes in Extbase backe to TYPO3 core, if possible). As mentioned, the Form Framework is another candidate where the current implementation might be hard to tackle.
Do you plan to cover the most common ViewHelpers, like URI generation, image rendering or form elements?
Yes, we plan to provide some sort of compatibility layer between Handlebars helpers and Fluid view helpers. Since the extension is built close to Fluid’s implementation, we don’t see too much issues here, but especially need to find good implementations for Extbase-related view helpers.
To sum it up: We always have an eye on Fluid’s development process and try to implement Handlebars features as close as possible to the ones that exist in Fluid and TYPO3 core. Switching between Fluid and Handlebars should be as easy as possible without too much “specialities” between the implementations.
