Sunday, 30 October 2005
Stumbled across this, from Ian Bicking;
My problem with a lot of MVC web frameworks is that they are really a way of codifying one developers internal thinking about a web application, and they don’t map well when they are used by another web developer; or they require both the code and the developers mind to be reshaped. This is fine, until another framework comes along that requires another shift in mindset and code. Or you have a problem (or just subproblem) that doesn’t fit into the model very well. Altogether, I am suspicious of frameworks; I think we need to work up from foundational abstractions, rather than jump to high-level abstractions like MVC.
I’ve been looking at a lot of these frameworks recently, and Ian’s thoughts ring true.
It’s not the first time I’ve had this feeling. My biggest problem with Lotus Notes was that it felt lie you had to buy into its view of the world — all or nothing. It’s their way or the highway; if you look at the world through Notes glasses, you’ll do fine, but as soon as you stray from the straight and narrow, forget it.
It’s a similar thing with these “frameworks.” Want to use another templating system? Forget it. Their data handling scheme not up to snuff? Tough. “Modular” and “small pieces, loosely joined” — some of the most fundamental lessons of the last ten or more years — fly over their heads.
So, what’s that about “foundational abstractions?” I think it’s staying close to the wire, close to the specs and close to the use cases. Don’t hide the technology that you’re using; respect it. The rest will flow from there. Otherwise, you’re just rebuilding Notes.