Differences between the Joomla Framework and Joomla Platform

What is the Joomla Framework, why do we need it when we already have the Joomla Platform?

The Next Generation...

Essentially, the Joomla Framework can be thought of as the next generation of the Joomla Platform. The massive changes required to introduce advances, such as namespacing, have huge backwards compatibility issues with the CMS and the existing Platform, which would basically lock the CMS into the version of the Platform it is using right now. This change presented an opportunity to create a new incubator, for further development, that could be used not only by the CMS and those developing applications natively on the Joomla Platform, but also by the wider PHP community.

Additionally, with the current Platform, it's a take it all or nothing situation. With this new approach, everyone will be able to choose the bits they actually need. It's a move away from the monolithic stack. A component based framework (in the sense of Symfony Components, not what the CMS historically refers to as "components") allows new code can be added and tested and easily integrated by downstream users. It would make it much more simple for the CMS to integrate things like Diana's OAuth work as well as JTwitter / JFacebook.

Does this mean that the Platform will get absorbed back into the CMS?

It means that all the work that's been done up till now, excluding the namespacing, can be absorbed back into the CMS's control. That's good for the CMS because it cuts down on the double handling they currently have fixing bugs.

Does this mean that extensions will break, or need to be rewritten, in the next version of the CMS?

No, in fact the change will prevent this from happening. The CMS will be at liberty to introduce parts of the new Joomla Framework as it needs to, and in a way that present no compatibility issues with existing extensions.

However, it is important to note we are not making the Joomla Framework backward compatible with the Joomla Platform. We are cleaning up all deprecated code in the process, as well as removing any remaining CMS code or poorly maintained packages. We feel this is a good strategy as the shift to namespacing is pretty big (you have to change your code) and also shifting to composer mean developers will have to start fresh anyway.

Why create another repository for this when there is already one for the Platform? Won't that confuse everyone?

Basically, the reason is that it was much easier to start a new repository to do all the prep work in. We had extensive discussions and it would seem that referring to things as the "old Platform" and the "new Platform" would get very confusing. Changing the name, and the repository, allows us to very clearly delineate between the monolithic stack that is Joomla Platform, and the new, namespaced, Composer aware code that is the Joomla Framework.

We are also breaking out each of the packages into their own repository so that they can be installed via composer in any environment that needs them. For example, someone coding with Laravel might want to use our Github code (since it's AWESOME). Currently, with the Platform, that's not possible. With the Framework, it is possible, because it's been decoupled from the other classes in the platform and is able to be used with few other requirements.

Okay, sounds great. When will it be ready? What version of the CMS will it be in?

Good question! Our goal is to at least put "Humpty back together" and get things working again, but also in a way that you can install individual packages and composer works out all the dependencies.

The CMS won't have any of the new Framework in it. It will sync whatever it can from the current Joomla Platform and then we'll more than likely retire the Joomla Platform as a separately maintained entity. All new work will go directly into the CMS or the Joomla Framework.

Does this mean that we will be able to use Composer and Packagist with the Framework?

Composer, and its companion Packagist, have become the defacto standard for integrating PHP libraries into your applications. The new Joomla Platform (a.k.a. the Joomla Framework) needs to fit more easily into this paradigm as well as making it easier for people building Joomla application to be able to leverage other libraries available through Composer more easily. Therefore, with all the work that is going on with namespacing, the current platform is being broken up into individual packages that can be published to Composer and installed with Packagist.

There is also the opportunity to clean up any package (removing legacy code), or even dropping existing packages (like JFile, etc).

What opportunities and challenges does this create for the project?

Opportunities:

Delegates management away from a small group of platform maintainers that can easily become a bottleneck for accepting or reviewing contributions on the platform as a whole. It is much easier for people to focus on approving code for smaller chunks of code.

Allows developers to pick-and-choose what they need to build applications regardless of what core library those applications are built on.

Still maintains the Joomla “brand”

Allows for packages that fall into disrepair or just hold no interest to be easily retired.

The Joomla leadership just has to be responsible for providing the right tools and for guiding policy.

Challenges:

There is some new overhead in creating repositories and maintaining access control lists. We've sorted some of this out with git sub-split. Still other details to sort out.

We’d have to work out how to approve new packages, something we have yet to tackle.