csn wrote:Yup, I agree--apples and oranges.
But saying MVC is the responsibility of the programmer writing the app is a stretch. Why reinvent the wheel AGAIN and spend lots of time doing so? And most programmers probably aren't up to the task of writing their own MVC framework, and one that's better than existing ones no less. I'd bet most devs choose to use MS's MVC framework for Windows rather than write their own from scratch.
Well, I guess I'm an old-school programmer who reckons programmers should be capable of programming.
"Yup, I agree--apples and oranges. "
No, not quite. I did think the analogy through instead of just trotting out the clichΓ©. Apples and oranges would be a category error. Which is what I was pointing out that comparing PHP to Rails was. An appropriate comparison would be between PHP and Ruby, or between Rails and Zend Framework. Or Rails and Symfony. Or Django and Symfony. Or CGI.pm and Django. Or Perl and Python.
"Why reinvent the wheel AGAIN and spend lots of time doing so?"
So why do new frameworks keep being developed?
"programmers probably aren't up to the task of writing their own MVC framework"
I get the feeling that there are quite a few "programmers" who wouldn't know programming if it sat on their collective face and wriggled. Obviously, if you have a clear, well-defined, well-understood, and well-established requirement for which a solution already exists, you use that solution. That's where frameworks come in. Me, I'm using one right now (because it was in use when I arrived), but I have to keep reminding myself to stop mentally re-engineering the thing and just use it like I have no idea what's going on under the bonnet. (Oh, there are some egregious design flaws in this thing. Detailing them would identify it, so I won't.)
So I guess you can make a comparison between "Ruby on Rails" and "traditional PHP"; the latter asks more of you as a programmer.
Besides, it's not like you need to build an entire framework when you're writing an application. You write the application. If you already know how to write it then that's most of the work already done.
"One that's better than existing ones no less"?
That kind of depends on whether a given specific application needs an all-singing-all-dancing-one-size-fits-all (except when it doesn't have something you need) framework. ASP.NET, for example, strikes me as massive overkill for 99.5% of web sites and I'd only be inclined use it in a situation where everything else in the organisation in question is already done the Microsoft Way. (That's something else I've noticed: pick a framework and all development processes morph into practices geared towards the care and feeding of the framework and its way of doing things.)
Why no "one that's as fancy as necessary but no more"?
Still, all that will happen is that the frameworks will get more elaborate and complex and configurable and easy-to-stuff-up and so development kits will be written to make developing in <insert framework of your choice here> easier and simpler, and then those development kits will become more configurable and more programmable and spawn their own hooks and become frameworks and the whole process will begin again with yet another layer of abstraction designed to isolate the programmer from the computer.