One OpenSpace topic convened at CodeMash was “Python Web Frameworks”. TurboGears seemed to be the most-represented citizen of the Python web world, but some asserted that they use Django. I had skipped Brian Goetz‘s “Java Performance Myths” talk in favor of this, even though I am sure that would have given me more ammo to smack down the crusty turds in the Java world who are always denigrating the work of others for its lack of their arcane incantations that are allegedly “critical to performance”. I have to say I was pretty dismayed after attending the OpenSpace, but maybe that’s not a loss after all. Perhaps my Python web enthusiasm was due to be curbed. Also, maybe I shouldn’t let those crusty Java turds get to me so much, even if I do feel they are a key agent in keeping the Java community from being more inviting.
Coming away from the discussion, my impression is that the Python web framework community is perfectly content with the dilution of effort and momentum that is caused by the proliferation of web frameworks. We talked about the number of projects out there, laughed a little, and then folks seemed to be ready to move on. One participant fortunately asked the question “How are TurboGears and Django different, because they look the same to me?” That’s a paraphrase, but the gist of his whole question was, as the two leading Python frameworks, how are these two serving different needs, and if they’re not, why are there two? What followed was some dialog that choice was good, the usual stuff you’ll hear in Open Source discussions about duplication and fragmentation of effort.
I followed up on his question commenting that the degree of fragmentation has seriously hurt the credibility and perceived viability of Python web frameworks in larger shops that are entertaining dynamic web frameworks as possible alternatives to doing everything in Java or .Net. I added that the proliferation of choices in Python has really only served to dilute the attention and effort for those that are emerging as the leading ones. I also shared that those outside the Python community are perceiving its web offerings as momentary fascinations of the brilliant, yet quirky enthusiasts upon which nothing long-term should be based. This didn’t seem to be well-received by the group, but I may be wrong. I think most folks present may have been up for a Python love feast instead of some serious introspection on where we are and how we got here.
Another thing we had was Python fans without significant Java experience continually emitting FUD about the JVM, which blows my mind. I have been following Python pretty closely for over a year now, and the amount of ignorance about Java in the Python community still surprises me. The lack of hands-on experience with Java does not seem to deter the constant, half-formulated criticisms of it. Some even seemed to be implying that Python’s threading situation was better off than Java. The platform of Java quite frankly kicks the hell out of most all others in that arena; this is widely-known.
There is an unsettling meme that seems to be running through the Python web framework community of “doing what’s cool”, which is unsettling. Cool and pragmatic seldom keep close company. One of the most heartening things about Rails 2.0 has been the steps taken to pay down technical debt and bolster the soundness of the framework. Hearing that TurboGears is pursuing X because Django has it and that’s cool disturbs me. “Cooler than Y” doesn’t get me a framework I am comfortable building upon; robust and reasonably-documented does.
I viewed the merged effort with the Pylons project very positively when I learned of it. Collaboration and true sharing are all-too-absent in F/OSS these days. However, the more I learn about the culture and mantra of Pylons, the more I am inclined to think it may have been an ungainly partnership. I am wondering if TurboGears’ original “compose a mega-framework of best-of-breed” may have subtly morphed its perception of best-of-breed to be “coolest”. And cool, like beauty, is in the eye of the beholder.
The need for a degree of stability in a web framework is not unlike the dilemma faced by technical authors and producers. Something I have heard from multiple technical writers is that one must resist the temptation to be forever revising the work in hopes of keeping pace with the changes occurring in the technology being covered. In software that rate of evolution is such that it is a Sisyphean undertaking. One must pick a point of time and stick to it. The hope is that said point is an acceptable level of stability so that the book is not useless weeks after it hits the shelves. (This begs the question of whether or not many technical books in print today should not have been published, but that’s a separate topic.)
My chief concern for TurboGears is that the apparent direction toward “cool” is in direct conflict with the need for stability and documentation. The quality of Open Source projects these days is such that few will tolerate a poorly-documented project that poses an unnecessary learning curve primarily brought on by the need to figure things out for yourself. Unless the documentation is shored up and the rate of significant component change slows, I think TurboGears will be challenged to gain more traction in the wider web framework world.
The reason I am even bothering to write about this is that I care about the TurboGears project. I chose it for my framework to explore at Bruce‘s Dynamic Web Frameworks Jam, and was blown away by how much had been accomplished in so little time with the project. It had things I have been wanting for years in Java web development, and the learning curve was so low that I found myself running ahead of my own understanding of Python at times. The DRY-ness of TurboGears is another strong draw for me. Implementing your own components when superior, highly-tested ones exist is just silly these days, unless considerable mitigating factors are present. While I think it holds lots of promise, I can’t say that I am comfortable basing any significant projects on TurboGears right now.
I love it! “Cool and pragmatic seldom keep close company.” Thanks for your honest and thoughtful assessment, and I hope the Python fanboys in the room with you were not representative of the Python community at large. Otherwise, you’re right, it’s in trouble.
Pingback: Words of Wisdom From The Elder
Pingback: Sp3w
Well
I think there’s a lot to be learned from looking at the “cool” stuff. Things are popular for a reason, and one of the things you have to do when working on a project that solves problems for users is to look at the why some people think other solutions to that same problem are “cooler.” And that’s what I’ve been trying to do with TurboGears. Beyond that, the main objective of the last year is to work with Pylons, Repoze/Zope, and whoever else in the python web framework world is interested in working together.
I think the “fragmentation” argument is actually overbolown, there’s a lot of cooperation, code-sharing, and idea-proliferation going on behind the scenes. For example one of the things that was mentioned in the conversation was the Django-Admin interface. This is cool because it allows you to edit your data quickly and easily, and it provides a very quick way to get a working user interface. Django is popular because this feature is really attractive, and their user community is growing partly because of it. Unfortunately the implementation is very Django specific. But, lots of the ideas are very viable outside of django. So, rather than take this project on as a TurboGears feature, we’ve been supporting a project called DBSprockets, which will bring many of those same features to TurboGears, and pylons. But it’s designed in such a way that it’s actually useful to a wider set of python web developers than just the members of our little community.
The idea came from django, and has been reimplemented in a more flexible way on top of SQLAlchemy and ToscaWidgets. This is actually a benefit of multiple competeing projects, we can learn from one another and new ideas seem to come at a faster rate when there are lots of people experimenting in different ways.
We certainly aren’t changing core components because of a “coolness factor” calculation. We moved from SQLObject to SQLAlchemy because SQLAlchemy provides a complete and compelling database access layer, built on an SQL independence layer, and an Data Mapper based ORM. Sure, some of the things SQLAlchemy can do are pretty cool, but the fact of the matter is that it provides a much better scalability and legacy database integration story than SQLObject. There’s a lot of pragmatic decision-making behind these choices. But, SQLAlchemy isn’t always enough to get us in the door, because the coolness of the Django Admin interface is a lot more visable to new users, than the scalability features of SQLAlchemy. The Genshi switch was based entirely on similar pragmatic reasons (performance, developer base, flexibility, etc).
But building a side project which allows us to get in the door to tell our story about building frameworks around components with well defined interfaces, and with direct support for many important “enterprise architecture” patterns isn’t raw persuit of coolness, it’s a pragmatic decision about how to position ourselves and our philosophy in the larger market.
As for the anti-JVM fud, I must have been focused on something else. And I sure hope I wasn’t an accidental participant in it.
I happen to know that the threading story on the JVM is far better than in python. And both Jython and Jruby have better threading support than their respective C implementations for various reasons related to object reference counting and garbage collection. But I think there are lots of advantages to multi-process concurrency solutions, and I’m not at all convinced that the JVM has a better story there than c-python, and that was a point I tried to make at the meeting. But perhaps I wasn’t clear or wasn’t thinking properly. If so, I’m sorry to have contributed to spreading any anti-java FUD.
One other thing.
I think the coolest features and best selling points of Django is their docs. So, from my perspective that’s one of the “cool” things we need to emulate.
Hey Mark! Hope you get a chance to recover from your conference/sprint marathon.
Yeah, you were not among those who were saying the stuff about the JVM which gave me pause. Additionally, some of the stuff I heard were things I heard at Pycon last year and even at PyAtl meetings. One of the best Java assertions I once heard from a Python person was “Are people even doing that much work in Java anymore?” 🙂
As almost anyone who knows me can tell you, I am no particular fan of the Java language. I don’t think the Java platform is bad, though. But, even if I did, I don’t see much use in sharing it while trying to have a meaningful discussion about a different language. The more open and collaborative feel of the dynamic language communities were a big part of the draw for me as I started looking at Ruby and Python.
For the record, I still think TurboGears has the best long-term vision among the Python choices. Furthermore, I think that only it and Django merit serious consideration. I didn’t spell it out fully in the original post, but hearing about things like web2py (formerly Gluon) were what made me think about fragmentation. Two leading Python frameworks does not fragmentation make. 😉
I don’t think anyone could question the soundness of switching to SQLAlchemy; that is the neatest ORM I have seen in any language. I was really excited when I learned about that.
The “cool” topics about TurboGears that concerned me were the discussions about even more changes to controller and view components. As you have pointed out, there have been some initial changes with well-documented reasoning. However, as I heard about the proposed new changes to controller mappings (I can’t remember exactly, something about going one way because of Pylons, but then WSGI was a different way, and Django had this other way that was cool…I kind of glazed over at that point) and moving from Genshi to Mako for view stuff, I began to be concerned. No doubt there are great technical reasonings behind these as well, but I wonder if they are critical enough to need to change already.
What I’d certainly like to make clear is that this post in no way is meant as a condemnation of the TurboGears project, and I think you’ve done a great job trying to steer the thing. Thanks for all the tireless (and unpaid) work you’ve put into it.
Thanks Barry!
TG2 will have the same object dispatch based controller mapping, with the possible additon of a way to manually override that mechanism when you want/need something different. But object dispatch will still be the default, and it will always just work. But, because Routes and django’s regex matching, do allow you to do somethings easily that are hard with object dispatch, I think it’s likely worth supporting some kind of built-in overide mechanism for special cases. And the most likely candidate would be Routes (from Pylons, which is based roughly on Rails-ActionPack routes implementation). But this will only happen if users who don’t need it never have to worry about it.
As for Genshi, that’s another pragmatic decision. Genshi has almost exactly the same syntax as Kid (it was designed from the beginning to be a reimplementation of Kid) with a few new features, such as includes, the ability to use xpath expressions in match templates, and a couple of useful tags. But the main reasons we are switching to Genshi are:
1) community support — Lots of devs on genshi, lots of users, so it will be around for the long hall — vs. Kid has had trouble maintaining a viable community
2) basic performance — Genshi is quite a bit faster than Kid
That coupled with the very similar API’s made it worth switching to Genshi.
Mako is another story. To be clear, there was some open discussion of switching to mako, but we will be sticking to Genshi. It often has 10x perfomance gains over Gehshi, and for sites which render millions of hits per day (or which just render very, very large pages) that can make a huge difference. Because the performance differece can be huge in some cases, TG2 will have to support Mako and even try to document it’s use, but it will not be the default.
Hopefully that clarifies some things, and makes it clear that we aren’t playing ring-around-the-component. 🙂
Hopefully that clears up some things about TG2’s development path.
Pingback: yep, that’s me - barry at alltc.com » Mark Ramm, friend and exemplar
I committed to django based on their endorsement from the People’s Front of Judea. 🙂
I agree that there too many Python frameworks and fragmentation is a problem but there is a biger problem. Most existing frameworks have a bottom-up design instead of a top-down one. Developers keep adding layers that break backward compatibility instead of starting from a user-centric API design. web2py (http://www.web2py.com) was originally designed to address this issue and show how a web framework should be user centric and not developer centric. The web2py API have never broken backward compatibility.
Pingback: -= Linkage 2007.01.14 =-
Comments are closed.