An Honest Look at Why We Use TYPO3

This blog post has been floating around in the back of my mind for many weeks, along with another, more technical post on ExtBase, which I hope to compose over the holidays. The prompt for this post has been the question "why do we continue to use TYPO3?"—a question I often ask myself during my day at Cast Iron Coding.

There are, after all, lots of reasons not to use TYPO3. During meetings with current and prospective clients, I often find myself cast as the defender of TYPO3. I suspect that just about anywhere that's not Germany, clients want to know why they should be looking at TYPO3 when their colleagues and peers are only talking about Drupal, Wordpress, and occasionally Joomla. If TYPO3 is so great, the argument goes, why have I never heard of it?

As a developer (most of this blog's readers know that I wear many hats at CIC, my favorite of which is actually sitting down at my desk and writing code), I often end up defending TYPO3 against a few common lines of questioning. There's the anti-PHP crowd that I sometimes run into. For the most part, talented developers in 2011 don't select PHP as their language du jour. Because of its early accessibility, its ubiquity in hosting environments, and the lack of support for real object-orientation in its early days, a lot of really awful procedural code has been written in PHP, and its been hard for the language to escape the legacy created by that code as its aged. Many really smart developers shy away from PHP on principal, and I can't say I always blame them. If PHP has declined in popularity, so has the concept of the CMS. These days, skilled developers want to work in frameworks like Rails, not content management systems that began production over ten years ago. Age brings features and functionality, but it also brings baggage. Sometimes, it brings lots of baggage. I'm thinking of Moodle, Mediawiki, and a whole host of other open source PHP apps built on codebases that now seem desperately outdated.

In short, I find that I'm constantly forced to question our commitment to TYPO3 in the face of its waning popularity (which creates doubt in the minds of marketing people) and its questionable technical pedigree (which creates doubt in the minds of developers and IT people). The lack of adoption in the US creates a feedback loop in which the lack of adoption is used as justification for the continued lack of adoption. Yet somehow, in spite of these questions, my team and I keep using TYPO3. We keep coming back to it year, after year. Why?

Well, unlike some other agencies, it's not because TYPO3 is the only system we're comfortable with. CIC is fundamentally a development agency (not a design agency), and the people on the CIC team understand how to code. We're a group that's always interested in a variety of technologies—I've seen people in this office working with Ruby, Python, PHP, shell scripting, Java apps, all sorts of Javascript tools (Coffeescript, Sencha libraries, the Knockout MVVM framework, Node, and more). We're a pragmatic, pick-the-right-tool-for-the-job, kind of shop and we're not unquestioningly married to a single technology. And yet, we keep using this PHP based CMS that's over ten years old. Why?

As I've been trying to think through and articulate an answer to this question, I'm reminded that there are truly unique aspects of TYPO3 that convince us to stick with it. To hear my thoughts on these aspects of TYPO3, click on the "continue reading" link, below.

First, TYPO3 isn't as popular as Wordpress and Drupal because it serves a much smaller market (in terms of quantity, but not necessarily in terms of revenue potential) than Drupal and Wordpress do. TYPO3 is best suited for larger, more complex sites, and there are inevitably fewer of these sites on the web than smaller sites.

I'll make this point by looking at Wordpress, because its a more unbalanced and therefore easier comparison to make. Last I heard, Wordpress powers some 50% of the sites on the internet. Any piece of software that's been able to grab that kind of market share is undoubtedly providing a lot of value to a lot of people, and I have nothing but respect for it. However, it's is absolutely not the right tool for the kinds of clients we work with. Organizations with dedicated MARCOM departments (which tends to mean multiple content stakeholders) that need to communicate on behalf of many groups within the organization and to provide sales teams with messaging and promotional tools, in most cases, will not be well served by a site running Wordpress. It's not that it can't be done—lots of effort has gone into making the Wordpress blogging platform into a CMS—rather it's that it just shouldn't be done. Organizations that produce a lot of content will always have structured content, data-driven content, and tie-ins with other systems (external and internal). For sites with these sorts of content to be scalable and maintainable, it's crucial that the content be stored in a structured way (and, equally important, that there are models in code that can adequately express the site's content and data). Wordpress' core models—the page and the post—are, in my view, too limited to serve the needs of larger organizations (unless, of course, those needs are simple, as is the case if we're talking about campaign sites, brochure sites, landing pages, and other small projects for which Wordpress can be a perfect fit). Wordpress' architecture, which is fundamentally procedural, means writing code that tends to lack the hallmarks of modern development including the ability to conform to common design patterns and principals of object oriented development. In short, Wordpress really, really rules at solving some problems, but it doesn't solve the problem that we try to solve, which is the management of content on large sites with complex data models and integration/workflow requirements.

Drupal is a trickier fish, and I'll admit that I don't have nearly as much hands-on experience with it as I'd like to, so my comparison here may be inaccurate, in which case I'm certain the denizens of the internet will elucidate matters for me. That said, it's also a system that, despite its popularity, just isn't all that attractive to me. For one, it has the same problems as TYPO3 (written in PHP, old codebase), but without TYPO3's effort to modernize the architecture. We've worked on projects where the site needs to expand and grow over five or six years, and the success of those projects has always been directly tied to our ability to write clean code, code that employs object orientation, polymorphism, inheritance, service-based architectures, and clear separations of business logic and the presentation layer. These aren't just buzzwords, either, these are the core principals on which nearly all interesting web development in 2011 is based. In an industry where MVC is finally becoming common knowledge, I find it difficult to fully commit to a system with a procedural codebase. I'm also a strong believer in the need to separate the front-end of the site from the administrative back-end, and my understanding of Drupal is that significant parts of the admin interface render on the front-end of the site. Perhaps I'm old-fashioned in wanting 100% control of the markup on the front-end of a site. But, part of me really believes that the rendered markup needs to be carefully crafted, and that a CMS has no business dictating what that markup looks like.

Moreover, popularity is not, as we should all remind ourselves, a clear and unambiguous sign of superiority. Wordpress is more popular than TYPO3 because it solves a more common need. It's a great tool for personal sites, blogs, small news-oriented sites, campaign sites, projects with tight budgets, small mom and pop business sites, and so on and so forth. If the hardware store down the street came to us and asked for a site, it would be almost criminal to suggest they go with TYPO3. Drupal is popular because it's accessible, certainly more so than TYPO3. Web design agencies (and we should deliberately distinguish web DESIGN agencies from web DEVELOPMENT agencies), in my experience, tend to have developers on staff who are, well, perfectly capable at writing markup, working with jQuery-powered Javascript, and who can confidently write PHP, but who may not really understand how the pieces in the MVC pattern fit together or who may not have heard of dependency injection or continuous integration or the oodles of other really good ideas that smart web programmers have been talking about for years now. These jack-of-all-trades web designer/developer types see a pretty good fit in Drupal, I think, whereas TYPO3 must look like a real nightmare to them, with its technical documentation and confusing ExtBase framework and its often too-technical backend interface. Plus, Drupal has always done a better job of marketing itself, and that too is a self-fulfilling prophecy. Drupal, to the newcomer, appears to be the healthier, better-maintained project, and that counts for a lot.

But, TYPO3 is different from these systems. It's more technical and embraces more technical concepts. It gives developers a lot of freedom, which hasn't always been good as it's lead to some terrible extensions. It's more complex, but that complexity isn't necessarily bad. For one, TYPO3 has always been able to compete, more or less, on core features. Workspaces and versioning has gotten much, much better over the years and is now a usable core feature. TYPO3's page model has always been sophisticated, and even in this era of the "social" web, the page and page content models are powerful models for content-driven sites. Localization has been present in TYPO3 since, more or less, the beginning, as has its support for multiple sites. More important than any of this, however, is the fact that for many years now TYPO3 has contained an object oriented plug-in architecture. This allows TYPO3 to be built around clear separations of concerns, which in turn tends to make upgrades very easy and stable (unlike, from what I hear, Drupal). Moreover, it has allowed developers to create TYPO3's little secret that most non-TYPO3 developers have no idea exists: the ExtBase MVC framework.

Unfortunately, most of the people who read this blog are TYPO3 developers who already know about ExtBase. This time, however, those people are not my intended audience. I want people who are considering TYPO3 to think about the ramifications of ExtBase a bit. The TYPO3 core contains a powerful MVC framework that is well built and really quite modern (Extbase supports signals and slots, dependency injection, a persistence layer a la Rails' active record pattern, and more). Because ExtBase is so informed by FLOW3, which in turn is informed by Domain Driven Design, ExtBase really compels programmers to follow best practices, which in turns leads to code that tends to be highly reusable. Controllers and Models in ExtBase extensions can be easily extended and ExtBase's object manager (which handles the dependency injection) allows for all kinds of scenarios where you substitute your custom object for an extension object. The takeaway here is that TYPO3 allows developers to employ some really modern programming paradigms and to write code quickly that is easy to maintain and scale over time. No hooks (instead of old-school hooks, in TYPO3-land we use signals and slots!), no procedural code, and no intermingling of business and presentation logic makes for satisfying development and an increased bottom line as developers are able to work more efficiently.

A picture of TYPO3 begins to emerge. It's a traditional CMS in many ways, with all the warts and pockmarks that all the old PHP systems possess. We all wish the backend interface was a bit cleaner, and contained somewhat less Javascript insanity. We all wish that the code contained fewer idiosyncrasies. We all wish that Kasper (TYPO3's original creator) had strove for convention over configuration. We all wish that Typoscript were easier (it's an powerful tool once you wrap your head around it, but asking a developer to learn a declarative language that's specific to one tool is a lot to ask in this day and age). But it's also forward thinking in a lot of other ways. Kasper embraced object orientation early on, in ways that competing systems did not, and TYPO3 benefits from those choices to this day. It contains powerful, documented interfaces that really matter in business settings (clear plug-in API, a task scheduler interface, a reporting interface, a database abstraction layer, authentication services, a command-line interface, to name just a few). And, finally, it contains an MVC framework that is sophisticated and vastly reduces development time while vastly increasing code reusability. Plus, what system doesn't have its warts? Nothing is perfect, and technology is never as perfect or as easy as many users are lead to believe it should be.

And this brings me to my second point about TYPO3 vs development frameworks (we can use Ruby on Rails as an example). Enterprise and large-small business projects tend to include significant custom requirements and tend to come with corresponding budgets. When more code needs to be written, it can be tempting to go with a web application development framework like Rails. Rails, like Wordpress and Drupal, is a great tool for certain jobs, but we increasingly see it being used for the wrong sorts of jobs. If you're building a data-driven application (like Basecamp or Harvest or Github), the by all means, pick Rails. TYPO3 wouldn't be a viable, maintainable solution to those sorts of problems. But, if what you need is to display data within a corporate website, then TYPO3 is often a much better fit than a development framework. With TYPO3, you get a full admin interface (which is significantly better than the scaffolding that frameworks give you) and all kinds of pre-built data models that are relevant. You get a content editing interface as well, so you don't have to recreate that old CMS wheel in the framework.

Clients come to us asking for custom functionality all the time. A large real estate developer asks us for a project database to show off their work. A foundation wants an application on their site that allows users to search 50 years of grantmaking. A medical imaging company asks for a media gallery with numerous ways of filtering the data. A nonprofit asks us to implement a system that allows municipalities to track their "green" initiatives across 150 different metrics. All of these sorts of tasks require custom development, and all of them could be built in Rails or Symfony or FLOW3. But, all of these organizations also have traditional content management requirements. They need to create pages, they need users to login to the front-end of the site and have their sessions tied into these custom applications, they need to render views of the custom application throughout the site as callouts and sidebars, and so on and so forth. Because TYPO3 occupies this middle ground between CMS and framework, because it offers the best of both worlds, it's able to meet this wide range of need and is able to do so in a scalable, maintainable way.

And so, time and time again, we come back to TYPO3. Not for every project, mind you, but for many of the projects. Despite its flaws, its warts, and its internal inconsistencies, we keep using it because in the end, its capabilities outweigh those flaws every time. More important, perhaps, than anything I've mentioned so far, the TYPO3 community pushes us to learn more and to become better developers. People in the community may complain about FLOW3 and TYPO3 5.0 (the legendary phoenix) at times. Hindsight is 20/20, as they say. However, there is one thing that is undeniably true: the current crop of leaders in the TYPO3 community—and you know who these people are—have pushed all of us to be better developers. Instead of sticking to TYPO3's somewhat legacy code-base, the FLOW3 and ExtBase team have push the community to embrace new development patterns and techniques. They've  turned many TYPO3 developers on to the MVC pattern, dependency injection, continuous integration, aspect oriented programming, signals and slots, ORM, test-driven development, domain-driven design, and many other paradigms. We keep coming back to TYPO3 because of just how forward-thinking the community around it often is.

We also keep coming back to TYPO3 because doing so has allowed CIC to grow its bottom line consistently over seven years. With TYPO3, we've been able to consistently under-bid and out-deliver competing agencies. Up until a few years ago, we were able to do that because we'd built a custom MVC framework in TYPO3 that was similar to ExtBase, but less sophisticated. Since ExtBase was integrated into the core, we've dropped our framework, embraced ExtBase, and haven't looked back. Neither have our clients, who to all indications are happy to use TYPO3 and happy with the functionality we've built and the price point at which we've been able to deliver it.

So, if you're still with me after this long post, put aside any preconceptions about TYPO3 and PHP that you might have on hold for a while. Check out FLOW3 and read up on what Robert and Karsten are trying to accomplish with that framework. Sure, PHP isn't as elegant as Ruby, but it does have the key features necessary for writing object-oriented code, and it's ubiquity and ease of use, as well as the birth of innovative frameworks like FLOW3 are powerful arguments for its continued relevance. Check out TYPO3 and play around with ExtBase. It will take you some time to get up to speed, of course, but the community is fundamentally friendly and people will help you if you ask intelligent questions. I think you'll be surprised with what you can accomplish with ExtBase, and how much you'll learn as you work with it.

On that note, Merry Christmas and Happy Holidays to all our friends and colleagues in the TYPO3 community!

--Zach

12 Comments

Zach, great post! Usually I stop reading long blog posts somewhere in the middle, but this one got me. You couldn't have written it better :)

"Despite its flaws, its warts, and its internal inconsistencies, we keep using it because in the end, its capabilities outweigh those flaws every time"

and

"TYPO3 community pushes us to learn more and to become better developers"

Perfect...!

Bye, and have a nice day,

Fabrizio
Posted by Fabrizio Branca on December 21, 2011

Thanks for the kind feedback, Fabrizio! I didn't mean for it to get so long, but it turned out I had a lot to say :)
Posted by Zach Davis on December 21, 2011

Nice write up. As a Symfony2 core developer, I always saw FLOW3 as a proof of concept that yes its possible to do really modern architectures and design principles in PHP.

But it really sadness me that the FLOW3 team didn't realize the opportunity that they once strived for and then dropped as they thought the path was too hard to do on their own .. and that is bringing JCR to PHP. The thing is FLOW3 is not alone here anymore and more importantly PHPCR is very real now with a growing community and 2 implementations that are pressing forward at rapid pace.

Check out http://phpcr.github.com/
It should be quite possible for FLOW3 to become compatible with PHPCR (again) and the benefits are great. Not only because of the potential for interoperability but also because it gives new options to scale.
Posted by Lukas on December 21, 2011

Thanks for the comment, Lukas (and for the re-tweet). I appreciate the tip on PHPCR—I hadn't seen that yet and will take a look at it.
Posted by Zach Davis on December 21, 2011

Thanks for the post, Zach. As always, well thought and well articulated.

I continue to use TYPO3 for the same reason I have used a Mac since 1990 (even during the clone wars). It is the best tool I have found to do the type of work I do and aspire to.

In the case of TYPO3, its content paradigm fits well sites that need to present diverse content in a variety of ways particularly when the need for a custom application is mixed in.
Posted by Ron Hall on December 21, 2011

Thanks, Zach, for sharing your thoughts! I'm very happy that I could be a little part in your motivation to stick with TYPO3. I left some note here: https://plus.google.com/u/0/101127394092431284396/posts/4xmweNYtfm5

As for Lukas' comment: I'm not against involving myself or the project into common efforts for standardizing libraries such as PHPCR. Just the contrary. At this time it's more a question of how much energy is left and how to set the priorities. After all we are still a very small team with a huge list of tasks. And I don't see much room for additional efforts until we have have finally released a stable version of TYPO3 Phoenix.
Posted by Robert Lemke on December 22, 2011

Zach,

Whew, the words abounded here. I'm really happy to see this post and the points of view it conveys regarding TYPO3 usage.

In the end, as you say, it's the clients needs that drive what core system to use. For the simpler stuff, I go the WordPress route, the more complex, TYPO3, every time.

+1 for `Despite its flaws, its warts, and its internal inconsistencies, we keep using it because in the end, its capabilities outweigh those flaws every time. More important, perhaps, than anything I've mentioned so far, the TYPO3 community pushes us to learn more and to become better developers.`

There's lots of truth here.

Ciao from Germany!

Michael
Posted by Michael Cannon on December 22, 2011

@Robert: well to me thats the point of PHPCR, to pool resources so that each of us has todo less to get more :)

Same applies to creates.org too btw :)
Posted by Lukas on December 22, 2011

Hey Zach,

awesome posting :-) You really were able to express how many of us feel. And it also makes me very happy that the route we decided on in the Berlin Manifesto ( http://typo3.org/development/roadmap/berlin-manifesto/ ), especially "Feature Convergence" and "Providing Resources For Learning" really seems to work out for a lot of people :-) -- not to say that we can't improve things still.

@Lukas / @Robert: I think embracing PHPCR would make sense; though I think the "Copy-on-Write Content Overlays" are an absolutely required feature for us to use it. and as Robert has written, we have a small team with lots and lots of tasks...

Greets, enjoy christmas time, Sebastian
Posted by Sebastian Kurfürst on December 22, 2011

Great post. We are always trying hard to write phpcs clean code and had some test driven development oriented projects in the past. So we appreciate most in 5.0, that the TER will only keep clean extensions.

Keep up your good work. All the best markus / web&co
Posted by Markus Pfeifenberger on December 26, 2011

As a TYPO3 web 'designer' based in Drupal's homeland Belgium, I sometimes feel a bit lonely to be one of the few TYPO3 freelancers in my country.

There was a time when TYPO3 was 'the' CMS to use, but when the years went by, other cms's started to gain their spot.

Your blog describes exactly how I saw TYPO3 evolve. And even I had my doubts from time to time. If I choose to start using Drupal some years ago, I would have had a lot more work, but ...

Most of the systems I have tried over the years all had nice features still I couldn't stop thinking I have seen these features long before they were introduced as new an exciting. TYPO3 already had them, most of the times even as a core feature.

Thank you Zach for this very well written post. It truly describes why I still use TYPO3, even when I sometimes forget why ... Not the best marketed CMS out there, not even the most known but definitely one to be very proud off.
Posted by Rob De Vries on January 13, 2012

We've been using TYPO3 to manage site content since 2006. When we redesigned this site in 2011, we included a complete upgrade of TYPO3. Your blog hits all the right notes. I don't know if anyone ever *loves* TYPO3, but after five years of content management it continues adapt and grow with our needs.
Posted by Doug Hooper on February 9, 2012

Leave A Comment

Cast Iron Coding, 107 SE Washington, Suite 210, Portland, OR 97214
PH: 503.841.5669 | FAX: 866.285.6140 | contact@castironcoding.com

Made in Oregon!

Cast Iron Coding is a web development studio located in beautiful Portland, Oregon


Contact Us
107 SE Washington, Suite 210
Portland, OR 97214
PH: 503.841.5669
FAX: 866.285.6140
contact@castironcoding.com