mnot’s blog

Design depends largely on constraints.” — Charles Eames

Sunday, 30 October 2005

Frameworks

Filed under: Web

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.

Foundational Abstractions

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.


4 Comments

Ryan Tomayko said:

Here’s a good definition of “Foundational Abstraction”, IMO:

“Why Frameworks Suck” http://an9.org/devdev/why_frameworks_suck?sxip-homesite=&checked=1

Gregorio’s term, “Friction”, makes a lot of sense here as well:

http://bitworking.org/news/Frameworks_and_Friction

Sunday, October 30 2005 at 11:30 AM

Mark Baker said:

I don’t disagree guys, but note that sometimes, “foundational abstractions” are frameworks. For example, server side connectors like HTTP & the Servlet framework.

I also don’t think there’s a hard line between frameworks and libraries as most non-trivial libraries will have some framework-like (inversion-of-control) structure. For example, most GUI or network libraries (i.e. supporting async uses) will have some kind of callback mechanism which is, by definition, a framework. It’s just a general one.

Most of the pushback against frameworks I’ve seen fall into one of two camps. Either the framework isn’t general enough, or it does things using the framework that would best be handled as a library.

Monday, October 31 2005 at 7:33 AM

Ian Bicking said:

Incidentally, when I was thinking about this, I was thinking that CGI makes a nice abstraction on top of HTTP – enough to be useful, but still looks very like HTTP – and WSGI is a nice abstraction of CGI. They add convenience, but without introducing many new ideas.

A contrasting way of handling things is object publishing – often with a CGIish entry point, but quickly leaving that behind and using new concepts for the internal processing. Some people think this is a better foundation, Zope being a good example… but it doesn’t look anything like HTTP. So I’d say I agree… “close to the wire” in some respects, or just generally that the abstractions retain the basic shape of the things they are abstracting, hiding just what they can completely and successfully hide, and no more (i.e., if a concept is going to be leaky, just leave it out).

Monday, October 31 2005 at 9:25 AM

Terris Linenbach said:

Mark,

People like you, Ian, and myself are soon to be dinosaurs, never to walk on the face of this earth again.

Frameworks exist for one reason: for enterprises to build software on the cheap. For CEOs and COOs, it’s about the business, not about creativity. Especially when the dev team is in India. And once the Indians become comfortable, dev will move to China, and after that, the dev team will consist of a single automated “programmer” named HAL.

Hate to be the bearer of inescable bad news.

Terris

Tuesday, November 15 2005 at 6:51 AM

Creative Commons