Full-stack vs. glue vs. coupling
Yesterday I mentioned James Bennett’s discussion of the two camps of Python framework design. Ian Bicking has responded to James and seems to disagree.
Quoth Ian in his Full Stack vs. Glue post:
In a recent post on Framework design James Bennett describes as a fundamental dichotomy in framework design
“full-stack” vs. “glue”. In this case, Django (which James works on) as a full-stack framework, and TurboGears and Pylons as glue frameworks. This is not a good way to describe the differences.
He then discusses “awkward glue and easy glue”, the “intent” of the pieces, and “coupled” versus “decoupled” frameworks. Read the whole thing.
I have to admit that I tend to agree more with James on this one.
Sure you can get all nuanced and discuss the subtle differences in terms for each program design element… but when it comes down to it, the glue vs. full-stack gets the point across. For better or worse, some frameworks glue together existing parts (e.g. TurboGears and Pylons), and some write the whole thing from the ground up as a full-stack (e.g. Django).
There is nothing inherently wrong with either approach. And if you ask me, having two competing ideas is a Good Thing. I’d expect the invisible hand to deliver us even better frameworks in the future. So does the nomenclature really matter?
February 21st, 2007 at 4:42 pm
I’m actually not convinced Ian and I are all that far apart — a lot of the difference seems to be in the terminology and emphasis. I’m looking forward to watching the web frameworks panel at PyCon this weekend…
February 22nd, 2007 at 12:30 am
Hi James,
I agree that for the most part the two of you are getting at the same ideas. Personally, I like the glue vs. full-stack terminology better… but I can understand why those on the “glue” side might feel that it is a derogatory term.
In the end, I think it’s just terminology/nomenclature and probably not too important. But, regardless, I always enjoy reading thoughtful posts from both you and Ian on such subjects. :)