PHP Frameworks: FuelPHP
Posted on June 21, 2012
In the last few days I’ve been messing with FuelPHP, a relatively new PHP framework. It’s written by a bunch of guys who used to work on CodeIgniter, and while it shows a lot of promise, right now I don’t quite think it’s ready for large projects. For reference, this writeup is for Fuel 1.2, which was released just a few weeks ago.
Things I Liked
- Data modeling. They really got this one right. It’s simple, easy, and most importantly, object-oriented. There’s no comparison with twiddling arrays in Cake, or dealing with overly large Doctrine models.
- MVVM. View modeling is awesome, and is a setup that I’ve not really worked with in the past. It keeps controllers nice and clean, and provides a discrete separation of logic. I wish more frameworks had this.
- Routing. The routing interface is really clean and fluid, and reminds me of Symfony. Well done there.
- Environments. Some frameworks don’t even have a discrete concept of environment…
- Core extending. If you want to build your own custom version of something (say, authentication), you can just extend the core class and load it. I wrote my own authentication to do a simple login, and it worked fairly well.
Things That I Didn’t Like
- Documentation. The documentation is woefully short and leaves out a whole lot of things. There are hundreds of functions in the actual core classes and other procedural methods that aren’t publicly documented anywhere. See below for a rather good example.
- Configuration. There is a great amount you can do with customization, and it’s just not apparent at all. For example, I was working with fieldsets and was using the built-in rendering, and had no clue in the world that you can overwrite the default behavior (which uses tables). I had to dig through the forums to figure that out.
- Forms. In general, forms are just really wonky to work with.
- Awkwardness. This one is a bit more subjective, but Fuel just doesn’t feel very intuitive to me. It’s hard for me to actually explain, but after messing with it for awhile, I just don’t feel like I’ve got a good grasp on its intricacies – and I can’t really go look for answers anywhere.
The biggest thing for me is that it just doesn’t feel ready for anything larger than small projects. A number of comments from the developers in the forums basically boil down to, “Yeah, that’s a bit of a mess – we’ll have it fixed in version 2.” While it’s encouraging to know that the developers are working hard to get it to be awesome, it’s just not there yet. I mean, I’m excited to see where this goes. I’ll definitely keep an eye on the project and see what advances come in 1.3, and definitely in version 2. Their repo is full of commits in the 2.0 branches, so I’m hoping it gets released sooner rather than later.
FuelPHP started off as a project between a few developers building the best thing that they could. In the first few months and the first year the community went mad for it, and they send in hundreds and hundreds of pull requests. They helped with documentation, added features and made improvements.
Now that we’re at 1.2 it seems that the community doesn’t feel the need to contribute all that much anymore. The development team have their own jobs and are not paid to develop the framework like many others, so we relied on that community support. If you find something that is not documented, then you find the answer, then you DONT send a pull request, then you missed a chance to help out others. If the guy before you did that, you wouldn’t have had a problem.
There are some bits like the ORM or Fieldsets that I barely understand. They’re tough to work out, but generally the only things that are not documented are not things you NEED to use. You can use Doctrine as an ORM, or any other ORM for that matter. Most folks don’t even use an ORM, so it’s really not the end of the world.
All Hail 2.0
2.0 is a big step in the right direction. Instead of maintaining all this stuff around the framework (like the ORM) which people barely have time to support AS WELL AS document, then FuelPHP 2.0 aims to do what a framework should: be a bloody good framework, not a good framework, and orm, and email driver package, asset package, and and and and. We’re moving to making our code Composer based, so we can plug and play FuelPHP code with other code, become ORM agnostic, use existing packages for various features and make the whole thing more useful.
Yes, some stuff in 1.x wasn’t perfect. Yes, some of it didn’t get documented, but most of what is there works really well and the bits that don’t work are getting rewritten. What more could you realistically ask for?
You say it’s not ready for “large projects”. I’ve been reading your comments a couple of times, but I can’t find any reference to why you think that is the case.
What defines a large project?
FuelPHP comes out of the box with quite a few features especially geared towards large projects, like built-in theming and templating, modularity and extensibility, HVMC support and for REST api controllers.
Your comments are absolutely true. Docs could be a lot better. We’re working on a new community support website that will make it very easy to update documentation. The current ORM and Fieldset implementation will be discontinued for 2.0. There are better and well maintained ORM’s available, and Fieldsets are way to complicated. Having said that, form generation is never going to be very useful for large projects, instead use the fieldset to build your forms in the view.
We feel at the moment it’s better to direct all efforts towards getting 2.0 ready, instead of trying to correct some of the known issues in 1.x while we know they won’t be ported to 2.0.
Whoa. I don’t even know how you guys found this post, but it’s quite humbling that you actually read it – so thanks for that. I honestly didn’t mean for this post to be vitriolic at all; it was more my musings on the subject. I really do appreciate the work you guys – along with the rest of the devs – have put into it, and like I said, I look forward to what’s coming up.
Phil: I guess I didn’t realize how much of the project was community-based, and I also didn’t realize that the docs were on github. As I figure out things, if they’re not in the docs, I’ll try to help with that. As to the ORM thing, I much prefer a cleaner, smaller version as compared to something enormous like Doctrine. Fabian is an incredible developer, but I kinda think Doctrine is just too top-heavy.
Harro: by large project, I meant an enterprise-level project in terms of data, as compared to something that a person puts together for themselves over a weekend. Here’s an example: suppose I wanted to build something where I have two different types: Articles and Pages, and each has a field called slug that is unique between them. I want to be able to route /:slug to each of the two types. So /my-article is an Article, and /about-us is a Page. I don’t see a way to easily do that with Fuel. In Cake or Symfony, I could do this with two different route classes. I realize that there are much easier solutions to this (/article/:slug and /page/:slug), but if a client wants everything to be pathed to root, I’m not sure what else we could do.
And I agree with the push for 2.0 – it seems that you guys learned a whole lot in putting this framework together, and it really does look like the next iteration will get it right.
Greg,
If that is your definition then I can only say that FuelPHP has been ready for that for a very long time. My company specializes in corporate/bussiness applications (we don’t do your grocer-on-the-corner type websites), and we’ve been standardized on FuelPHP from the moment v1.0 was released.
The case you use as an example has nothing to do with the application classification. I would argue that in a business application you wouldn’t use that kind of ‘magic’ mechanisms. But like in Cake or Symphony, you can create very complex routes in FuelPHP. Unlike these frameworks, FuelPHP uses closures instead of classes.