is it true "All PHP Frameworks Suck"??

[eluser]Unknown[/eluser]

Recently, Rasmus Lerdorf, the creator of PHP, stated in a PHP frameworks conference that all PHP frameworks suck.

He also answered several interesting questions about the present and future solutions in PHP 7 or beyond.

Read this article to learn more about Rasmus said and the what it means for the way you develop PHP now and in the future.

For more please read this All frameworks suck

Is It Realy True?? What is your idea??

[eluser]CroNiX[/eluser]
Who cares what he says? He also says that OOP sucks and he never wanted PHP to have it in the first place. If it were up to him, we'd only have procedural code.

BTW: he also said at one time that out of all of the frameworks, he liked CI the best.
http://www.sitepoint.com/rasmus-lerdorf-...ink-again/

So, are there any frameworks that don’t suck? Rasmus did mention that he liked CodeIgniter because it is faster, lighter and the least like a framework.

[eluser]jonez[/eluser]
[quote author="CroNiX" date="1391706312"]Who cares what he says? He also says that OOP sucks and he never wanted PHP to have it in the first place. If it were up to him, we'd only have procedural code.[/quote]
That's an interesting topic of discussion. One of the best developers I know hates OOP too. It's such an odd thing to hear someone say. I love objects and could never go back to writing only procedural code.

I've been working with C a lot lately for an Arduino home project. I have never missed objects and type inference so much!

[eluser]CroNiX[/eluser]
Well, procedural will always be faster, more efficient and consume less memory than objects. Try benchmarking an ORM against native SQL (or a simple query builder like CI uses) under a heavy load, which is why I will never use one unless it's a requirement. I'm more concerned about efficiency than ease of coding for the developer, but I don't work on small websites and always need to think in terms of large scale. There are usually about 1k visitors on the main site I work on at any given time and growing all of the time (it's a national real estate company). If I used an ORM, I probably would have had to use a beefier server to accommodate the overhead, which costs more and does absolutely nothing for the end user. Just so the code is easier/prettier to write, which is usually written only once? No thanks.

[eluser]jonez[/eluser]
[quote author="CroNiX" date="1391795231"]Well, procedural will always be faster, more efficient and consume less memory than objects. Try benchmarking an ORM against native SQL (or a simple query builder like CI uses) under a heavy load, which is why I will never use one unless it's a requirement. I'm more concerned about efficiency than ease of coding for the developer, but I don't work on small websites and always need to think in terms of large scale. There are usually about 1k visitors on the main site I work on at any given time and growing all of the time (it's a national real estate company). If I used an ORM, I probably would have had to use a beefier server to accommodate the overhead, which costs more and does absolutely nothing for the end user. Just so the code is easier/prettier to write, which is usually written only once? No thanks.[/quote]
ORMs hissssss! I think the same way. The queries they throw out are a mess. I'm sure they will get better in time but I'd never use one by choice. Straight SQL all the way!

OOP isn't necessarily slower, less efficient, and the memory difference in JavaScript is minimal. In JS function prototypes do not consume memory per instance. Each object instance consumes memory to hold it's properties, but all the object's methods are shared in memory just like procedural code. You have the extra overhead of scoping but that can be overcome with closures and self references. The majority of poor performing JS is using jQuery over pure methods (when possible), poorly planned selectors, and browser repaints from using live appends over document fragments.

I've never found PHP slow. Not that PHP code can't be slow, but it's usually poorly thought out loops or too much disk activity that bog it down.

[eluser]InsiteFX[/eluser]
The best way to speed up PHP is to refactor the sections of code that are slow using a good profiler, also caching will really speed up PHP but each cache has its downfalls and ups.

[eluser]stevezissou[/eluser]
He is arguing against "general purpose frameworks" and the overhead they bring...but he is not saying "don't use a framework". The argument stems in part from the "Java-fication" of PHP frameworks that's happened over the years.

For your own sanity and everyone else working on your project, use an established framework like CI, Laravel, Rails, Django, et al. Rolling your own framework is not something you need to focus on except in edge cases. Your bottlenecks will be elsewhere before you need to start hacking together your own custom framework.