Why I find boilerplates stupid

I have been integrating web sites in TYPO3 since about 2005. When you are at it for such a long time, there are some questions that always repeat themselves.
One of the most asked questions is: What is in your standard package? Do you have an agency package? What do you use as boilerplate?

I have to admit that I really liked the idea of a boilerplate package for many years. Strangely enough, though, I never managed to put together a package of my own and my few approaches never made it anywhere near product maturity.
My latest attempt is currently in on github, but I caution, it's not ready and the typoscript included is only for special page types.

Nonetheless, I complied with a colleague's recent request and, with the latest project in mind and the challenges of recent projects, attempted to generate code that is a help and not a nuisance.
I capitulated after 3 hours.

I started with TYPO3 version 3.6.
Since this time so many things have changed and a package, an agency extension or a boilerplate must inevitably grow with each new version.
Unfortunately I don't have the time and especially the desire to update some crazy, maybe cool, functions over and over again and in the worst case to make them available for different versions.
Probably most of us know TYPO3 installations that can't be updated because the super-fancy-with-so-many-functions extensions can't be updated.
My approach to this is more pragmatic:
If I need the super-function from the last project, it's usually much faster to copy&paste it over.
Especially because the cool super function usually needs some customization.

Butter by the fishes

Kickstarting a TYPO3 project takes 30 minutes. A page tree, header and footer navigation should be integrated in another 3 hours (When the frontend is ready)
A profile card with photo and text needs - well, that depends on the project. Does the card consist of free text? Does the data come from tt_address? Do we need a custom extension? How much boilerplate code do I have to fight against to integrate the design?
A boilerplate should help us - but where?
A navigation consists of 8 lines typoscript + fluid template with custom HTML.
OK - 8 lines for the boilerplate. (did I already mention copy&paste?)
The problem is: What do we need to quickly integrate a design and go live with it?

know your tools!

My favorite feedback is: "When I start the project, I get an error".
Guys, it doesn't have to be like that. At 20+ years old, the toilet paper shouldn't be an issue anymore ....
Seriously. We are web developers! We make the internet! The basics have to be right.
And if not, then go to night school, get detention! And don't say: My boss doesn't give me the time. (Unless you are still in training.)
So the motto is: Find it - Fix it.
I spare myself further polemics here ...

A really fast development environment

The other side is a really fast development environment. So a setup that speeds up the development.
Tools which shorten or reduce turn-around times.

And above all a toolbox that closes the gap between frontend and integration.

This is where time really gets burned!

First, the frontend developer implements a design in HTML. Here template engines like pug/jade or Handlebar/Mustache are used.
First an immense effort is made to simulate authentic content or Ajax accesses.
The integration is then done by splitting the existing sources or compilations and integrating them into Fluid.
Javascript and CSS are copied directly into the sitepackage as a compilation.

And now it starts to grate. The backend developer, for reasons known only to him, change an endpoint for an Ajax access.
This has to be addressed back to the frontend department, there the simulation is adjusted in the frontend and the integrator ports the change (via copy&paste) into the TYPO3.

Yes of course - how else, many developers say here.

What nonsense.

Why don't all competences work together and interlock?
Why can't a frontend developer think a little bit outside the box and consider whether an HTML structure can be implemented in a CMS at all?
Why can't an integrator or backend developer write 8 lines of Javascript to implement an Ajax access?
And why is it necessary to do so much copy&paste for integration?

How about a development environment where frontend, integrator and backend work together? Really together, as a team! And if the integrator sees the code from the backend, he might have a good tip for the frontend.
Or the backend developer learns, by the way, how to make a nice Ajax access.

standalone or fluid

With t3-build it is possible to program either with a small template engine in complete frontend as standalone version.
The integrator then uses exactly the same files and develops them further in fluid-template.
Alternatively it is also possible to skip the standalone step and use TYPO3 as template engine and content source.

Everyone has direct access to the real sources

Since all developers involved develop in the same repository and use the same build process, each can view the other's sources and optimize them if necessary.

Faster customization, fixes and enhancements

This is such a great case. The customer says, "Please make the gap wider here"
Average implementation: 5 days!
Average customization: 2 lines!
If the customer is unlucky, the frontend developer is on vacation right now.
Or the integrator. Then the customer may have a screenshot, but live is a long way off.
This is really uncool. That's why t3-build offers a build process that can be used in all stages up to deployment.

For all impatient:

Check it out

Unfortunately I didn't have the capacity to update the documentation yet.

The current release has two proprietary tags: standalone, fluid - This can be used to wrap content.

For all others:

Stay tuned - more info will come here and in the project above.