#1 Mature and consistent #2 An active and friendly developer community #3 Does not break backward compatibility every few months (I am looking at you Laravel 5)
T On Wed, Oct 1, 2014 at 3:55 AM, Reuben Helms <[email protected]> wrote: > My 3 reasons: > > 1. CakePHP can integrate with legacy code. It only takes a little bit of > fiddling, but it was one of the primary reasons I went for it. > 2. Convention over configuration, but not at the expense of no > configuration. Working with legacy databases, it was good that Models in > CakePHP could be configured to work with tables that didn't fit the ideal > convention. > 3. Documentation / code readability. Whilst separate, if I can't work out > how a feature works in the documentation, I can go to the code and work it > out from there. With the exception of the events system, I find the code > easy to read and navigate. > > Those are 3 that come to mind. Now that I've been using it for several > years, there are additional reasons to stay, like my investment in > learning, community, approachability of the core team. > > On Tue, Sep 30, 2014 at 6:28 PM, José Lorenzo <[email protected]> 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 <[email protected]> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 a topic in the >> Google Groups "CakePHP" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/cake-php/NXgTsZ0COjc/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/cake-php. > For more options, visit https://groups.google.com/d/optout. > -- ============================================================= Hire a CakePHP dev team : http://sanisoft.com ============================================================= -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/cake-php. For more options, visit https://groups.google.com/d/optout.
