Rasmus Lerdorf : "All PHP Frameworks Suck"

[veedeoo]

For years, I have been waiting to hear Rasmus Lerdorf to share his words and opinions about many things around PHP, especially the security issues, PHP frameworks, future versions, and password hashing. At last, he attended the PHP Frameworks Day 2013 and I was surprised by his thoughts about PHP Frameworks( They were precise and concise assesments).

I am not going to elaborate on what the creator of PHP said during his presentation at the PHP Frameworks Day 2013. The linked video will provide some interesting information about the progress in PHP.

Rasmus Lerdorf expessed his thoughts, opinions and plans.

1. Must upgrade from PHP 5.3 to current version.
2. Why APC was out of the picture in favor of Zend Opcode Cache?
3. Why "All Framework Suck"?
4. Frameworks execution of the same code repeatedly. General framework does not apply to all.
5. PHP's non-blocking I/O programming support via libevent extension.
6. Unicode and JIT for future PHP 7 version.
7. Using Go programming language.

Regardless, if you are inexperienced or experienced developer, I think this video is worth watching. The video is more than 40 minutes long.

Please share your thoughts about the video.

Loved it. Framework devs must hate him though:)

I can't pretend to have understood it all though.

So far I havent used any framework, and it seems like I did right thing.

One thing I will say for them, at least they give you a decent idea of how MVC could be implemented (well some of them anyway). But I generally find them to be quite heavy for my needs - I don't need the kitchen sink as a rule.

Defo check this out tomorrow.

I'm in two minds about frameworks... To some extent I can see them interfering, but I haven't really got my head around MVC yet. I guess if I stuck with it I would have a different opinion.

Well, they can save you a lot of time - once you've managed to cling on to what is sometimes a very steep learning curve. Symfony almost gave me a brain haemorrhage. :(
Unfortunately some fo them just insist on doing everything "their way" - for example, getting xgettext to work with Laravel was a two week project. I needed xgettext more than Laravel, so guess which one I jacked.

[gabrielcastillo]

Hey, was anyone ever able to find the slides? I when to the url provided but got nothing.

[cereal]

Yep: http://talks.php.net/show/phplondon13/

To browse through the slides use the keyboard arrows. Note I suggest Firefox to browse them, Chrome seems to not work fine.

[veedeoo]

That's very true of Symfony 2. Even worse with the Zend framework, because I have to starved myself in college just to be able to pay for my Zend Framework Certification. It cost me a fortune just to get it.

In practice, I prefer lighter frameworks where I can choose the modules I need. Pretty much assembling my own from the packagist.org. I really admire the idea behind the Dependency Management for PHP by Composer, because it allows me to do this.

However there is a minor catch here.The only reliable autoloader, class loaders, and router are coming from the Symfony packages, which is to me is another overload or unnecessary instantiations of many classes during the initialization process. Even Laravel uses some modules from the Symfony packages.

I tried different routers from packages.org via composer, but most are just not the same as the ones that are with Laravel, CI, Kohana, and Symfony.

Here is the simple composer.json file I am currently using when creating my own framework. This is pretty much the basic foundation of a framework with a template engine smarty or twig ( must assign twig in require and remove smarty on the autoload block). Rasmus also talked about similar to this approach and favored this over the full framework.

    {

"require": {
    "symfony/class-loader": "2.4.*@dev",
    "symfony/http-foundation": "2.3.*@dev",
    "phpunit/phpunit": "3.7.*",
    "swiftmailer/swiftmailer": ">=4.2.0,<4.3-dev",
    "doctrine/orm": "2.3.4",
    "symfony/routing": "2.5.*@dev"
},
"autoload": {
    "classmap": [
        "vendor/smarty/smarty/Smarty.class.php", 
        "vendor/smarty/smarty/SmartyBC.class.php"
    ]
},
"autoload":{
    "classmap":[
    "vendor/veedeoo"
    ]


},
"minimum-stability": "dev"

}

For twig template engine,

"require": { "twig/twig": "1.15.*@dev"}

The downside as Rasmus mentioned on the video is demonstrated by the Symfony autoload which is a page with hundreds of entries, and these files I believe are loaded during the initialization process. I might be wrong on this, but the only way to alleviate these not needed instancies is to create a simple PSR 0 compliant loader class and a simple Singleton instantiator class.

Overall, I think CI and Kohana got the upperhand when it comes to speed. I just can't believe that Ellis Lab don't want anything to do with CI anymore.