When I first posted to this forum, I new very little about frameworks and their inner workings. Unfortunately, I made the decision to go with Laravel despite the sound advice I received from everyone here. I don't even remember my last post but that is when I went with Laravel. I've since built many projects building Laravel and did a lot of freelancing using Laravel as my go to framework. I've since used Rails for some stuff as well but my heart is still with PHP and Rails has it's own issues.
Basically, Laravel is turning into a Symfony clone and with it, the extra baggage/bloatware. I have been very unhappy with the way they jump into new versions so quickly. They are getting ready to release 5.0. It is a totally different animal based on it's predecessor.
Anyway, I am back on the move looking for a good PHP framework. So, here I am.
Welcome back, Matt. Out of curiosity I just checked when you left the forums and FuelPHP: your last post was in August of 2012 - maybe you've already been on the go then or hopping on the Laravel train.
It's nice seeing someone turn their back on Laravel and go back to another framework. Quite frankly I don't get what the hype about Laravel is either. Don't get me wrong, Laravel is a great framework and I get a load of inspiration from its implementations, too, but I don't like the rapid development process as well as the high frequency of major releases. There's other things I personally don't like about Laravel either, but I definitely don't want to bash on the framework. I'm very happy for Taylor to have created a framework that has gained popularity in such a short amount of time. Then again, I like FuelPHP because it's not necessarily following every new trend and does not release new major versions every year or so. Though I would love to see the 2.0 release of FuelPHP rather sooner than later ;)
I hope we do better than Laravel in this respect: we don't like bloatware either, and absolutely no fans of Symfony.
One of the reasons we started with FuelPHP was because we feld the need for a simple, fast and stable framework that could be used for "corporate" applications, which require long-term maintenance, and where there is hardly ever a business case for upgrading the framework used. Clients simply don't want to pay for work that doesn't give them anything from a functional point of view.
Our aim is to make upgrading as painless as possible, which looks like it will be the case, except for applications that use core class extensions (which obviously have to be rewritten).
Part of the current codebase will become available in v2, for example ORM, as the new ORM is very different (but worth the upgrade, its so fast its crazy).
And back to my first remark: when Fuel v2 hits the streets, we're going to release a final LTS version of v1, which will be supported for bugs and security issues for at least a few years, so all your current applications will remain safe and supported.
It's great to see some of the same faces since back when I first joined this forum.
As mentioned above by Harro, I don't want to commit to this version of Fuel when 2.0 is coming out. I will have to look at the changes. I do like the fact that Fuel comes with it's own ACL. Laravel does not.
I have been checking out the documentation but can't seem to find anything on route or controller filters?
Assuming you don't have any core extensions, the goal is to limit the changes to search-and-replace type.
Obviously, we can't guarantee anything until v2 is actually there, and we've done a few upgrades outselfs.
Upgrading will be documented, going through the entire v1 API. One if the major changes is the switch from snake_case to camelCase, requiring quite a bit of changes.
v2 will not have a static interface like v1 has, but we're planning a separate package to introduce that (a but like L4's facade's). One of the options we have is to make this package also emulate the old v1 method names.
Honestly, I have never built an application with Fuel. I've just been running through the core docs. I have a very important client that needs an enterprise app built. I am planning on having Fuel take care of the web based dashboard and communicating with the middleware that is already in place that someone else built in Java. Basically, revamping a straight PHP dashboard, which was poorly slapped together with vanilla PHP (no design patter) and rebuilding it from there.
This job starts on Dec. 1st but I already have some core stuff developed in Laravel that I will have to re-build in Fuel. Unfortunately there is no way around it. Not even with PSR loading standards.
Yes, I will admit, Facades were a nice feature in Laravel. I am using quite a few interfaces and services so I am assuming you can tap into the IOC with Fuel the same way?
Another thing I really didn't like about Laravel was their forum. Either, there were too many people trying to answer the question with the similar answers and were wrong or nobody at all. Not too mention, Taylor Otwell or Jeffrey Ways never once responded to my questions. Not that I wanted to but my point being, I get that type of person to person touch here. I've always liked that and seeing the same ole faces still here tells me some good things. I know Phil took off and went with Laravel. Hey, gotta go where the cash is I suppose. Oh well. That's the way I look at Laravel. One big money backing project where things are rushed, rushed and rushed. Then, a spokesperson like Jeffrey pushing Laracasts and his endorsement to the framework. By all means, I take nothing away from either of them. Excellent developers but even better business men.
If I had stumbled across Laracasts the first day I was searching for a PHP framework, I would have went back to whatever it was and continued to use it. Some great stuff there but my goodness, talking about making core topics more and more confusing. Especially with the endless banter in the comments.
Introducing all of these topics that just aren't core but are "hot" at the moment or trending in the developer community. No thanks.
I can't imagine Phil contributing much, he didn't do that here too. ;-)
I think it is important for core developers to be present in the community. Especially for a community driven project, without any company backing (money or not).
Fuel v1 doesn't have DI or IoC. So nothing to tap into. Fuel v1 has a static interface (which is where L4 got his facades from), with "forge" and "instance" methods to create and retrieve instances.
Donate
