On 12/25/05, Ron Stephens <[EMAIL PROTECTED]> wrote: > > I posted this on Python newsgroup just now, in response to Alex > Martelli: > > [EMAIL PROTECTED] > Dec 25, 7:53 pm show options > On December 15, Alex Martelli wrote: > > >Alternatively, counting Google hits: > >rails python django 112,000 > >rails python subway 81,600 > >rails python turbogears 32,000 > >This isn't exactly "buzz", of course, but it's SOME measure of "critical > >mass" -- and with django about equal to subway+turbogears, it does not > >appear to show any emerging dominance. A significant measure of "buzz" > >might be obtained by redoing the same search in, say, two weeks, and > >noticing the deltas... > >Alex > > Hmm, on December 25, I re-did the numbers using google: > rails python django 138,000 > rails python subway 66,000 > rails python turbogears 46,000 > > Now, I coudln't resist doing it this way too: > > python django 360,000 > python subway 690,000 > python turbogears 127,000 > > Unfortunately, no compelling trend emerges. This is the problem, I > think, no, trend, no clear winner (other than Rails;-)))
These numbers, in my opinion, are almost completely useless. I realized this soon after TurboGears was released. Before release, a Google search for TurboGears yielded ~60 results. Within a week of release, a search yielded more than 100,000 hits. I'm certain that one would be very hard pressed to truly find 100,000 pages referring to TurboGears a week after release. That's why I've been paying a lot more attention to what's visible in front of me: how many people are members of the google group, how active are they, how many people are contributing patches, how many people are looking at the site and the screencasts, how many downloads? And, probably most importantly, what are people doing with it? Any of these things taken by themselves are not very compelling as a statistic. Taken together, you can see that things are moving and moving fast with TurboGears. (That may be true of Django, as well, but the stuff I really know about is TurboGears.) Here's some of the qualitative stuff that I get out of reading the mailing list and talking with users directly: businesses are using TurboGears (for internal apps *and* for products), people are moving to TurboGears from Java and PHP, publishers are interested in publishing TurboGears-related material (even if O'Reilly isn't!). > Python web frameworks, for the love of God, UNITE!!!! "For God's sake, think of the children!" Luckily, I've already responded to this. Ruby on Rails (and Ruby by association) have *not* been growing because Python has too many frameworks. Rails was a distinctly better product with better marketing. http://www.blueskyonmars.com/2005/12/20/python-and-the-one-web-framework/ > This will work, I think, if and only if the "Consolidating" framework, > the one to be used to absorb the other(s) best aspects, makes immediate > > and up-front, highly visible concession(s) so as to clearly > communicate a win-win scenario. I disagree. It will work if and only if the best parts are chosen. Of course, "best" is subjective, but ultimately *someone* has to decide. If you try to take everything in or opt for a less ideal way of doing things as a "concession", the whole becomes weaker. That is a path to mediocrity or worse. > If this is to work, in my opinion, (and by "work" I mean be successful > enough to challenge Rails), then Cheetah must be enabled as an equal > templating language to Kid (at least). Kevin, you don't know me, but I > dare make this post for the good of Python. Kid may be technically > superior in every way to Cheetah (I don't know), but is the least > popular choice you made for TurboGears. Cheetah is a lot more popular. > You obviously love Kid; I suspect you think it is the best choice you > made in creating TurboGears. Again, I think "for the good of Python" is an invalid argument. "For the good of Python" is a web framework that provides a great user experience with a clear path to getting things done, instead of unnecessary choices at every turn. I also think that "Cheetah is a lot more popular" is not a very good argument. I could turn around and use the ridiculous sort of statement that they use on the news: "Kid's growth in popularity over the last three months has dwarfed that of Cheetah". With that kind of phrasing, it would sound like Cheetah is an also-ran, no? Back to Cheetah, though: as I've said earlier in the thread, I've used Cheetah quite a bit and it's a very good package. The place where "Cheetah is a lot more popular" *does* have important meaning is the use case of providing some Cheetah support to make it easier for people to migrate their apps. That was a use case I've been planning to support since before this discussion began (and it's also worth noting that there are people using Cheetah with TurboGears today). But, there is a big difference between making it easy for people to use Cheetah and making Cheetah a core part of TurboGears. I think David Stanek's suggestion of starting a KidVsCheetah page on the wiki is a good one. It will allow us to put together a solid picture of the differences between the two. > But if you give in on this, you will be amply rewarded, but on the > other hand, I do not believe a Kid-centric TurboGears will compete > effectively with Rails, for it will signal continuing division and in > Python land. "Continuing division in Python land" has little to do with competing with Rails. TurboGears with Kid will only have problems competing with Rails if it provides a lesser user experience. I think Kid provides a better user experience for HTML/XML. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
