
Fuel - A simple and flexible PHP Web Framework  - fosk
http://fuelphp.com/
======
dhorrigan
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.

~~~
jpcx01
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.

~~~
jschreuder
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.

------
oskee80
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.

~~~
philsturgeon
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 f __king noob.

~~~
clarkgriswold
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.

------
Pewpewarrows
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.

~~~
dhorrigan
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.

~~~
datasink
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.

------
cvander
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.

~~~
michh
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.

~~~
datasink
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.

~~~
soulclap
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.

~~~
waterlesscloud
The inconsistencies are just more mental friction. It's not a huge cost, but
it's no benefit either. If you can avoid such friction, why wouldn't you?

~~~
soulclap
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.)

------
jordanlev
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.

~~~
jimktrains2
I actually like Ko3 a lot better than 2.x. It just seems to jive with how I
think and arrange things. The docs are constantly getting better too.

~~~
jordanlev
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).

~~~
jimktrains2
Yeah, Ko2.x was pretty nice as well. You could always fork it an maintain it
with all the other misfits;) (I kid I kid (about being a misfit))

------
lastkarrde
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 seems confusing.

~~~
alanstorm
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

~~~
jasonlotito
There is already a standard.

[http://groups.google.com/group/php-
standards/web/psr-0-final...](http://groups.google.com/group/php-
standards/web/psr-0-final-proposal)

Voted on back in 2009 by members of Solar, Cake, Doctrine, Zend, Symfony,
Typo3, PHP Core, Yahoo! and others.

~~~
jschreuder
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.

------
twidlit
I wanna know what is the one thing it is aiming for? simplicity? speed (ala
Yii PHP framework)? or modularity? Its not clear on any of the page...

~~~
oldstrangers
Judging by their constant use of the words 'simple' and 'flexible', I'd assume
simplicity and flexibility.

~~~
twidlit
Honestly curious, are existing PHP frameworks hopelessly complex and rigid to
have this problem?

~~~
iconfinder
In my experience Code Igniter does a very good job at being flexible, simple
and fast.

Perhaps they should have a page explaining how Fuel is different from Cake,
Zend and Code igniter.

~~~
jschreuder
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.

------
garazy
For users of IE7 and below visiting the site will take you to
[http://www.microsoft.com/windows/internet-
explorer/default.a...](http://www.microsoft.com/windows/internet-
explorer/default.aspx)

That's the worse degrading browser support I've seen :)

~~~
philsturgeon
Why would we care? Get a proper browser. IE9 is out.

~~~
joshfinnie
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!

~~~
jschreuder
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.

------
philfreo
I would like to hear how this specifically differs from say Kohana or
Symfony2, both of which are PHP5 only and have good communities already.

~~~
jordanlev
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.

~~~
jschreuder
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.

~~~
jordanlev
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.

------
alanstorm
Anyone know if this is related to the Fuel CMS (<http://www.getfuelcms.com/>)
or are they separate projects?

~~~
lastkarrde
Separate projects. Fuel CMS is powered by Code Igniter 2.

------
petervandijck
I've been using Fuel for <http://gethirely.com> (almost ready to go out of
alpha). It's pretty good.

------
MattBearman
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.

I found a broken link though - <http://fuelphp.com/docs/classes/agent.html>
and the error page looks a lot like CodeIgniter/Expression Engine :S

~~~
philsturgeon
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?

------
samgranger
The examples are really similar to Kohana, especially view factory. Did you
use pieces from it? And is this a MVC or HMVC framework?

~~~
philsturgeon
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? :)

------
alexlawford
(Sincere question) why would someone use Fuel over, say, Codeigniter?

------
defied
The advertisement at the beginning of each screencast is annoying.

------
denysonique
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...

~~~
dangrossman
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.

~~~
Isofarro
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.

~~~
dangrossman
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.

------
ibernat
What put me off is the useless Html class. You have a method named H which
produces the H(1,2,3..) tag. How is this useful in any way?

~~~
philsturgeon
This was ported over from CodeIgniter which has a few crazy Hellers for this
sort of thing. I wrote an article explaining the benefits:
[http://philsturgeon.co.uk/blog/2009/12/Why-CodeIgniter-
HTML-...](http://philsturgeon.co.uk/blog/2009/12/Why-CodeIgniter-HTML-helper-
functions-rock)

Remember though, that class won't be loaded unless you want it.

~~~
jschreuder
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.

~~~
philsturgeon
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. :)

------
agotterer
The Lithuum project looks like a promising PHP 5.3 framework from some ex Cake
developers. What is different about Fuel?

~~~
soulclap
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.

~~~
greut
Finishing the ORM seems to be the biggest deal right now, you can have a look
at the roadmap (<http://rad-dev.org/lithium/wiki/about/roadmap>).

The links you are looking for:

• documentation (javadoc-style): <http://lithify.me/docs>

• drafts (book-like): <http://dev.lithify.me/drafts/source/en>

• community: irc://irc.freenode.net/#li3

They are hard to find, I agree.

------
divcraft
Funny it uses Redmine a RubyOnRails based issue tracker for managing bugs

~~~
philsturgeon
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? :)

