Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Future of the framework
Once again some woes on current state of the project.
As much as I like the framework and I made tons of great apps with it, it no longer seems like something worth recommending, as no clear roadmap for the framework is announced and v2 plans been there for long enough to unvalidate itself over time.
In other hand anything I've tried could get close to pleasure working with Fuel.
I wouldn't mind to devote some time to help build the core if there are any core interfaces/classes layed out.
Personally I woudl expect PHP7+ support (just forget about 5.x), more PSR compatibility (especially autoloader aspects), more composer centric approach and modularity provided by it (I liked certain parts of the framework core and even ported things like query builder to standalone classes just to use it in some legacy project), probably couple of more things...
Just dont want this to turn into another Kohana....
Its funny how long projects like CodeIgniter, Yii or Nette survived over there and other faded away as a result of community dropping off...
So... what sort of realistic plans are there for Fuel ?
The honest answer is: I wish I knew.
I had a stroke in 2014 which severly limited my mental capacity (which is pretty shit I can tell you, if you work in IT), and this is only slowly recovering.
With this limitation I try to maintain the current codebase as good as I can, if only because my company develops everything using Fuel. As we build apps and not websites, stuff we build require long term and ongoing support. We have apps that are still developed on which are getting to 9 years old!
So the current codebase is not going away anti time soon, and nor will our support for it.
Having said that, things are improving, and in the recent months Emlyn and I have been discussing the possibility of picking things up again. Things we've agreed on sofar:
Target PHP8 (strict typing / return types / type declarations)
Chained Middleware architecture
Composer components instead of modules/packages
API driven design (possibly OpenAPI based), controller returns data structure
Output rendering separate from
, based on returned data and request format
Keep Fuel simplicity, avoid Laravel/Symfony complexity
The challenge in many Open Source projects is people, finding hands to do the work.
I support another project as well (where I don't have to develop, so it is easier on the brain), and they suffer from the same problem, it seems like for the current generation, IT is a 9-to-5 job, and not a hobby anymore.
Sorry to hear about your health, hope you recover soon. You made great contributions to open source projects (still remember DataMapper for CodeIgniter)...
Long term support and quick responses to reported bugs are greatly appreciated, however for a green field projects growing and vibrant community around the project is safer ground as there will be someone to maintain the code they invest money in. Personally I still maintain some Kohana based software (still runs fine, but had to patch frameworks myself to be able to run it on PHP7.x), but having large community comes with many benefits (large number of experienced ppl and extensions)...
The reality of UK's market is 70-80% PHP jobs Laravel then some e-commerce / cms platforms / unspecified, so you have to learn Laravel or you going to starve.
What you have mentioned about plans for v2 seems reasonable. I would also add some DI containers and service classes and type hinting are pretty useful concepts, worth implementing.
If you need some more help with building v2, let us know.
I'm more than happy to help in any form!
I'm really itching to get started again, but at the moment, the brain still lets me down.
It is however slowly improving, I hope to be in a position to do something for an hour or two a day, without falling asleep, by the end of the year. Hopefully PHP 8 will be released by then, so we have something to develop with.
And I'm going to take you up on that offer!
Hope you get better Harro
This was one of my favorite topics. I asked questions and I'm still following the changes.
Fuel is a framework With beautiful design and unique capabilities in its time, it could have become the premier framework, but that's all.
I must first say I still use Fuel and the new version of this framework is not very important to me. In general terms, developing a framework requires either an emotional level or a high financial level, and I don't think it is possible to develop it under current circumstances.
Let me give an example:
Let's think the new version was born and all issues (!) Were fixed. what's next?
Problems with the site and the forum that really doesn't attract anyone and can't even do a simple search inside the forum and google for it (really not someone who can write a better CMS or forum? Or maybe No one asked?) ...
The docs are still having problems, very few examples, versions, multilinguals, etc. (Currently the main developers are editing the docs) Of course, how to update is a separate issue.
There are no packages (currently not available for the new version compared to other frameworks) and there are no dedicated features (whether new or old) and
What features will developers consider other than the source framework itself? Only code? An ugly old site? An unusable forum?
Let's look at it logically: not everything is code, even for frameworks!
All this cycle will be repeated again and more developers will migrate this framework. Why?
What additional features are available on the site?
What additional features will this new framework have?
Who will support it?
Most importantly: at what cost?
(In the real world, developers need money - it's a full-time job)
Harro: IT is a 9-to-5 job, and not a hobby anymore.
I don't know if there is a plan for this.
Harro is trying harder than anyone else to develop a new version (what I think) and of course to support and answer questions (what I saw). The other core members of the developer framework are absent (or at least I didn't see them in the discussions)
Code sharing is practically forgotten in this framework.
(To one of the questions about the UI for the Auth package, the answer was almost: This section is not free tools!(can`t search and give you link)
Well, where to buy it?
Where can I get this service if it's not open source?)
Just visit the Larval site, full of features that we can easily use for our clients and develop, for a very small fee.(
Writing code may be important, but to develop and use the framework we need to do more than just write code.
Why should we explain to clients why we use this framework? (I always ask myself!)
Why waste more time writing duplicate codes? (Oil is really useless)
Why do I have to write everything myself?(There are really few packages)
I would love to appreciate the efforts of the main developers, but these should also be taken into consideration.
Anyway for the new version: We need a lot of changes!
On a business psychology course, a coach once told me:
"Everything a human being does is driven by 3 factors: Money, Status, and Fun".
Developing Open Source didn't use to be about money, some did it for the status it brings ("I am a famous developer, look at me"), some, like me, did it for fun.
Doing something for fun implies btw I mainly do it for me. It is good for my ego that others like it and want to use it, but it is not my main goal, and that probably reflects in things like documentation.
Today, the fun is gone for most people (they don't want to code in their spare time), and more and more it is about money (from fremium to commercial models), both Symfony and Laravel are commercially backed, for their developers it is a paid day job.
If you're big enough, and commercial, you can employ or pay people to do everything around the code, from docs to conferences, like Laravel does. Fuel isn't, and Fuel doesn't strive to be.
It all means that tradiional Open Source can simply not compete with that.
I personally don't recognize many of your comments.
Our clients don't have any say in the tools we use. Most don't have a clue.
Most of our Fuel apps use a long list of composer packages (there is seldom a need for Fuel specific packages), I don't really miss Fuel specific packages. I think we have less than 10 we regularly use.
We developed a theming framework a long time ago (which was loosly modelled on Joomla's template system at the time) which we re-use for every app, and which only needs small controllers to provide the output for page template sections. It is database driven, so no hardcoded routes, you plug a module in, configure it's location within the app, have the front-end guy theme it, and done. Not unlike a CMS with plugins.
The list of improvements we have is based on the issues we have run into, the biggest one being duplicate code for multiple endpoint types (/users/list returning html, vs /api/users/list return json, which basically the same code).
I also like to replace our modules and their config system by service providers, remove the distinction between modules and packages (make them all composer packages) and introduce a middleware system, not unlike the one Laravel uses, to make process chains possible, so you don't have to fiddle with class extensions and before/after methods.
Using the middleware system, the controllers can be standardized to only return a data structure, and output rendering can be done at the end, external to the controller. This would allow /users/list return both HTML and JSON, depending on the request.
Honestly, I disagree with most statements on the post above (by atabak), Harro was faster.
Fuel is quite niche framework, quite unique in a good meaning. I remember when I first started using it after it was clear for everyone that Kohana is dead. It was a bit hard, few 500 (no write permission to log directory) thrown and took me a while to get around some quirks. Longer I worked with it the more I loved it. Everything was easy and quite intuitive. I can recall one moment when I was working on my CMS and I had to render some tree like structure into html nested lists... I though " would that work" and I nested some views to recursively render the whole tree and it worked like a charm! And this is where it fits: a succesor to CodeIgniter -> Kohana lineage and approach to development.
Performance and low overhead was always one of the key points for me and its really hard to find any simple MVC framework to meet the expectations, but in other hand, the landscape of PHP tools and the languages capabilities have changed dramatically, thats why we need to move on.
Zend is still zend, masivelly overengineered, loads of abstractions seems completely unecessary for my projects...
Symfony4 is my number one when looking for replacement. All looks good, I like couple of concepts like autowireing, CI containers, annotations, service classes.... until you bring Doctrine and start using standard packages like validation, auth or forms... This may have some sense working on massive scale project with hundrets of developers... consistency then is more important than your effectivness as a single dev. For me personally, its just too much hustle and effort to make things this way.... and oh the performance... single select consume 7-12mb of RAM. I can simply server x10 more traffic using Fuel for the same cost... where it may be less concern for the corp, it matters for me. Still, need a site with authentication ? Well there is no bundle for it it seems, you just write your own implementation every single time... Documentation is quite bad, but not terrible, if you get chance to put your hands on symfonycast it can actually make a huge difference and speed up things, otherwise it feels really owherwhelming to a newbies..
Laravel is another example. It reminds me Wordpress. Huge community its where it shines. Thousands of extensions can seriously speed things up. Need a site with authentication ? artisan auth:make and its done... untill you need permission with roles... or anything slightly different. Then you end up writing your own or use extensions. This is where it reminds me Wordpress, thousands of extensions, very few is actually a quality code... but there is a chance you can gule in couple bits to get what you want.
As speaking with other developers, it seems like for them Laravel is "not as aggresive as other frameworks" and from businnes owners "its just easy"... Figuring stuff out is another story...
From a developer point of view I dont like its design. Seems bloated, with the most hated fascades and triats everywhere. Seems very confusing and its very easy to write smelly code. With so many extensions and lack of clear abstractions I have no idea how would it all work together on a larger scale, not to mention performance.... However there are some good bits, its easy, its easy to write stuff, easy to start. There is a lot of resources and devs out there to help if you stuck (not everyone if not majority of devs) is capable to dig down to the framework core to figure things out. I have few projects running in Laravel. It was a bit painful to start with, but I accepted my faith and tried to do stuff. Most stuff seems unecessary, blade is not bad but I can't get along this concept of extending views - its just limitig and counter intuitive. Processing payments, queuing jobs, sending notifications its as easy as it could be but I didn't need anythin specific on there...
What else is left there ?
Yii which seems to be still alive and kicking (never had a chance to work with it) but its quite impressive that they still there.
CodeIgniter still breathing - is bad as todays standards (I've seen recently project written in it) seems very old and limiting. There is a new verison in late beta, few improvements but feels outdated already - personally I wouldn go for it...
Slim ? Not much in it seems more like a simple wrapper around few composer packages, having Symfony4 actually makes it pointless....
Looking at above landscape, there is a lack of simple and powerfull HMVC framework, with low overhead, and this is where I see fuel right now.
The problem is that many things changed since initial Fuel's release. PHP seems to be more composer oriented, PSR plays important role shaping quasi API for different vendors and has serious impact on things like loggers or can speak common language - its just make sense to do this way. In the other hand, PHP7 introduced many goodies, static typing, error handling improvements and many others, we are simply not thaking benefit of that. Where I'm completely sure I'll be able to run my Fuel based apps for several years from now, its just hard to convince anyone to give it a try now.
In other words, I value core principles and philosophy behind Fuel, but its need a start form scratch really and its a biggest no-go for new devs. I even heard "they failed to release v2 for several years now" where I value LTS more, this seems to be good indicatior on overall "health" of the project.
Website isn't important (but might be for some) documentaition isn't great but obviously could be improved... It lacks few concepts to be highlghted as begginners may not be aware of it, and comperhensive explanation of components woudl be nice to have, but thats a secondary thing. Presonally I'm good enough to figure out by just reading the code...
Building communities has nothing to do with how the website or forum looks like. You need to get attention of good and dedicated devs first and build on top of that. Rest seems to be jumping on a train being attracted by many factors, but they never find "a bare framework" valuable. Its more on"how easy", "how capable" and "how musch support" I can get thing rather than a pretty website. It was really sad to see how Kohana community collapsed, mainly as ppl felt left alone after each minor release brought breaking hanges and v3 was completely different animal without any particular reason at that time... Same IMO have happened to Mootools when I was really tired of pairing few plugins together, where jQuery was rock solid and just worked... Thats I think why composer / PSR woudl help to avoid the pain and give a framework an instant access to huge library of quality extension to build on.
Starting fresh from PHP8+, PSR in ming sparks a new hope. Dropping packages seems reasonable as well as composer serves this purpose much better and its available for everyone, regardless the framework... And this is one of reasons why we don't have any decent packages : they are only for Fuel and community isn't big enough to make any sense to make them. I did use it for my own purposes but they were only to share some specific functionalities across different platforms I created with it. Using composer would be much better choice to share code with the outer world.
For me personally, Fuels hits the spot. If you need variety of plugins, dont want to write anything again - go with Laravel, honestly. If you don't mind spending hours on learing these things potentially risking "it might not fit my requirements without serious modifications" you should be satisfied with it.
I seriously doubt Fuel will reach popularity level of Laravel, but it certanly find its way to the hearts of few ninja devs over there
This is a good framework to use and it doesn't need to be complimented. Why did you misunderstand my talk?
I think first of all I said I like this framework and work with it.
I wrote small and large projects with this framework (mostly government and corporations) from simple mobile api to complex projects, perhaps most of all developers - I also wrote my own generator code and it worked fast.
What I meant to bring up on subjects like Larval and other frameworks was just an example and not a comparison. It's not wrong to compare, though.
Maybe I took this framework too seriously? Maybe I didn't express my opinion well either!
Providing resources and documentation for each function, class, and control is required for government programs and some companies. There is really competition. (Re-read "disperse" messages)
Harro I've been working on a project just like your templates and it's coming to an end and I'm really upset now, these codes took me about two weeks! Although I could buy it for you and use in the project (I'm sure my coding is not as good as your coding).
Is this a problem? Does it have anything to do with open source? What's wrong?
Larval and Symfony are great and there are plenty of projects ready to start in these frameworks. But they don't work for me (read the above comment for a better understanding)
For the site and the docs, I don't think I'm wrong and it really needs work.
Why not ask the developers in this forum to design a simple forum based on Fuelphp? Whatever it is, it's better than this forum!
I talked about the facts without any fanfare.
For some projects I have to rewrite most of what is available in Larval or Symfony. Why? Because Fuel is not taken seriously and no one is willing to write a special package for it.
I mean using other developers' potential for this framework, otherwise I have no problem doing it right now.
I think I had better say it now!
Let me tell you a bit about Fuel so you might be kind to me:
For example, using Clamav to scan files in Upload in Fuel does not take long and it is funny that this was a lot of advertising for Larval. Or using Swoole as the server took a few hours but not one person responded to it in the forum although I later found out the project was available on github.
These problems will be solved if developers and users become too many
Why would you be upset? Our code is not open source, and not for sale.
As to docs and forum, I don't think anyone is debating that, I welcome your contributions.
If I had a team of 20 people, and the funds to pay them, things might be different. But as things stand, it is my free time, of which I don't have a lot (that is useful). It is all very easy to "demand" better docs, a better forum, tons of packages, and so on, but as with so many open source projects, you are not paying my time, you get it for free, so you have to do with what is there.
In the (in)famous words of Phil Sturgeon: "PR or STFU".
I work, and worked a lot with Fuel, and love the framework. I do regret the lack of popularity, but it's not a big deal, everything you need is there, as well as support for PHP version and security update.
I don't agree with the statement that for new generation, code is only a job. Code is my passion, and I do want to spend some time helping Fuel to improve. The thing is, that without clear guideline from project maintainer on should we improve 1.x vs making v2 (which was never clearly defined, btw), it's quite hard to have a clear vision, that can be divided into tasks.
But since there appear to be motivated devs here about Fuel future, should we discuss a clear direction to take ? I am willing to be a part of this.
It was more a generalisation, I understand there will always be exceptions.
Good to hear you want to get involved, we'll have to think about how to document the todo list so others can easily contribute.
Just want to throw my 2 cents in from an autodidactic/amateur point of view
I absolutley love Fuel from the first time I wrote my first few lines of code with it!
I tried Laravel, Symfony, Codeigniter and with none of them I could get stuff runnnig as easy, fast and steady as with Fuel!
I'm not a techie nor am I a professional programmer but I had to create a database GUI for a friend which he could use from everywhere without a local application like Access or Base or stuff like that and Fuel was kind of a revelation.
I knew some basic PHP like echo and foreach and so but with Fuel I got a deeper insight into PHP to the point that I was able to extend the auth class from a 3 to a 4 part permission set (set1.set2.set3.set4[part]) and even created my own class/package to generate barcodes and finally a "blank" template for Joomla with a scss compiler to compile Bootstrap 4 on the fly
For me this was a huge leap and all because of the things I learned using Fuel
With that being said, I actually don't need too many changes or more features. The framework together with the packages Auth and ORM provides everything needed to start a project! Just keep it compatible with the evolution of PHP!
And please keep composer optional! I totally despise that "tool" (or maybe I just don't understand its concept)
There are a few changes that I want to see:
- Make Classes testable, which mean removing the static interface (from the classes themselfs)
- Remove Fuel's own autoloader in favour of PSR-4 (composer autoloader)
- Replace Theme / View / Fieldset / Validation to make ouput generation easier / simpler
- Split output generation from business logic to avoid code replication (p.e. view output vs api's)
- Split code from data in the ORM (to make it faster / less heavy / more memory efficient )
- Simplify the callstack ( request -> controller -> response ) processing
I agree that the fundamental idea behind Fuel should not be changed, it should remain "fast and simple", it shouldn't turn into a second Laravel...
Harro, any progress on planning out v2 ?
My health hasn't allowed for major work, unfortunately.
The bit of time I have goes into putting bread on the table, and fixes for the existing codebase if and when needed.
Add a Comment
It looks like you're new here. If you want to get involved, click one of these buttons!
Apply for Membership
↳ Job Board
↳ Installation & Setup
↳ Tips and Tutorials
↳ Code share
In this Discussion