This (the state of python web frameworks) has been rolling around my head all week. I agree completely with what Derick has said.
I mainly lurk on tg, pylons, pyjamas and other python web framework lists. I originally chose pylons because of sqlalchemy and its ability to handle composite keys. We have had some success here promoting python (we mainly work with a big erp java oracle system) but the vendor has recently come out saying they are moving to groovy and zk. I'd much rather work with python but I see the python frameworks losing ground to java (with oracle being a wild card). With Google releasing gwt designer there appears to be less reason (unfortunately) to use python. The java to javascript toolchain appears strong, with other players (wavemaker, titanium) also in this space. Perhaps without corporate backing it is unrealistic to expect python to be able to compete. One exception to this is https://github.com/robertolupi/genropy, video http://blip.tv/file/3837476 but it still seems like early days there. Using dojo looks great, but not using sqlalchemy probably makes it a non-starter for us. Pyramid seems to have purposefully left the 'client/browser' area untouched, concentrating on the server but to me a framwork these days has to address the client/browser side of the equation as well. It is where the bar is being raised to with respect to web frameworks. RIA development, while being a twisted path, seems to be converging towards the benefits that the web has brought (ease of deployment) with the benefits of client/server (RAD). I'm curious to know what others think, if tg plans to address this piece in the pyramid puzzle. > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Derick Eisenhardt > Sent: Tuesday, November 09, 2010 12:59 PM > To: TurboGears > Subject: [TurboGears] Re: A modest proposal for the future of TurboGears > > From the discussion so far, I think we can take something Mark said in > the very first email and choose a direction right here. > > >The point I emphasized a bit was that Django is doing a great job of > >marketing, and the current situation is something like this: > >#1 Python web Framework > > ---> Django > >#2 Python web framework > > ---> TurboGears or Pylons or repoze.bfg or flask or... > > Whatever direction is chosen we want the end result to lead us in the > goal of redefining that logic as: > > Python web frameworks: > #1 Django (let's just be realistic here) > #2 Turbogears (full-featured web app development stack) > #3 Pyramid, web-core, etc... (build it yourself + disparate > components) > > Basically TG needs to move out of the pool of "other" and rise above > to the step new devs look at before they dig in to #3. > > Personally what I'd like to see is a solid, stable stack...with pretty > much every component most users will need 99% of the time built-in and > fully integrated. As while it's good to offer choice of various > components (hence why I chose TG over Django), TG2 has a few areas > that are not very pythonic...there needs to be one obvious, preferred > way, and if you want to venture into another direction, that's up to > you...but TG's documentation will primarily focus on the "correct" > way. > > One thing that has really bothered me ideologically in this area is > TG2's seeming lack of a preferred Javascript/Widget set (as opposed to > TG1's implied integration with MochiKit). Sure, there's Tosca, but > it's just so limited that it's really only good for simple web sites, > not true web apps, which as someone already said should be the real > focus of TG. I don't really care whether it's JQuery, Dojo, Pyjamas or > some other option...but this needs to be built in and standardized > upon. For the app I've been working on the past 2+ years I've had to > write everything myself to get Dojo and TG2 to work together, it could > really be much much more *automagical* in transferring data between > client and server and integrating with my templates. > > What you really need to be successful is a singular set of tools, with > just about everything you should need to write a web app built in, > fully documented as if TG were a single project like Django as far as > the user is concerned. Abstract out all your dependencies too, there's > no reason I should be importing things directly from SQLAlchemy or > Genshi, I should be importing things like tg.database and tg.template, > even if they're only wrappers so that if and when those things are > changed I don't have to go back and update my code to the new > dependency. That also applies to documentation, putting "see docs on > Dependency X's web site" doesn't cut it. If you want to be the full- > featured mega framework, then I should rarely have to leave the > turbogears.org domain. > > Whatever is decided, TG or whatever we call this in the future needs a > much more active community, with more developers, more users, and > probably some sort of corporate backing where at least a couple of our > core devs are getting paid full-time to work on TG if it's really > going to be sustainable and become the vibrant framework we all want > it to be. Personally I'm still leaning toward the 3 way merger of BFG/ > Pyrmaid, Pylons and TG, with the 2 package concept Mark mentioned > (minimal-core vs full-stack). > > -- > You received this message because you are subscribed to the Google Groups > "TurboGears" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/turbogears?hl=en. -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
