@Peter:

I struggled with that problem too, being used to the flexibility that PHP gave you. However, it's been my experience that the flexibility people crave is out of a belief that their requirements are unique, when in fact they tend to not be as unique as previous thought. Rails makes you work within a structure and if you work WITH that structure instead of AGAINST it, good things tend to happen.

That said, I also believe that Rails lets you build things that have already been built, so it's not really covering new ground. It's just letting you build stuff faster by providing structure and a whole bunch of helper tools to generate code you had to do by hand OR create your own tools.

I'm not abandoning PHP by any means, I'm just embracing the idea of frameworks and using conventions to speed up my work.

Frameworks are an interesting topic for me right now as I am currently actively writing one. This might seem like a strange thing to do I know, considering how many quality web frameworks are already out their, but like you Lukas I also found the learning curve with many of the frameworks was outweighing any perceived benefit of re-using somebody else's code, at least initially anyhow.

Not conventional wisdom I know, but it works for me ;-)

With regards to convention over configuration, I agree with you that conventions can seem strange at first: things "just work" but it might not seem clear why; but I prefer the inflexibility of a structured convention-based approach over the infinite flexibility offered by many larger applications, especially I have found this complex configuration approach common in many of the Java applications which I have worked with during my day job (both open source and commercial), which can often leave you in XML configuration hell.

I guess Rails and their ilk are trying to break away from this configuration overhead, but it is certainly at the cost of flexibility and some confusion when you first start to use such a framework.