My reasons are more practical than technical, but still very relevant:

1. Familiarity
2. Speed to get-go
3. Well maintained/supported

Without deep knowledge of other frameworks it's hard to come up with technical 
arguments, but I'd love have them in my armoury.

- Jeremy

On 30 Sep 2014, at 09:28, José Lorenzo <jose....@gmail.com> wrote:

> Before giving my own view into this problem, you you guys list the reasons 
> why you think CakePHP is a cool or productive framework to work with? Just 
> give me 3 reasons, no comparisons with other frameworks
> 
> On Tuesday, September 30, 2014 6:24:30 AM UTC+2, Jeremy Burns wrote:
> This is so true. I'm a huge fan of Cake but we do feel like the whipping boys 
> sometimes. I recently hired someone into a project and the first thing he 
> tried to do was change the framework for a whole bunch of vague reasons like 
> 'Laravel is just so much better'.
> 
> Perhaps someone can devise some simple benchmarking challenges that the 
> guardians of the various frameworks can take up themselves and then compare 
> the actual results, rather than letting a random person do it out of the box. 
> A competition, if you will. So, for example, write a thousand records to a 
> database, read them back, perform some function and render them to screen. 
> Yes, yes, I know there would need to be some element of a level playing field 
> with server spec and the like, but it could be done. Then each framework can 
> show it's own best efforts and - importantly - will have no excuses about not 
> understanding the framework or setting it up correctly.
> 
> I haven't had a 'job' for the past six years, but on the odd time that I 
> decide a regular income would be nice I rarely - if ever - see CakePHP as a 
> requirement. It's always Symfony, Zend, Drupal, Code Ingniter, sometimes 
> Laravel, sometimes ROR and sometimes something else. That's awkward and I 
> just can't help wondering if I am swimming against a tide. Perhaps everyone 
> else is right and I am wrong? TBH, I'm not clever enough to be able to 
> explain why Cake is the right choice compared to others; some help there 
> would be cool.
> 
> On 30 Sep 2014, at 00:43, Reuben <reuben.he...@gmail.com> wrote:
> 
>> My apologies, dereuromark, for the incorrect spelling of your handle.
>> 
>> On Tuesday, 30 September 2014 09:40:31 UTC+10, Reuben wrote:
>> The few times that I've seen CakePHP compared to other PHP frameworks is in 
>> performance tests, and it never looks pretty.  Usually the test is a very 
>> simple Hello World test, or an action that reads/writes a bunch of records 
>> to the database.  Not really real work tests, and no effort to configure the 
>> application to make sure it's doing the best that it can (i.e. appropriate 
>> cache options, etc).  
>> 
>> There have been a few articles written on CakePHP and performance, and all 
>> the stuff you can do before complaining about the framework itself.
>> 
>> Unfortunately, when people are comparing PHP frameworks, they just look for 
>> that performance index, and don't take too much notice of the merits of the 
>> performance test taken.
>> 
>> My perception is that at last check, there might be room for improvement in 
>> the event model, but I don't do all the other things that can be done to get 
>> better performance out of CakePHP, before going there, so it's never been an 
>> issue for me.  I also understand that start up times have been improved with 
>> CakePHP 3, and the routing configuration required.
>> 
>> Of course, CakePHP is more than just performance of the framework.  The 
>> documentation is great, the community is great and the core development team 
>> are very approachable, via groups, irc and github issues. And the code 
>> itself, should you need to look at it, is very readable.  The only part that 
>> makes my brain hurt a little is the event system, especially when trying to 
>> work out, when this event is fired, what is listening for it in the CakePHP 
>> core.  
>> 
>> Maybe there could be some articles written about the CakePHP core, to make 
>> TheBakery a little more attractive to read. I'm more likely to read CakePHP 
>> articles from Mark Story, AD7six or deuromark than peruse the 1 or 2 
>> paragraph articles on TheBakery.
>> 
>> Regards
>> Reuben Helms
>> 
>> On Tuesday, 30 September 2014 07:15:54 UTC+10, Florian Krämer wrote:
>> In the official CakePHP Facebook group Yanuar Nurcahyo asked about opinions 
>> on that link 
>> http://www.quora.com/Why-isnt-Cakephp-popular-despite-being-one-of-the-earliest-php-framework-to-be-written
>> 
>> I'll quote my own comment I've added to that posting:
>> 
>> I'm a little shocked about the wrong information people spreading there as 
>> well as the amount of false information. Especially the one that got 4 
>> up-votes. Most of the answers there read like FUD or written by people who 
>> can't or won't read documentation. Also I really don't get why people always 
>> "need" bleeding edge php support. There is no urgent need or do you migrate 
>> you app / server to a new php version just because it's cool? The only 
>> problem that CakePHP has is an image problem.
>> 
>> What I would like to discuss in this thread is reasons and solution to them. 
>> Why has CakePHP such a negative perception? The thing that bothers me 
>> personally the most is why the *uck do people say it has a bad 
>> documentation? Seriously, I don't get it. Can't they find the documentation? 
>> Can't they use it? Or is it really just FUD by some <random-framework> 
>> fanboys?
>> 
>> The "stone age php version" isn't a very valid argument IMHO. Yes, I agree, 
>> CakePHP felt behind other frameworks for at least ~2 years and I've missed 
>> the namespace support more than one time. But that was really the only 
>> language feature I was really missing. Everything else is sugar on top of 
>> the cake. I don't know if other people update their servers and apps for fun 
>> and if they do the required testing for free for their clients...but well, 
>> looks like some guys out there have more a cowboy-coder attitude than a 
>> professional one.
>> 
>> Also I don't get why people complain about the architecture of CakePHP, yes 
>> it is different, yes it gives you everything out of the box and isn't a 
>> package made of 100 loose libs and then glued together. This is IMHO 
>> actually an advantage and makes it easy to get started with it. And 
>> seriously, how often do you change the ORM stack of <random-framework> in 
>> reality? And on top of that, CakePHP 3.0, as far as I can tell, is more 
>> decoupled than 2.0 was. For example the face pattern in Laravel is, as far 
>> as I've worked with it and understood it, just one way you can use for 
>> dependency injection. The face seems to works like a proxy. I might be 
>> wrong, I haven't spent much time with it yet. SF2 is using a container 
>> object to deal with the dependencies. However, my point here is other 
>> frameworks appear to be more fancy and by this attract people who are 
>> looking for fancy things, "interesting" design patterns and architecture. 
>> Which brings us back to the cowboy-coder attitude. Something doesn't has to 
>> be fancy to just work.
>> 
>> I know that for example Symfony gets a lot attention and exposure through 
>> having virtually one domain per component of their framework and a nice 
>> design for these sites and for whatever reason Symfony manages it somehow to 
>> get massive funding. Creating all these pages and a fancy design takes time 
>> and money. So I don't think doing something similar would be an option for 
>> CakePHP. Honestly I have no ideas what could be done to help making CakePHP 
>> look better (and stop these silly guys from spreading FUD). I would not mind 
>> all their critics at all if they would bring valid and detailed arguments. 
>> But everybody complaining about CakePHP is just repeating other peoples FUD 
>> about a bad documentation and not exactly mentioning what is wrong with the 
>> architecture. Going into a discussion is like going into a fight without a 
>> weapon. But well, the problem here is nobody fights these false "arguments". 
>> :(
>> 
>> I personally don't mind using Symfony2 or Laravel, they're good frameworks 
>> as well, but I don't think that CakePHP 3.0 has to hide in any aspect, nor 
>> had Cake2 when it was new. But CakePHP has a completely different philosophy 
>> than SF2 and Laravel, obviously one that people are not used to.
>> 
>> So, has anyone constructive critics about that? Maybe others here don't even 
>> think CakePHP has a problem with it's perception?
>> 
>> -- 
>> Like Us on FaceBook https://www.facebook.com/CakePHP
>> Find us on Twitter http://twitter.com/CakePHP
>> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "CakePHP" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to cake-php+unsubscr...@googlegroups.com.
>> To post to this group, send email to cake-php@googlegroups.com.
>> Visit this group at http://groups.google.com/group/cake-php.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> Like Us on FaceBook https://www.facebook.com/CakePHP
> Find us on Twitter http://twitter.com/CakePHP
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "CakePHP" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to cake-php+unsubscr...@googlegroups.com.
> To post to this group, send email to cake-php@googlegroups.com.
> Visit this group at http://groups.google.com/group/cake-php.
> For more options, visit https://groups.google.com/d/optout.

-- 
Like Us on FaceBook https://www.facebook.com/CakePHP
Find us on Twitter http://twitter.com/CakePHP

--- 
You received this message because you are subscribed to the Google Groups 
"CakePHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cake-php+unsubscr...@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.

Reply via email to