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 ?
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)
PSR 3/4/6/7/11/14/151/7
Chained Middleware architecture
Composer components instead of modules/packages
API driven design (possibly OpenAPI based), controller returns data structure
Output rendering separate from controller, based on returned data and request format
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.
Hello 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 compatibility issues.
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.(https://nova.laravel.com/)
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.
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) ;)
So in order to picture what is the current situation of the framework, Harro, as you stated, don't have time to do major work on it at the moment, and the rest of us willing to work on it is not so much, so manpower is kind of missing here.
The framework isn't dead, far from it, but isn't in great shape either. Packagist show 400 installs for april, and 11.3k for Laravel, which is only 28 time more (I say "only" given the difference of popularity, I was expecting bigger difference).
V2 would be great, but I deeply think that the actual 1.8 is already a hell of a framework. The major issue is not the codebase, but the few to none traction it get. Think about it : Not so much potential newcomers heard about Fuel when looking for a framework, and a good part of those who do will be discouraged by the website and documentation, the fact that most of the few available packages are quite old now, ect...
Here are some ideas to that could get it more tractions :
- Having a new website, more modern, including better doc organisation, and also refreshing forum look and feel (I can work on that, let's discuss)
- Having a dedicated subreddit, Discord channel, youtube channel...
- Taking old tutorials and make them more actuals, like show what the rest controller can do with a modern javascript framework - Make them textual and video, diffuse them on the website, tutorials websites, subbreddit, youtube, social networks...
Because I think any dev can be seduced by Fuel code design, what is missing is everything else. What do you guys thinks ?
We (as in Fuel) are not free of idea's either, but it all boils down to time, or lack thereof.
And unlike 10-15 years ago, there doesn't seem to be much appitite amongst developers to spend many hours a week working on an open source product, just for the fun of it. I see the same with other open source projects. You can't compare that to the likes of Laravel or Symfony, which both have financial backing from a commercial organisation.
We (as in my company which currently backs Fuel) have some modernizing plans on the table, and my idea is to have those worked on in dead time, if the cashflow permits it (so I don't to furlough staff). With the idea that 2.0 is simply an evolution of 1.8/1.9, and not a total rewrite. We don't have the cash spare to sponsor Fuel development unfortunately.
One of the big improvements we want/need, is a decoupling between controller and view/presenter. So in effect every controller will become a sort of rest controller, returning a data structure, and external factors will determine if the data will be rendered into HTML, returned as JSON, etc. We would also like a decoupling between frontend and backend, so that you can split the HTML rendering from the API, for example for scalability.
The rewrite was originally planned because the current codebase is virtually untestable due to the number of static interfaces and tight coupling. But the more I think of it, the more I think Fuel serves a different market from the likes of Laravel or Symfony. I don't know about you,but most of our clients aren't really into spending 60% or more of their budget on writing tests. No matter if that is a good or a bad thing... ;-)
« And unlike 10-15 years ago, there doesn't seem to be much appitite amongst developers to spend many hours a week working on an open source product, just for the fun of it »
You keep saying that. I strongly disagree. Open sources contributions went off the roof in the lasts years with the popularity of Github, and the web industry heading more to packages driven paradigm. Devs wants as much as before to do stuff for fun. Why wouldn't they ? Don't fall for the classic "It was better back in the days, nowadays nobody [...] anymore".
If Fuel become attractive again as a framework, I guarantee you that there will be more people willing to work on it, and that is a simple fact. Which brings me back to my previous post, you didn't expressed any opinion at all about the suggestions I made. What do you think about them ?
I am active in several projects, and all of them have difficulties finding people, and holding on to them. I am not talking about occasional contributors (which you need to, absolutely), but team members willing to spend many hours a week on the project. You need these people, not only for the bulk of the work, but also for architecture and design, roadmap, planning, etc.
The main difference is (I think) that back then, it was a hobby for most people, and hobbies are always exciting and worth spending time on. These days, for most developers it is a (9-5) job, and they look for hobbies that don't have anything to do with work. You also see that in the average age, which in another project I contribute to is around 50.
As to your suggestions, they are all valid, no doubt about it.
But even there it boils down to people. Don't underestimate the hours needed to deal with your list, you would probably need at least 5 people with lots of free time to do anything significant.
I may sounds cynical, but they say that is what old age does to people.. ;-)
Maybe it's just that involving in a new, exciting project is more fun for devs rather than in a framework that isn't evolving since a long time...
But there are still people that are willing to involve and this thread is the living proof. So, first thing first, what about we (people interested to improve Fuel) find a more practical way to exchange on the subject. Do you wanna make a discord channel for that purpose, maybe with an announcement on the website and twitter ?
And regarding the list of suggestion, I am offering to involve in them. So, the first priority should be the website, do you agree ? I can do that. I've already wrapped my head around it and have interesting ideas about making a new website for Fuel. Here is a proposition on how things could be re-arranged :
- Bring a modern look with a fresh design.
- Drop PyroCms ( but actually no, see further )
- For the website "content" (homepage, about, features, contribute, contact), It could be statics html files, with a modern css framework and some js as needed. If it is a requirement to be able to easily edit content, a headless cms like prismic.io or storyblok.com can be integrated easily - their forever free plan is more than enought for that task. Those static files can then be ci/cd deployed on github pages or netfily open source free plan.
- For the doc part, Html files can be converted in markdown, which will be great for editing more easily, and from there, automatically generate it with docsify or vuepress. Those are greats tools with realtime full search. Again, automatically deploying to github pages or netlify at doc.fuelphp.com (same goes for dev-docs)
- The (abandonned) roadmap section could be removed as Github is better to organise things on each repo directly with mardown files and issue system.
- The Api and Forum obvisouly depend of Pyrocms and phpDocumentor generation environment, so the simpliest solution would be to leave those as it is and make it v1.fuelphp.com, with 301 redirect so SEO won't break. On those sections, header and footer should be adapted to match the new design as close as possible. The forum CSS could eventually have a a bit of work to make it look more modern.
I don't have much time, so it won't be there soon, but I still can give fews hours a week. Maybe others would be willing to help if you diffuse the call. What do you say about it ?
We have the fuelphp.org domain available, which was planned for Fuel v2. It runs on Pyro as well (it's one multisite installation), but with a different and brighter theme, while keeping the Fuel purple...
I've disabled maintenance mode so you can check it out: http://fuelphp.org (no SSL cert setup yet).
It can be used to setup something new, besides the already existing site. Currently, it is loaded with old content which was used to make the theme.
As for the forum, I'd like to link in the existing forum, shouldn't be too difficult, it's embedded in the pyro theme, and yes, API is phpdocumentor output, which runs automatically using a git hook, we can keep that to (for the time being).
I can't really argue with your other points, all very valid, and yes, the more hands, the merrier...
The theme you showed is pretty decent, but I had something more carefully designed in mind. I'm working on something that should please you. I'll show it when ready.
So, I have an early version of the concept I'm working on for the new website. You can check it there : https://adamsgit.github.io
Please let me know what you think about it. There is a lot of stuff missing ATM, It's just a homepage first shot. Currently, it's just plain HTML, CSS and a bit of JS. No content managment has been integrated yet because it's not something I should decide alone.
I also found a not-so-tedious way to convert the documentation in markdown, so I will take care of this soon and give a try to docsify.
After that, I also plan to write the "Get started" guide, haven't put a lot of thoughts in it yet, but I will most likely be a todo app with Api driven Fuel and Svelte.js, something that reflect more the web development as it is now.
Good. Regarding content managment, do you have any requirments / suggestions ? I propose to keep it simple by either :
Not having any - Just modify static files when needed through Github - Partials can be generated with hooks - Would be and issue for blog tho.
Use a headless CMS with free plan - Content served through CDN at load time - I suggest Storyblok (1TB / Bw / month) or Prismic.io (100GB / Bw / month) - Great for a lot of content types including blog - Good for eventual translations as well
Also, we could use a more efficient way to exchange about it. Do you use Discord ? By the way, that may be a good idea to have a Discord channel for Fuel in a more general way, a lot of code related projects move to it those days. Do you want me to take care of it ?
As to hosting, Fuel's sponsor (FlexCoders Ltd) does, besides Fuel development, also managed hosting. So we have a managed VM available for free that currently runs fuelphp.com and fuelphp.org (was reserved for the new version "2", both domains are owned by the sponsor too).
No, I don't use Discord, never have. So I have to look at it. The current channels are in Slack, as rooms on FlexCoders' Slack license, but they haven't seen any traffic since Mark quit.
edit: the sponsor has several managed "as a service" offerings, amongst which Mattermost, an open source platform like Discord or Slack. Might also be an option.
Donate
