Preface: I am the Founder and Lead Developer for Fuel
A lot of people are complaining, and saying things like we don't use namespaces properly. My response: Then don't use the framework. I started the framework because no current framework met my needs. Here are some of the reasons I did not simply use an existing framework:
CodeIgniter - Slow to evolve, requires a lot of code for simple things, nothing autoloaded (don't even try to mention the autoload config file.
Symfony2 - Over-complication of menial tasks, kind of slow.
CakePHP - Slowest (php) framework known too man, bloated, need I say more?
Zend - Slow, bloated.
Yii - Just don't generally like the syntax.
Kohana - There isn't much I don't like about Kohana actually...other than its not PHP 5.3 yet (not going into specifics on why this is bad).
DooPHP - Not full-featured-enough.
I also wanted things like HMVC (i know some of the above support it), Modular Routing and a few other things.
To the guy that said he was turned off by the Html class: if you don't want it, don't use it, stop whining.
I agree with your assertion to not use your framework. Believe it or not, having an open and active user base of your framework will help you and all members. Doesn't seem like you are attempting to start things off on a very good note.
I think you got him wrong. We've been at this for some time now and did some heavy development on this. Sometimes a person comes in and comments with a single line like "I WANT MORE NAMESPACES" and seems to assume that we picked our current setup without giving it a second thought. When someone comes around and all they can say is something as unmotivated and useless as that we won't have a lot of time for the assumption we didn't think of it.
If you completely disagree that's fine, move on to something else then - no hard feelings either way I hope. Just don't assume we just created this at random. Dan's remark was spot on, we chose the way we handle namespaces and autoloading very deliberately and we'll take the time to explain our motivations if you ask. But if you come in telling us that our setup sucks because we should be all-something because product X has that as well: don't expect we'll spend any time on you. There are lots of others with a more open-minded approach whom our time is far better spent on, and of course especially those actively helping out being the community you refer to.
If you try to make your software perfect for everyone, then all you will create is a muddled mess. It's a good thing to acknowledge that some people are your audience and other people aren't.
I mean, if you were developing a new social network site, would you try to seed it with the Amish?
I think it's great to have more active frameworks for PHP that keep questioning how 'stuff was done' with the previous ones.
The only thing that I keep wishing for is that the whole 'new school' PHP 5.3+ gets something similar to Ruby's gems and having more high quality code that lives outside of frameworks.
(That's no criticism towards FuelPHP at all - just seeing that you guys are writing some 'good PHP code' it might be worth considering if it wouldn't be great when some of it was available outside of FuelPHP as well.)
Actually we have something along those lines: using our command line utility you can install "packages" which should be a collection of classes for added functionality. Currently we have some well known libraries already available through the CLI by using "php oil install package htmlpurifier" for example, they're taken from Github and installed in the fuel/packages/<packagename> dir.
Of course if you don't want CLI you can just download them and copy them to the right directory yourself.
We intend to create a repository for packages and classes installable through Oil directly into your Fuel install.
At this time we are still using a single Github profile to fork any repo into that will be available through Oil package install: https://github.com/fuel-packages (install the packages without the "fuel-" prefix as their name)
PEAR and PECL are great, but they add requirements to your application that live outside of the system.
You have to worry about your application being compatible with the version installed on the server and all sorts of other madness. Through this incredibly simple system (which will shortly become more powerful with its own interface) we can basically just install a package into your application in the same way most people would normally download, unzip, etc.
php oil install foo
Then add it to git, push and you're all good. Otherwise you have to run around installing dependencies and all sorts of other junk.
Some of us in the PHP community definitely agree with you, and are working on trying to change the culture amongst developers. I'm currently writing a series of blog posts to try and convince developers why this is a good idea, and how to go about doing it.
I've been following Fuel's commits ever since they were on GitHub, and it's been impressive watching it all come together. The only concern I have is with the overall tone of the project, influenced mainly by Dan.
There was one comment here about namespaces... Phil gave a detailed answer; Dan says 'if you don't like it, don't use the framework'. Someone brought up the HTML class... Phil explains why it's there and that it isn't loaded unless you want to use it; Dan says the same thing, but adds 'stop whining'. I think Dan is incredibly talented, but I've seen he is very quick to use the words dumb, idiot and retard in his Twitter stream.
As a mid-level developer that uses mainly CodeIgniter, there is a lot about Fuel that is new to me and I don't fully understand. If I were to start using Fuel and had maybe a dumb question about how something worked, part of me wonders if I'd be berated publicly or called an idiot. That doesn't make me want to rush out and start learning something new.
I'm really grateful to all the Fuel devs for busting their asses to release this framework, the one criticism I have is one of PR, and the supposed 'community-driven' aspect of it.
I understand this, really. Dan is under a great deal of pressure, as are we all. Most of the developers run several OS projects that have a large following, but when threads like this pop up it's hard not to get frustrate. Fuel already has an amazing community with an IRC already far more active and tolerant than any framework support I know.
Try asking a question in #rails. Chances are you won't even see anybody post for 3 days, and if they reply they'll call you a fking noob.
I have to whole heartedly agree with oskee80 on this one and I feel the need to chime in on it. Jelmer, Phil, you guys are fantastic when it comes to public relations. Dan, not so much. I feel the same way as oskee80; as a mid level developer I do feel a little discouraged about asking questions.
As a framework that is designed for simplicity I'm sure it's going to be an attractive choice for junior to intermediate developers, especially because there is a lot that you can learn from it which I can attest to as I already have. Thank you BTW. But that being said, and as you guys already know, there will be a lot of no0bish questions and seemingly stupid things said simply out of ignorance (Within the true meaning of the word ignorance as in "uninformed or lack of knowledge". Sorry, had to put that in there as I've seen and heard that word get misused a lot). Those questions need to be dealt with professionally. Lest we forget that we were all no0bs once. Never forget where you came from!
Going forward, I would suggest that all PR should be dealt with by you and Jelmer. At the same time though I can understand that that's a whole lot work that you guys would rather not have split between just the two of you. But what else can you do? I know you guys understand.
Anyway, something I know that you guys don't hear enough: Thanks for all of your hard work for giving us a sweet new kickass PHP framework. It really is f*#king amazing and I fall more and more in love with it every time I play with it. As a CI user of 2 years I now feel bored when I have to work on my CI based projects. That's a good thing. Cheers.
Thanks for replying. I can understand how someone who puts tons of time and effort into something can sometimes mistake questions and confusion for criticism. I plan on using Fuel for something soon, and if I have any questions I'll check out the IRC channel.
If the developers are reading this: please for the love of god get a real view/templating engine in there. While you certainly _could_ use raw PHP for your views, it opens up a lot of security concerns and just doesn't have a lot of the features you'd come to expect when coming from other frameworks.
Go look at something like Twig (http://www.twig-project.org/) from the Symphony devs. That's step one I would take before using your project, is to hack it to use Twig templates instead of your views.
And you can't simply throw the Twig classes in app/classes why? Oh ya...no reason. Why should we lock people into a specific templating system? We are working on something for v1.1, but it will still not be core...it will be a package.
You could add Twig into Fuel in the time it took you to write that comment.
I've been using Fuel for a number of weeks now, and I'm generally really liking it. I agree with the Twig recommendation though, and did drop Twig in almost immediately.
To answer your question specifically: it would be smart to use Twig by default, rather than developing your own custom Fuel template engine, because you would need to spend a significant amount of time to get something with the same feature-set, build quality and documentation coverage. Would this time not be better spent elsewhere?
As a pretty content Fuel user, I should also mention that your tone doesn't benefit the project.
Sure, and you could provide zero abstractions to the database (with an ORM) and tell people to grab their own library. For one of the core pieces of MVC, I would hope that you'd actually develop into the V part more.
Your replies to any not purely positive comments or criticism in this thread or elsewhere come off as very abrasive and rude by the way: not the kind of attitude HN expects and is certainly not the way to attract more of a community.
Your framework looks very neat and I'm interested in seeing what it turns into in the coming months/years: don't spoil your reputation before you even leave the gate.
There will be a Parser lib in v1.1 which will allow you to plugin pretty much any templating engine.
Also you won't need to "hack" anything to use Twig with Fuel, the Views aren't loaded when not used. Just use Twig to create your HTML output.
I like the idea of a fresh start in the crowded market of PHP frameworks.. But also, I think that there if you're willing to do the effort to work with something new, you should also try new languages. The web is moving very fast and the nicest projects in github today aren't built in php.
PHP might not be the language of choice if you start hacking a project for yourself. And sure, it has tons of problems and weaknesses but you can't deny one thing: you can very easily get very cheap dev-power when you use PHP.
Sure, those people would also be able to learn Python, Ruby, or whatever the flavor of the month is. But it would take you significantly longer to train them to work on your project. And they might want more money if they realize they now have a more valuable skill ;).
I believe this is why Facebook still uses PHP.
In that light: a new PHP framework that makes things even easier is a good thing.
When people recommend writing web applications in Python, they don't point to the language itself as being better for web development. They point to Django or web2py. Same for Ruby, with Rails. So it's odd that people talk about PHP itself in these same conversations. You can write web apps without a framework in PHP, but I don't think anyone building non-trivial applications is still doing that.
"Tons of problems and weaknesses" is largely untrue at this point. Many of the problems that were traditionally pointed to were corrected in 5 and 5.3. There is no interest in breaking backwards compatibility, so the built-in function parameter order inconsistencies are still valid. Most frameworks work around this issue with an OOP wrapper for array and string operations.
It is difficult to find good dev-power for PHP that's cheap. I've tried. You can find many people who have a basic level of PHP knowledge and refer to web apps as "scripts". Finding people who have an understanding of OOP and modern development techniques is much harder and more expensive.
Here's why I program web apps in PHP: it works and I know it well. If I need a library for something web related, I can assume it will be available as open-source. I don't have concerns that I can make a PHP application scale if I need to. When features don't make sense to implement in PHP, I'll snap them off and implement them in the most appropriate language in the background. Most of the heavy-lifting for web applications typically happens in the background.
I keep hearing about PHP's "function parameter order inconsistencies". Has that ever been a real problem for anyone? Guess not. Auto-completion got your back and it's debatable if these are real 'inconsistencies' anyway. The amount of really really helpful built-in PHP functions for a lot of common tasks more than makes up for this.
Definitely hear you on the lack of PHP developers with an understanding of OOP and all though. Seen it myself when my previous company tried to hire one, the 'range' of people applying is incredible.
Completely getting your point that it could be annoying for some people out there. It never bothered me though and while this is not really a strong argument, it's always one of the first things to come up when people talk about PHP's flaws.
If it really bugs you it could easily be solved with a few helper/wrapper functions.
(Besides that, regarding elegance of syntax, there's no doubt that most other languages used for web dev'ing are lightyears ahead of PHP.)
I think the valid argument here would be that PHP is the cheapest/easiest option for most webmasters out there. When a normal person -- say an artist -- buys hosting, it isn't likely that he'll sit down and set up Python or Ruby. No, he'll upload a copy of Wordpress (on PHP) and be blogging in a couple of hours.
The reason Facebook hasn't migrated away from PHP is because it has incumbent inertia (it's what's there) and Facebook's engineers have managed to work around many of its flaws [...]
I am a big fan of the Kohana framework, but was very disappointed at the direction they took with version 3.0 of that framework. For the kinds of applications I build in PHP, Kohana 2.3.4 was pretty much the perfect framework for my tastes. Kohana 3 changed everything around, lacked documentation, and made things much more verbose for relatively little benefit (to me and my kinds of projects -- I'm sure it benefits others in some way).
This Fuel framework looks like they took Kohana 2.3.4, cleaned up some bugs, added the command line utility and migrations to it, and that's it. Awesome!
Really only one thing that seems to be missing (and maybe it's in there but not in the documentation): how do you put validation in the model, so you're not duplicating model validation in every action that processes submitted form data?
Other than that, I would also agree with what others have said about the tone of the developers -- it's not going to help the growth of the project's community in the long run.
Kohana 3 changed everything around, lacked documentation, and made things much more verbose for relatively little benefit.
This is the major thing that turned me off about Kohana. I loved the original concept - "PHP5 fork of CodeIgniter" - and we actually have it backing our two largest web apps. But I would never recommend Kohana again for a commercial project that is under active development.
Between minor versions there was major API breakage, that wasn't really documented - and was going on in parallel with 3.0 development (think Rails 2 -> 3 with no documentation). For a long time the "Unofficial Kohana 3 Wiki" was actually the only source of documentation for KO3 (even after release).
It seems like the PHP community keeps fragmenting into new PHP frameworks to replace old stodgy (cough PHP4) frameworks (good), with modern design practices (good), but then totally ignoring the community aspect of OS software, documentation, and maintenance.
Yeah, I definitely realize that I'm in the minority with my Ko2 love. It just seems to jive with how I think and arrange things. So I would never say that "Ko3 is terrible" (it's still better than most of the other php frameworks IMO), just that I personally was disappointed because I thought 2.3.4 was perfect for me and my projects and my tastes.
And I will admit that the Ko3 docs are now much better than they were a year ago (well, that unofficial wiki is -- the official docs are still severely lacking).
Does anyone know why Fuel uses a mixture of Zend_Style class naming and namespaces? For example controllers are prefixed by Controller_ and are in the root namespace while tasks are put in the namespace Fuel\Task with no class prefix.
class Controller_Foo{}
namespace Fuel\Task;
class Foo{}
It has nothing to do with laziness. It allows you to override any part of the system without actually changing any of the core framework or module files.
I can't comment specifically on the Fuel framework, but it's probably going to take years (if ever) for "the right" way to use namespaces to emerge among the PHP communities. There's been a decade plus of ingrained name-spacing by convention that PHP developers will need to shed
We actually keep pretty close to that, but have two implementational differences:
1. Namespaces are linked to a specific directory instead of just translated to a path
2. Our paths are fully lowercase
And I stand by those. The first allows for more flexibility when it comes to code organization and the second makes mistakes in classloading a lot less common. You can disagree with these but we have documented them clearly. Also it's quite easy to add another autoloader, ours won't even do a filesystem check when trying to load from an unknown namespace so it should add hardly any overhead to attach a Zend (or anything) compatible loader.
Previous to PHP5.3 (when namespaces were introduced) most frameworks followed the Zend_Style_Of_Naming (That class would be located in Zend/Style/Of/Naming.php).
All new frameworks that support PHP5.3+ (with the exception of Fuel, it seems) have done away with Zend_Style_Naming and follow direct namespace <-> file mapping.
Seriously just curious, what are 'all new frameworks that support PHP5.3+' that are complying to that? And even with namespaces, I guess there are still a couple of ways on how to do this in the file system and handle autoloading. What's the 'standard' then?
The most direct comparisson is CI:
CodeIgniter was a great framework for PHP4 but it is still very much based in PHP4. They may have started to move towards PHP5 with CI2, but they didn't rewrite it with PHP5 in mind. As such the whole architecture is still dictated by PHP4. Also CodeIgniter doesn't have classes autoloading, HMVC, modular seperation, build in ORM, migrations and a lot of other things we felt were very much missing.
The comparisson to Cake & Zend is a bit apples and oranges. Both are hugemongous frameworks in comparisson, especially Cake has a pretty big footprint. Zend is even a whole other approach in the sense that it is more like a collection of loosly coupled classes, while Fuel is a more intergrated framework. I know for example that some have already been using Zend classes with Fuel, combining the large offerings of Zend with the development base we offer.
This is one of my biggest pet-peeves... As a person who is forced to use IE6 at work still, I have come to the conclusion that most sites will not look good in my browser.
Why block your content from people who want to see it; just stop supporting it, put up a blank css file for < IE9, let the site be broken.
Doing this is the easiest way to lose me as a viewer of your website... if I am blocked at work there is no way I would go back to the site once I am home using a modern browser... It just seems silly to me!
I get your point but there is one problem with that approach that has lead me to advise some clients to use such a filter. People like most of us reading here know quite well the evils and shortcommings of IE6, but by far the most people still using IE6 don't. I know it is hard to imagine for anyone here but I have friends whom I had to explain that some non-functional website was due to their prehistoric browser. Telling the public their browser is way too old is far better than presenting them a partially functional non-marked up website. It may annoy you and me, but we're not the public most webdesigners should care about.
Now to our own site disallowing IE7 while being targetted at web professionals. Pretty much no-one doing serious web development will be limited to IE6/7 - let alone use it as their primary browser. If you do and your employer is short-sighted enough to keep at IE6, you'll be part of a very very tiny minority which will most likely still not have access to PHP5.3 either.
Second this. I am currently so fed up with catering to all sorts of browsers and their incompatibilities and shortcomings that I think a 'stop caring' approach along with 'go somewhere else then' is becoming the only way to preserve my own sanity, as long as the given project/task allows it.
Sigh. To avoid further downvoting, I may add that the 'blank css' approach makes more sense than the 'go away' one.
But I was thinking of things like the different browser (HTML5) Audio APIs 'we' are facing right now and my point was that you are probably better off just focusing on getting things right in one environment first before spending too much time on 'making it work for everyone'. Which is 'overrated' anyway, depending on the project. Just think of how Beatport.com is entirely based on Flash which is still the most convenient way of adding audio.
I know little about Fuel (just discovered it today), but my take on it is that it is pretty much exactly like Kohana 2.3, but less complex and verbose than Kohana 3 (because Ko3 changed so much from 2.3).
Symfony/Symfony2 is a much more heavyweight framework -- much more "enterprisey", which I don't mean in a bad way -- the Symfony folks seem to have a much better understanding of OO patterns and best practices than most PHP folks, and if you're building a very large app that needs to be scalable, extendable, etc., Symfony is the way to go. But for more straightforward CRUD apps or sites without humungous user bases or numbers of pages, Kohana/Fuel is a better fit, IMO. The usual lightweight vs. heavyweight tradeoffs.
I would like to clarify something: We're not exactly (or pretty much exactly) like anything. Some small parts may have been taken from other frameworks but the whole application flow (Request, Response), autoloader and most of the classes were written from scratch. Being (partially) responsible for classes like Validation, Form, Cache, ViewModel and packages Auth & Orm I can be very clear that while inspiration may have been drawn from many sources they were build specificly & uniquely for Fuel without being ported/rewritten/copied from anything.
We do use slightly modified versions of Kohana's querybuilder & View classes (something we're very upfront about, and from Ko3 btw not Ko2.3) but the framework by and large was build by us originally. And if parts were taken from other frameworks it is mentioned explicitly in the code, but those are the exceptions rather than the rule.
Apologies if I am misrepresenting the project (as I said, I know very little about Fuel, just discovered it via this thread) -- didn't mean to put you on the defensive.
I didn't look at the underlying code at all, just browsed through the docs and to my eyes the "API" or "structure" of Fuel looked very similar to Kohana, which is a HUGE compliment coming from me, as Kohana is (was?!) my favorite PHP framework. Definitely not accusing anyone of stealing code -- just trying to answer the guy's question. I don't think anyone could argue that if you compare Fuel to Kohana and Symfony [as was the question], Fuel is WAY closer to the Kohana end of the spectrum.
Anyways, I'm really looking forward to trying this out on my next non-CMS project -- thank you for creating this.
I haven't had time to have a good look at this, currently I use CodeIgniter, but I'm always open to change, so I'll grab a copy later and play around with it.
The development team (of which I am one) all come from the CodeIgniter community and have built lots of applications and sites using CodeIgniter. The Fuel site runs on PyroCMS, which I also develop as both Fuel and PyroCMS belong to the same company. There's no point us developing a brand new CMS just to run the website for our brand new framework right?
Yes we've been perfectly open and honest about every sigle class or library that has been taken from another framework. We have several of the Kohana developers hanging out in the #fuelphp IRC channel and we all get along just fine, so no issue there. If something works well, why change it? :)
Fuel is fantastic, if unfortunately I was going to have to code in PHP I would probably use it as Fuel is really inpsired by Rails e.g. $ php oil generate migrations...
There are dozens of PHP frameworks inspired by rails, it's not remarkable.
Symfony (which Delicious 2.0, Yahoo! Answers, Yahoo! Bookmarks, Dailymotion v2009, etc. were built on) has a CLI too ("symfony doctrine:migrate"), and is 5+ years old.
Yahoo used a stripped down and customised version of Symfony (called ysymfony). As far as I recall they stripped out the Model part of symfony - so the entire Propel/Doctrine stuff. Answers for example, wrote their own data query/persistence.
So although you mention doctrine:migrate - Yahoo were not using it on Answers, and if Delicious, Bookmarks and Daily Motion were using the Yahoo version of symfony, neither were they.
You don't even have to "strip anything out". It's modular by nature. W3Counter (one of my sites) was built on Symfony and doesn't use Propel or Doctrine either.
Sorry Phil, going to correct you a little bit here ;-) It actually wasn't ported over. It was written by Alfie and I did a big rewrite on it before committing.
Right you are, but Alfie based this almost directly on CI. You recoded some of it, but the initial purpose and feeling of the class remains as essentially a copy of the CodeIniter Helpers. The sort of thing that is so similar it was just easier to call a port. :)
Don't take this as any legit comparison, but from my perspective: Fuel is at 1.0 RC1 as of right now, although it has only been started a few months ago. Lithium has been in development for ages (since 2009) and it seems like it hasn't seen a lot of action lately, the last blog post on http://lithify.me/ being from November 2010 and the last packaged download being 0.9.9 from December 2010. (Didn't check the activity on the repos.)
That doesn't tell you a lot about the quality or reliability of the framework and what's to come but personally I prefer the "let's get this out there" approach over borderline vapourware.
Besides that, browsing the FuelPHP forum it looks like people are already busy adding functionality through plugins and the team seems to be helpful and embracing it. So they've definitely got 'momentum'.
Also the 'docs' on FuelPHP seem to be pretty 'complete' at first glance, also giving me the impression that they are totally up-to-date while I can't even figure out where the proper 'docs' for Lithium are. They don't seem to have things arranged for 'being in the spotlight' yet.
And I can't comment on what's going on under the hood really, as I am more interested in 'libraries' that are not depending on any framework these days.
But as far as I can see, FuelPHP is sitting there for you along with current docs and a dedicated team to try out and give it a shot.
We use any product that makes sense. Should we be forced to develop an issue tracker in Fuel before launching the framework? And a CMS? And a forum? :)
A lot of people are complaining, and saying things like we don't use namespaces properly. My response: Then don't use the framework. I started the framework because no current framework met my needs. Here are some of the reasons I did not simply use an existing framework:
CodeIgniter - Slow to evolve, requires a lot of code for simple things, nothing autoloaded (don't even try to mention the autoload config file.
Symfony2 - Over-complication of menial tasks, kind of slow.
CakePHP - Slowest (php) framework known too man, bloated, need I say more?
Zend - Slow, bloated.
Yii - Just don't generally like the syntax.
Kohana - There isn't much I don't like about Kohana actually...other than its not PHP 5.3 yet (not going into specifics on why this is bad).
DooPHP - Not full-featured-enough.
I also wanted things like HMVC (i know some of the above support it), Modular Routing and a few other things.
To the guy that said he was turned off by the Html class: if you don't want it, don't use it, stop whining.