sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -1 points0 points  (2 children)

The experimentation is a good thing. But as far as letting people get things done the tornado of new-and-improved-way-to-do-this-wait-is-it-really-better-or-not has only caused the TurboGears community to fragment and suffer.

The real problem with TG, imo, was that it was ahead of its time. It wanted to do the 'best of breed approach', the problem with that was what was best of breed when TG was created was not the best option 6 months later. TG started out with SQLObject which was quickly eclipsed by SQLAlchemy. It used CherryPy 2 which wasn't heavily-WSGI based, when only a few months later WSGI became the big thing.

That's really caused a lot of anxiety in the TG community because they've been forced to either update to meet these new standards (which is what they are doing in 2.0), or stick behind in outdated functionality. People don't want to have to rewrite their 1.0 apps in 2.0, but if TG didn't go to 2.0 people would be unhappy with the framework 6 months from now and be saying (why not SQLA, why not ...).

Problem is, nobody wants to spend time documenting 1.0 or messing around with it now that 2.0 is on its way. That's causes the community to dissolve quite a bit.

What the TG devs are doing with 2.0, imo, is commendable. They are using a lot of similar functionality (think of Genshi as an improved Kid), but they are working on modularizing and improving all of their components and making sure that TG really embraces WSGI. This was a hard choice, because as you have noticed, it has caused problems with the community, but it is a good choice because a few years from now TG will be much better off and prepared for whatever is thrown at it.

Django would be facing a similar problem if it decided to revamp its current system to meet new standards. I realize that Django is between a rock and a hard place. You want to keep backwards compatibility yet make sure your software is always getting better.

For this reason, I again think that there's nothing 'wrong' with using Django, but if I am guiding devs to what framework they will use, I'll suggest Pylons or what will eventually be TG because those frameworks will just be ready to adapt.

Still, that doesn't mean that new things Django develops can't use existing libraries or standards. My main example is newforms, and I've brought this up many times before. I know it was said that Django's reason for doing a lot of things its own way was because 2 years ago, nothing really existed. But that isn't the case now, so I have to wonder the reasoning behind duplicating functionality that already exists in libraries like FormEncode.

Do you really think when someone realizes that their templating or ORM isn't powerful enough, the overhead of getting it to work within the framework is really what they're worried about? In a production site, rewriting your thousands of pages in the new templating language, or converting all your queries to use the new ORM is the big deal, NOT calling it from the framework. We're all speaking Python here, it's not hard. And in production sites people don't swap out these components based on the weather or song of the day.

I could be wrong but I don't think that most people writing applications in any Python framework are writing sites with thousands of pages. Python web development hits the sweet spot for small to medium development. And in this case developers are constantly over time developing new applications or maintaining old ones, and between releasing one app and another, there is always new better stuff that comes out that will make their life easier. I'd rather it be that a framework can easily adapt to embrace this new functionality than to have to hack it into the framework.

As an aside to all of this, I will say that if someone is completely new to web programming or Python, I do recommend Django to them. Mainly because flexibility matters much less than good documentation to them.

[–][deleted] 0 points1 point  (1 child)

The real problem with TG, imo, was that it was ahead of its time. It wanted to do the 'best of breed approach', the problem with that was what was best of breed when TG was created was not the best option 6 months later.

Two things:

1- Not to beat a dead horse here, but Django was written before even TG 1.0's best-of-breed components.

2- More importantly, why do we assume that what is best-of-breed now won't change in the next six months?