The next promising framework : Laravel

September 4 2012, 7:33 AM  by Frosty Z

Bad luck with Symfony. Its 1.x branch was very nice and promising, but has been given up, in favor of the Symfony 2.x big bloat (still growing).

Browsing sometimes the excellent StackOverflow Q&A site is a very good way to stay informed of the frequently used technologies.

This way, I’ve just discovered Laravel.

A quick look shows a very promising piece of work. I hope that it will be correctly maintained (decent BC, no “cargo cult” shifting…)

Agile annoyances

May 15 2012, 8:55 AM  by Frosty Z

I’m fed up of hearing coworkers and other teams speaking a language that I can’t understand, just to say the exact same thing that I could understand if spoken in the “old, outdated language”.

This is just plain common sense, wrapped up in a new trendy vocabulary.

If you want to spend your time more intelligently than attending to an Agile/Scrum seminar or certification training, just read this :

Enough time lost with that marketed hype.

EDIT 29 dec. 2015 – see also :

Are web development frameworks still immature ?

February 20 2011, 9:59 AM  by Frosty Z

Just another rant that nobody will read, but at least I will feel better after writing it…

One year has passed since my last post. The so-called Symfony 2 should be released next month, and nothing has changed. Its core team seems, as always, deaf to simplicity and backward compatibility aspects.

Following an interesting comment, I’ve decided to check again Ruby on Rails. Very nice piece of work too, but like Symfony, a very dumb policy for migration between versions. If you want to upgrade a project fromRails 2.3 to the new shining Rails 3, you can choose between spending at least one hour and $9 for an online video, or spending $6 for “Almost 120 pages of upgrade information” (!!??), and obviously, an incredible amount of time for boring and useless rewriting.
At least, unlike Symfony, some people keep migration in mind (if you accept to spend time and money for it), anyway if I were a long-time RoR user, I would feel laughed at.

CakePHP seems to be struck by the same disease. Look what boring stuff you will have to face to migrate from 1.2 to 1.3 minor versions.

That disease has a name : Planned Obsolescence. But I’m not sure that web developers (and their employers) will still blindly follow a such immature and profit-oriented project policy, applied to Open Source web frameworks.

Edit :
– Kohana : painful migrations too… example1(!!) example2
– CodeIgniter : more interesting although not perfect… see this and that.

Symfony 2.0 preview

February 24 2010, 10:27 AM  by Frosty Z

I’ve just had a look at Symfony 2.0 preview, and viewed its presentation at the Symfony Live conference.

Did you enjoy migrations with Symfony 1.x versions ? Do you have some additional months to waste ? Rewrite your apps for Symfony 2.0 !

Just look at the preview of what you will have to relearn, and how you will have to rewrite your code. That’s the price to pay, if you dare think about migrating your applications to benefit from Symfony 2.0 improvements (like performance). Indeed, backward compatibility seems to be the last matter Symfony core team pays attention to.

Did PHP developers kill BC from version 4 to 5 ?…

You’ve been warned : Symfony is a framework for professionals… in code rewriting.

Symfony and backward compatibility

December 8 2009, 7:15 AM

Symfony is a really good and very, very useful piece of work.

But sometimes, I feel that all the time saved by the framework becomes wasted in upgrade processes, because of very poor backward compatibility.

Unlike major PHP versions, you simply can’t expect that your project using Symfony 1.0 will work on the next minor versions without hassle!

Examples of significant changes:

  • ORM (Doctrine will permanently “replace” Propel in Symfony 2.0 and is already the default ORM since 1.3). Fortunately, the plugin DbFinder exists…
  • Forms management (validation…)
  • Email sending (sfMail for 1.0, then Swift_Mailer for 1.1 and 1.2, then a new class based on Swift_Mailer for 1.4, but requiring to use ‘raw pieces’ of Swift_Mailer like Swift_Attachment !)

As well, look at the huge documentation you have to follow if you want to upgrade from 1.0 to 1.4 (at least, it exists, but I found it sometimes incomplete)
Upgrade Symfony from 1.0 to 1.1 (difficult to reach on Symfony website)
Upgrade Symfony from 1.1 to 1.2
Upgrade Symfony from 1.2 to 1.4

This is very boring, leads to pure time waste, even if a few things are automated by the “project:upgrade1.x” task, and newcomers could think that the framework is immature and amazingly complex.

IMO, developers using a framework shouldn’t even bother if they are using PropelDoctrineSwift_Mailer or AnyBeautifulThirdPartyClass. They simply want to create forms, manage data in the database, send mails etc., whatever occurs behind the scenes.

Instead, too much new features / concepts / third party elements are regularly killing backward compatibility, leading to unjustified complexity for upgrades and “relearning” time to use some existing features.

I know that Symfony’s audience is web developers, who should be technically “aware and up-to-date”, follow Symfony’s recommendations, good practices and coding standards, etc.

But, please keep this great framework simple, to avoid extra heavy efforts for learning and upgrading.

I’ll try to contribute as much as possible in that direction (if I have time between two upgrade processes ! :-p).

About PHP closing tag “?>”

Just my two cents about this debate. To summarize :

Always keep the closing PHP tag “?>” for files containing only PHP ?



  • Avoids headache with adding inadvertently whitespaces after the closing tag, because it breaks the header() function behavior… Some editors or FTP clients / servers are also known to change automatically the end of files (at least, it’s their default configuration)
  • PHP manual says closing tag is optional, and Zend even forbids it.


I would say that the arguments in favor of omitting the tag look stronger (helps to avoid big headache with header() + it’s PHP/Zend “recommendation”). I admit that this isn’t the most “beautiful” solution in terms of syntax consistency, but I can’t find anything better.