ProcessWire doesn't produce any markup on its own, nor does it provide a sophisticated template hierarchy out of the box. This is not a flaw, mind you, but rather a clever design decision: ProcessWire is unopinionated in terms of output generation, which is precisely why it's so well suited for so many different use cases.
If you take a peek under the hood of a vanilla ProcessWire installation, you'll notice that content for each page is rendered by a template file associated with said page's template: /site/templates/[template].php. This approach is what we call "direct output", and it's the easiest way to develop simple sites with ProcessWire.
Simplicity comes with a cost, though: the direct output approach is also not very scalable, and sooner than you know you'll be looking for something a bit more... advanced.
Output strategies to the rescue
If you've been developing sites (or software for that matter) before, you're no doubt aware that mixing code with markup and business logic with presentation logic is a bad idea, and will often result in an unmanageable mess — the not-so-tasty disaster commonly referred to as spaghetti code.
Most output strategies provide you with the means of structuring your template files in a way that keeps your concerns separate and minimizes code repetition. Here are some of the most popular output strategies for ProcessWire:
- Direct output. This is the default, out-of-the-box approach. Very simple — great for learning the basic concepts of ProcessWire and maybe even building your very first website, but doesn't scale well beyond that.
- Direct output with includes. Essentially the same as direct output, except that now you're splitting parts of code and markup into reusable include files. Simple and much more scalable than direct output, but still somewhat limited.
- Delayed output. In a nutshell this strategy involves defining content as (PHP) variables in the template file, including a shared output file (often called main.inc), and using our previously created variables to "fill in the blanks". Now we're getting somewhere!
- Markup regions. This is a built-in output strategy included with recent ProcessWire versions. Combines direct and delayed output, allowing you to populate markup into existing HTML using some custom tags, ID values, and/or data-attributes.
Additionally some third party projects introduce their own output strategies. Wireframe of course also falls under this category. For your convenience we've set up a dedicated page for what we refer to as Wireframe alternatives; be sure to check them out as well!
Wireframe is great for scalability, serious developers, and teams
But why Wireframe, you may ask — and, you know, that's a very good question indeed. Wireframe isn't the only viable solution out there, not by a long shot, but we strongly believe that it's top of it's class in many ways.
First of all Wireframe was designed from the get-go with demanding projects in mind: by focusing on well defined structure, a carefully selected collection of powerful (yet easy to grasp!) core concepts, and scalability (in more ways than one) it strives to solve common "big project issues" such as code repetition, separation of concerns (or the lack of it), and difficult to grasp hierarchies.
Built on the foundation of its battle-tested predecessor pw-mvc, Wireframe is a great choice for developing robust and scalable ProcessWire sites.
While it's not a "pure" MVC implementation (whatever that means nowadays), Wireframe introduces concepts that are commonly utilized in the context of software development, and as such it's well suited for complex projects. On the other hand it also puts plenty of weight on ease of use and simplicity, which makes it a great candidate for smaller sites.
Last but not least, Wireframe is quite opinionated, which means that things tend to work the same from project to project — a highly valuable feature if you're working as a team. Enabling and enhancing teamwork has always been one of Wireframe's grand goals.