Many of us know our preferred framework or platform of choice very well. So when faced with an upgrade, a platform evolution, or a new task that requires looking into and learning a new framework, the prospect can be a bit daunting. Whether you have to learn a new framework or platform to keep current on your day to day job or just because you love learning, I’ve got a few tips I hope will help make your journey a little easier.

How Did it Come to This?

There are two main reasons to learn a new framework or platform. The first is because you’re curious and you want to see what it offers. In this case, you’ve either already got a framework you like and are familiar with, or it’s your first framework, or perhaps you haven’t yet found a framework you really like. You’re investigating because you personally feel in some way that it would be good to look into this new framework. Nobody may be forcing you to learn it, but you want to.

The second is that you’re effectively being forced to learn it. Perhaps the framework you know and love is no longer being supported. Perhaps your platform of choice is adopting a new way of working, bringing in components from a framework and essentially requiring that to stick with your platform, you learn some new and foreign things. If you’re a Drupal developer, the latest version is bringing in quite a bit from the Symfony framework, allowing for greater interoperability with frameworks and components from outside the Drupal ecosystem.

If you’re a long-time Zend Framework developer, you may remember the huge shift it was to move from Zend Framework 1 to Zend Framework 2. That’s the transition I went through. Essentially everything about the framework changed except for how it was spelled. Because of this enormous shift, a lot of applications remain on the first version. Just around the corner is Zend Framework 3 which is more of a philosophical shift than a “change everything” approach that marked the move from version 1 to 2.

My most recent foray into a new framework came with trying to learn Zend Expressive, a microframework that uses a middleware approach and Zend Framework 3 components. While I am quite familiar with Zend 1 and 2, middleware was something new, with only a brief bit in a conference tutorial looking into the Slim framework.

The Role of Frameworks

In the last decade of PHP, frameworks have moved from being nearly unheard of to ubiquitous. Dozens, if not hundreds of new frameworks have popped up, some flourishing, others quickly fizzling out. We’ve seen large frameworks like Zend Framework 1 and 2, and Symfony. Laravel, while being relatively new has enjoyed a meteoric rise in popularity. CodeIgniter and CakePHP aimed at developers wanting some of the simplicity of Ruby on Rails, but they brought about many of the restrictions as well. Phalcon’s goal is speed with the framework itself being implemented as a C extension. Yii is built to work with third party code, allowing easier integration with other frameworks. Aura provides fully decoupled components without external dependencies. In short, there’s probably a framework that matches with your coding style and philosophy, if not overall, then at least for a particular project.

Another movement I’ve seen over the last couple of years is the move towards microframeworks. These are smaller frameworks that aim to provide a lot of the common functionality but not everything. Often these are based on components from a major framework. There’s Lumen, based on Laravel, Expressive based on Zend, Silex based on Symfony, and Slim which uses a few of the PHP Framework Interoperability Group’s PSRs (and others, of course). Whatever your framework choice and for whatever reason, I hope this will help you get going quickly.

Jump in With Both Feet

As I mentioned, my most recent foray into a new framework was with Zend Expressive. This was done by choice. I’ve been using Zend Framework 1 and 2 since before their official 1.0 release and Apigility since it was announced at ZendCon in 2013. As a result, I know the Zend stuff pretty well, so I thought looking at Expressive would be a lot of nothing new. I was wrong. The shift from “MVC” to middleware requires a change in thinking and understanding what the actual problem is, rather than determining how you would have solved it with the framework you’re familiar with. When learning any new framework, there will be a bit of a learning curve bump to get over.

With Expressive, I decided I wanted to build a project that would stick around rather than a throwaway app. Not something huge, but something I needed. Whether the project went well, or poorly, I was going to finish it. This leads me to my first bit of advice when learning a new framework.

Make a Small Real Project

There’s a lot to be said for following tutorials or watching videos and reading blogs. All of those are valuable and worthwhile, but if you’re not actually doing something real with a new framework, chances are you’ll quickly reach a hard limit on what you know about it. So my recommendation is to build something real. What I mean by that is a project that you’re going to launch or use, at least for a while. Many tutorials step you through building a blog, or a book or movie or CD tracker. These are all fine and good, but beyond adding a book or movie, you’re never going to touch them again. You likely won’t add any features or functionality beyond what the tutorial told you to add.

To really learn a framework, build a project for something you’re going to use. If you’re going to be using it, chances are you’ll need to come up with new features, and you’ll need to learn how to make them in your new framework.

For me, the project I wanted to build with Zend Expressive was what I’m calling a webhooks box. We have a series of Jenkins Continuous Integration build servers, as well as projects hosted on Bitbucket, and Jira, and we use Slack to communicate. Our Jenkins servers are not publicly accessible, but I wanted to make a way that would allow events or webhooks from each of these services to cause things like builds, notifications to Slack, updates to statuses in Bitbucket and Jira. I want to be able to cause tests to run, builds to go, approvals, etc to happen because of messages in Slack. So this will be a an ongoing and continually updated project for me.

Apply What You Know, Be Open To Learning

Zend Expressive and Zend Framework 3 have been heralded as an end to framework silos. In a testament to this, when installing it, the framework gives you a number of choices for various pieces. It supports routing via Aura.Router, FastRoute and Zend Router. It supports dependency injection through Aura.Di, Pimple and Zend ServiceManager. For rendering HTML, it supports Twig, Plates and Zend View. With these choices, I had the advantage of being able to pick some things I am familiar with while choosing others that I am not at all familiar with. In my case, I chose FastRoute, Zend ServiceManager and Plates. Of these, Zend ServiceManager is something I’m quite familiar with, but I’ve never used the others.

With my work with Zend Framework and Apigility, I am familiar with Zend Router, and a little with Zend View but I decided to pass them up and see how other libraries work for these things. If you’re experienced in a framework, then many of the concepts you’ll need to learn for a new framework may be familiar, but the implementation may not be.

Learn the New API

Zend Expressive is able to allow choices of what dependency injection container, view renderer and router you want to use because in each case, each of the choices follow the same sort of pattern. The middleware that is used follows the interfaces specified by PSR-7. The dependency injection containers follow ContainerInterop which effectively means that by learning some of these new libraries, I’ll have a good headstart on learning the others.

Each framework has these concepts, whether they are provided by the framework or through external components like they are with Expressive. This means there will be a way to do routing, a way to build objects and inject dependencies, ways to render views, perhaps ways to connect to and interact with databases. In some cases, the framework may provide even more, such as interactions with web APIs, payment gateways, generating PDFs and barcodes, working with file systems (both remote and local), database migrations and more.

Becoming familiar with what the framework provides can help you when building out your application. That being said, I feel the way forward is for frameworks to provide less and components and packages to be included where needed. To see where some of this is heading, I urge you to look at what the PHP-FIG is doing. In addition to creating recommendations for coding styles, autoloading, caching, logging, and HTTP messages, they are working on recommendations for interfaces that will help libraries interact for hypermedia, containers and documentation. These interfaces will help ensure a much easier transition from libraries that use them to other libraries and implementations with those same interfaces.

Coming back from FIG land to the API, if your framework doesn’t use these interop interfaces, you’ll need to learn about how they do each of them. For instance, does the framework provide for dependency injection? If so, is it handled automagically, through configuration, through factories or something else? Are the factories defined as classes, callable closures, arrays of key => value mappings, or something else?

Is routing handled via configuration, convention, method calls or something else? For frameworks that provide routing details via configuration, you many need to learn XML, YAML, JSON or how the particular flavor of PHP arrays needs to be arranged. If routing is done via convention, it means that you’ll place certain kinds of files in certain places with particular names.

In my case with learning Zend Expressive, the new API that I needed to learn about middleware. It’s a pattern where there’s an incoming request and an outgoing response and in-between a number of small pieces of software called “middleware”. At each step, each of these functions or classes makes a small change to the response or makes a decision and then the control passes to the next bit of middleware. From what I’ve seen it allows for a lot of transparency in what’s happening since the framework is mostly there to take away a bit of boilerplate. At any point along the way, a piece of middleware can return a response which means the rest of the middleware doesn’t need to run.

It also means that many of the paradigms I’m used to when dealing with applications using an MVC style framework do not apply here. I’ve had to change how I think a bit to get things working, but it has also lead to what I feel is a group of smaller, more easily testable and more composable bits of code. So far it has been quite educational and enlightening. I’m definitely looking forward to what I’ll be learning in the upcoming weeks.

Sometimes frameworks provide 42 different ways to do the same thing. Sometimes they have terrible documentation or none at all. In this case, looking at the source is a good idea. Another way to find out what’s happening behind the scenes is to connect a debugger (See the January 2015 issue for more on this) and step through what’s happening. This can be very helpful and enlightening in discovering how the framework does its magic and hopefully determine how it expects you to work with it.

Contribute to Open Source

After you’ve gone through the tutorials and videos, it may still be a bit of a mystery about how to work with the framework. The designers and developers who created the framework usually had some idea about how it would be used but unless they’ve documented it clearly, it may not be readily apparent what they were thinking. That’s where contributing to open source comes to play. If you can, find an open source project that uses the framework you’re trying to learn. There’s a good chance the people who created the project know a thing or two about the framework. You can use the project as a bunch of examples about how the framework can do things. If you are able to make changes, think fixing bugs, adding features, even writing documentation for the project means you may be able to pick the brains of the maintainers and ask questions about how they might do something if you’re trying to figure out the framework.

Additionally, with a fully realized project, my suggestion for using the debugger works here as well. It can help you understand how the project is organized and how the project uses the framework and components it depends on. Sometimes the project may provide additional clues and hints on how to provide contributions that lead to further insight about how the framework works. Working with a full project will almost certainly provide more information about a framework than any tutorial or video.

Contribute to the Framework

Once you’ve established a bit of familiarity with the framework, another valuable step is to start contributing to, at least trying to, contribute to the framework. Take a look at the framework’s github page and look at the issues. See if there’s something listed that sounds like it’s not too far off the beaten path. Try to reproduce it by building a small example with the framework. If you’re able to reproduce the issue but don’t feel able to fix it, commenting on the issue that you were able to make it happen and how can be very useful to the maintainers. If you can fix it, put together a patch and make a pull request.

When you become a bit familiar with some aspect of the framework, look at the documentation around that area. If it’s lacking, explained poorly, or could use additional examples, consider writing new documentation or augmenting the docs. Contributing code or documentation back to a framework is a great way of saying thank you to the people who created and maintain the framework. Imagine how much easier you might have found learning the framework with your new and improved documentation in place. Consider it a way of “paying it forward”. Improving the docs means that other newcomers will likely have an easier time learning the framework, which means more users, more contributors and ultimately a better framework with better support.

Practice, Practice, Practice

Ultimately, the best way to learn a framework well is practice. This, of course, applies to all areas of life. The best way to get better is practice. This means continuing to use the framework, building new features into your application, changing existing features to use new, different and better ways of realizing the framework. It means getting involved in the community, joining the IRC channel for the framework, asking questions, answering questions and getting feedback. You can go on StackOverflow and ask and answer questions. If the framework is new and you feel you’ve learned it well enough, consider speaking at your local usergroup to introduce others to the framework and share what you’ve learned. Sharing your knowledge and ideas in a written or spoken way is a great way to solidify the ideas and concepts you’ve learned.

This Framework Sucks, Now What?

In some cases you may find that you don’t like the framework or it doesn’t do what you need it to. That’s ok as well. Not every framework will appeal to everyone. If it did, we’d probably need only one framework, not hundreds. If you finally decide that the framework isn’t for you, now you have a choice. If it’s close to what you’d like but not quite there, you could consider contributing to fill in the gaps. Of course the maintainer has no obligations to take your patches, but it is an option. You could fork the framework and make your own version. You could start your own. If you decide to do this, I recommend it mainly as a learning exercise. You can, of course, create and release your own framework, but chances are unless it’s doing something particularly elegant, novel, or special, it’s unlikely you’ll gain many users.

Fortunately, there are tons of other frameworks out there. As I’ve mentioned numerous times in previous articles, one of the best ways to level up is to not stop learning. Pick another framework and start another project with it. Learn it, contribute to it, and decide if you want to continue to work with it. If you find that you do like it, spread the word. Help others find and use it, help contribute to it with code, docs or bug triage. Open source thrives because of the contributions everyone makes.

Now What?

Whether you’ve got a reason that is being imposed on you to learn a new framework, or you just want to learn something new to keep your skills fresh and learn new ideas, taking the time to learn a new framework can be a great experience. It can lead to new opportunities at your current position or new contracts. If you contribute by sending pull requests, speaking, or writing, it can be a great way to meet new people, make friends and have more fun with your work. The bottom line is don’t be afraid of a new framework. Look at it as an opportunity to learn and improve and absorb new ideas. It’s also an opportunity to contribute and give back. Framework authors and contributors are also learning and growing as developers as well. This means new frameworks and new versions of existing frameworks will continue. By learning about them and hopefully contributing to them, this cycle will continue. See you next month!