Related
I want to create a website and I am confused which web framework to use. Please recommend me which framework is better: Django or Zope. I am using Python.
If you mean plain Zope2 by zope then I'd go for Django. Most interesting stuff in the Zope world takes place with either Plone or Grok (which is Zope3, which is actually quite different from Zope2).
Grok works nice with relational databases, Plone doesn't really, so if you depend on an RDBMS, either go with Grok or Django.
Zope and Plone have a rather steep learning curve so you'll get started more quickly with Django.
The largest downside about Django is, in my opinion, that it tries do do everything by itself (templating, object publishing, ORM, and so on) while there are many excellent existing components out there. If you want to be able to use your code / knowledge outside of the web framework you're using, consider Pylons or BFG
Many options, no clear answer, sorry :)
I have no idea what sort of website you're trying to create, so it's hard to recommend a specific framework.
I'd recommend getting through some tutorials to see which one you like best (There's also pylons and TurboGears to pick from).
Django seems to be the most popular starting kit these days though.
If your website is very hierarchical and needs fine grained permissions, I'd use Zope. (Don't use Zope if you intend to store your data almost exclusively in an SQL database.)
If you have large datasets that can be put into (sql)tables and need many forms, I'd use Django. (Don't use Django if you need very fine grained access control, and hierarchical data)
You see: both have their weaknesses and strengths (although I am only developing in Django these days. The Zope community seems to be a bit in dispute these days about the way it should develop)
Zope is dead. As is TurboGears, Pylons, BFG, Repoze, CherryPy etc.
Active and popular Python web frameworks include:
* django
* flask
* bottle
Big, medium and small. Take your pick.
Here is a good comparison of Django and Zope (and Rails)
http://cd-docdb.fnal.gov/cgi-bin/RetrieveFile?docid=2715;filename=Comparison.html;version=3
They preferred Django. I, personally, use Django too, so I don't know much about Zope.
Another good thing about Django is that they have very good documentation (though I don't know that of Zope). Many people praise that very much.
Also I found Django quite easy to use, and also they have a ready 'administrator panel', which allows quick web-oriented site management from the first steps. More important for me, however, is its fine integration with python and the simple organisation (in the link above they complained that Zope uses very much of its own features, while Django is closer to pure Python).
If you are starting from scratch I will suggest you should go for Django. You will get lots of features and suppost from django. Easy to debug and best suited for rapid developement. In the other hand, You should only choose Zope, if you have experienced developers familiar with Zope or have existing projects based on Zope and the cost of switching is too high for the potential value gain.
In zope's website it self it is written, It is no longer recommended to start new projects based on it, unless you are intimately familiar with the technology stack.
Background:
I have a new site in the design phase and am considering using ColdFusion. The Server is currently set-up with ColdFusion and Python (done for me).
It is my choice on what to use and ColdFusion seems intriguing with the tag concept. Having developed sites in PHP and Python the idea of using a new tool seems fun but I want to make sure it is as easy to use as my other two choices with things like URL beautification and scalability.
Are there any common problems with using ColdFusion in regards to scalability and speed of development?
My other choice is to use Python with WebPy or Django.
ColdFusion 9 with a good framework like Sean Cornfeld's FW/1 has plenty of performance and all the functionality of any modern web server development language. It has some great integration features like exchange server support and excel / pdf support out of the box.
Like all tools it may or may not be the right one for you but the gotchas in terms of scalability will usually be with your code, rarely the platform.
Liberally use memcached or the built in ehache in CF9, be smart about your data access strategy, intelligently chunk returned data and you will be fine performance wise.
My approach with CF lately involves using jQuery extensively for client side logic and using CF for the initial page setup and ajax calls to fill tables. That dramatically cuts down on CF specific code and forces nice logic separation. Plus it cuts the dependency on any one platform (aside from the excellent jQuery library).
To specifically answer your question, if you read the [coldfusion] tags here you will see questions are rarely on speed or scalability, it scales fine. A lot of the questions seem to be on places where CF is a fairly thin layer on another tool like Apache Axis (web services) and ExtJs (cfajax) - neither of which you need to use. You will probably need mod-rewrite or IIS rewrite to hide .cfm
Since you have both ColdFusion and Python available to you already, I would carefully consider exactly what it is you're trying to accomplish.
Do you need a gradual learning curve, newbie-friendly language (easy for someone who knows HTML to learn), great documentation, and lots of features that make normally difficult tasks easy? That sounds like a job for ColdFusion.
That said, once you get the basics of ColdFusion down, it's easy to transition into an Object Oriented approach (as others have noted, there are a plethora of MVC frameworks available: FW/1, ColdBox, Fusebox, Model-Glue, Mach-ii, Lightfront, and the list goes on...), and there are also dependency management (DI/IoC) frameworks (my favorite of which is ColdSpring, modeled after Java's Spring framework), and the ability to do Aspect-Oriented Programming, as well. Lastly, there are also several ORM frameworks (Transfer, Reactor, and DataFaucet, if you're using CF8 or earlier, or add Hibernate to the list in CF9+).
ColdFusion also plays nicely with just about everything else out there. It can load and use .Net assemblies, provides native access to Java classes, and makes creating and/or consuming web services (particularly SOAP, but REST is possible) a piece of cake. (I think it even does com/corba, if you feel like using tech from 1991...)
Unfortunately, I've got no experience with Python, so I can't speak to its strengths. Perhaps a Python developer can shed some light there.
As for url rewrting, (again, as others have noted) that's not really done in the language (though you can fudge it); to get a really nice looking URL you really need either mod_rewrite (which can be done without .htaccess, instead the rules would go into your Apache VHosts config file), or with one of the IIS URL Rewriting products.
The "fudging" I alluded to would be a url like: http://example.com/index.cfm/section/action/?search=foo -- the ".cfm" is in the URL so that the request gets handed from the web server (Apache/IIS) to the Application Server (ColdFusion). To get rid of the ".cfm" in the URL, you really do have to use a URL rewriting tool; there's no way around it.
From two years working with CF, for me the biggest gotchas are:
If you're mainly coding using tags (rather than CFScript) and formatting for readability, be prepared for your output to be filled with whitespace. Unlike other scripting languages, the whitespace between statements are actually sent to the client - so if you're looping over something 100 times and outputting the result, all the linebreaks and tabs in the loop source code will appear 100 times. There are ways around this but it's been a while - I'm sure someone on SO has asked the question before, so a quick search will give you your solution.
Related to the whitespace problem, if you're writing a script to be used with AJAX or Flash and you're trying to send xml; even a single space before the DTD can break some of the more fussy parsing engines (jQuery used to fall over like this - I don't know if it still does and flash was a nightmare). When I first did this I spent hours trying to figure out why what looked like well formed XML was causing my script to die.
The later versions aren't so bad, but I was also working on legacy systems where even quite basic functionality was lacking. Quite often you'll find you need to go hunting for a COM or Java library to do the job for you. Again, though, this is in the earlier versions.
CFAJAX was a heavy, cumbersome beast last time I checked - so don't bother, roll your own.
Other than that, I found CF to be a fun language to work with - it has its idiosyncracies like everything else, but by and large it was mostly headache free and fast to work with.
Hope this helps :)
Cheers
Iain
EDIT: Oh, and for reasons best known to Adobe, if you're running the trial version you'll get a lovely fat HTML comment before all of your output - regardless of whether or not you're actually outputting HTML. And yes, because the comment appears before your DTD, be prepared for some browsers (not looking at any one in particular!) to render it like crap. Again - perhaps they've rethought this in the new version...
EDIT#2: You also mentioned URL Rewriting - where I used to work we did this all the time - no problems. If you're running on Apache, use mod_rewrite, if you're running on IIS buy ISAPI Rewrite 3.
do yourself the favor and check out the CFWheels project. it has the url rewriting support and routes that you're looking for. also as a full stack mvc framework, it comes with it's own orm.
It's been a few years, so my information may be a little out of date, but in my experience:
Pros:
Coldfusion is easy to learn, and quick to get something up and running end-to-end.
Cons:
As with many server-side scripting languages, there is no real separation between persistence logic, business logic, and presentation. All of these are typically interwoven throughout a typical Coldfusion source file. This can mean a lot more work if you want to make changes to the database schema of a mature application, for example.
There are some disciplines that can be followed to make things a little more maintainable; "Fusebox" was one. There may be others.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What sequence of events made Django the most popular Python web framework .. and still so? Even though several other frameworks exist.
Note: This question is neither argumentative nor confrontational. I merely asked for (objective) "the sequence of events" that lead to its actual popularity. Being aware of the dynamics of software acceptance, I am not intending anyone to get into arguments over technical superiority.
Many Python web frameworks already existed when Django appeared in 2005 -- indeed, the joke was already going around, by then, that Python is "the language with more web frameworks than keywords" (and Guido rejected my proposal to fix that in Py3k by adding many, many more keywords). Now "django" per se is a bit ambiguous as a search term (it's also the name of a popular guitar player whose life inspired a Woody Allen movie, etc, etc), nevertheless adding "python" to the search to remove those other meanings you can see e.g. in this graph how its relative popularity changed in comparison to another classic Python web framework, Zope. Mostly steady growth quarter over quarter, with a huge surprising jump up at the start of Q2 2008... which just happens to coincide with the date in which Google announced App Engine (it's impossible to prove causation in such case, but the coincidence is at least interesting;-).
App Engine essentially rules out any Python web framework that deeply depends on custom C-coded components, or intrinsically require "heavily relational" functionality; out of those that run well with just pure Python code, Django is probably the one that App Engine most directly and visibly supports. However, this was just a boost, adding to Django's underlying healthy growth trend. The explanation for that trend (and indeed for App Engine team and users' decision to support Django so well) must lie in characteristics that are intrinsic to Django itself.
Django is sometimes criticized (including by... yours truly;-) for being "too magical" or "too monolithic", compared to alternatives such as Pylons, TurboGears, Werkzeug, &c, which are lighter-weight (esp. the latter, my favorite;-), more transparent, and allow easier swapping in and out of specific components (ORM, templating, &c). However, Django's popularity tells us that, for most people interested in developing server-side web sites and apps, these Django design choices are perceived positively: Django's seen as a very rich and well integrated framework (and it does have a lot of add-ons and contributed "plugins", but those are more a consequence than a cause of its ascendancy).
Ease of getting started, automagical "admin pages", and the like -- as well as the fact that Django can be bent to make really rich and complex sites/apps and accommodate peculiar or unique requirements, with much skill and some work -- are probably the "killer features". To use Werkzeug at its best, you need to understand HTTP, and WSGI, and pick and integrate your favorite storage and templating -- developers of Python-based web sites and apps (like, in a sense, users of Rails, or users of even-more-popular PHP!-) are "voting with their mindshare" for an environment in which they need not necessarily do any of that, but can mostly focus on their application domain. I will have to admit that they probably do have a point;-).
I think there were a few factors, the combination of which was greater than the sum of their individual weights.
One is simply timing: Django appeared right as the first big wave of Rails hype was ramping up, and so it was immediately portrayed as being sort of "Python's answer to Rails". That resulted in a not-insignificant number of eyeballs on the project almost from the start. The fact that Adrian was at the "Snakes and Rubies" meetup in Chicago and got to take part in side-by-side talks about Rails and Django did a lot for that.
Another factor is that Django is and always has been a single-package install (well, not quite: you still need a database adapter, unless you're on Python 2.5+ and using SQLite, but close enough). The non-Zope alternatives, which all focused on leaving component choices in the developer's hands, required quite a bit more work just to get to the point where you could do a basic tutorial: you'd need to go hunting down an ORM, a template language, etc., etc. and get them all installed and configured. Though that's gotten much better over the years, I think the lingering memory of that still has an effect.
And Django came out of the gate with documentation that (if I may say so myself) was far above the usual standard for open-source projects, and has only gotten better over time. The tutorial, for all its many faults, hits on a number of the high points that make Django useful, and the remainder of the documentation has always been of good quality, mixing both API reference and important "how to" bits as needed. This produces a good out-of-the-box experience and helps with the post-tutorial learning curve (something which has always plagued Zope).
I also think there's a perception -- rightly or wrongly -- that, say, Pylons or Werkzeug really are better for experienced developers who already know their way around WSGI and the Python web ecosystem; the fact that they tend to be strong choices for taking your existing favorite libraries and plugging them together is the source of this, I think, and perhaps nudges some newer folks over toward Django's integrated approach. The flip side, of course, is that a lot of people who'd be better off learning more up-front before trying Django don't do that ;)
Finally, I think there's something to be said for the way Django's been marketed, which is to say that it really wasn't marketed for a long time, or at least not in the sense that, say, Rails was marketed. Until Django 1.0 landed, the "marketing" effort mostly consisted of people blogging (and there were some notable incidents where people were asked to tone it down a bit), talks at PyCon and then mostly just improving the framework, building cool things with it and letting the results speak for themselves. Now, of course, in the post-1.0 world we have the DSF and DjangoCon and business-oriented consultants doing training sessions and lots of books and all the rest, but that's all still quite new.
I expect that there will be a backlash, just as there's been with Rails, and in fact I think it's been brewing for a while and has already started. But up until now I think the factors I've listed here are at least the major ones behind the consistent, steady growth in popularity Django has seen since its initial release.
I can think of three reasons for Django's popularity, only one of which has been addressed in other answers as far as I see:
Documentation. It's well structured, comprehensive, and approachable from a number of skill levels.
Design. The visual design of the admin, error pages and the project site are far above the level of design seen with most open source projects.
Community support. Starting with the team at World Online, Django picked up some influencial evangelists early on. I'm not sure you can over state the importance of blog posts like Jeff Croft's Django for Non-Developers (I think that was the title).
"My personal favorite, and I expect that that will remain a personal favorite for a long time, is something named Django" - Guido Van Rossum on FLOSS weekly episode 11, aired aug 4th 2006
[Click Here] (listen to last third of the interview)
Think this might have helped? or at least the reason why Google chose it for AppEngine?
of course, the django community (including devs) are doing alot of things right. For example (Some analysis in the links):
Improving modularity:
[Click Here]
kick ass documentation
Click Here
There is also something about the community that gets people to want to contribute which I've yet to put my finger on:
Click Here
Of course, all that lead to Django being an outlier:
Click Here
There is no question about Django's popularity.
In my case, I'd bought the TurboGears book, and struggled through its inconsistencies and haphazard route to explaining things.
Then I got the Django book, and voila! My first for-pay project was created while working my way through the sample project in the book. That plus the online documentation sealed the deal.
For me, it was simple: Documentation, documentation, documentation.
I noticed that it often got promoted as being the Ruby on Rails equivalent in Python. It's also has a connection to Google (Google hosts Django events, and supports it in their App Engine). A web framework being endorsed by Google has to amount for something. :)
At least for me, an important factor was that Simon Willison and Adrian Holovaty were already well known players in the "Web Standards" scene, as well as Jeff Croft later.
That wasn't only a quality seal, but also made Django very web-friendly, with its respect for HTTP, markup, and even the quick and dirty, "print debugging" way of working that people coming from PHP were used to.
I might be heavily wrong here, no data to back this up, but I feel that Django gained a lot more traction from people coming from PHP, as opposed to Rails which got a lot of conversions from Java/.NET.
As others already noted, the documentation is way above average. The best I've seen, as far as I recall.
The fact that there were several high volume sites already using Django (i.e. lawrence.com etc...) - even by the 0.96 days - helped me convince management it was safe to use. Things like Pylons and Turbogears really did not have that.
As for Django's popularity over time (the literal meaning of your question title, if not quite your actual question), have a look at the google trend.
Do you use a wiki in your company? Who uses it and what for. Do you share information between projects / teams / departments or not?
We use ours to store
Coding Style docs
Setup and Deployment procedures for web servers and sites
Network diagrams (what are all the servers in Dev, Staging, QA and Production called etc.)
Project docs (pdfs, visios, excel, docs, etc.) are stored in SVN. For the non-techies we have links to those docs in the wiki that point to an up-to-date share on my box. (tip: some wikis provide source control integration but ours doesn't)
Installation and Setup procedures for development tools
Howto's on things like using our bug tracking system, our unit testing philosophy
When doing research on a topic I often capture the important information in a wiki page for others to learn from
I've seen them used to keep seating charts in medium to large size organizations for the new people
At my previous company all of the emergency contacts and procedures for handling a critical outage where available on the front page of the wiki
The best part about a wiki is that it's searchable. Some wiki's support searching inside uploaded or linked docs as well.
If you setup a wiki and encourage or even require people to use it the amount of information that will accumulate can be amazing. It's definately worth the effort especially if you have someone in IT with some spare time on their hands to set it up.
Do you use a wiki in your company?
= We use it for the purpose of a Knowlede Based. Basically it is a wiki but many more functionalities intagrated.
Who uses it and what for
= Employees. Knowledge Sharing, Preparation of collaborative-documents, etc.
Do you share information between projects / teams / departments or not?
= Depends on the requirements. It is possible to set permissions between users.
We use a wiki, for documenting our systems. It's updated gradually as things update and evolve. It should go without saying that there's benefit in that, however whether you use a wiki or other methods is worth thinking about.
A wiki is great for collarborative editing. The information shouldn't go stale in theory, because as people use the systems they have the opportunity to keep it up to date.
However we have found in our organisation that people struggle a little with wiki markup. Especially tables. I think a solution that has wysiwyg editing would be better if you have non-highly-technical people editing it. Sharepoint springs to mind, but it's expensive.
I use a wiki as my virtual "story wall" for agile development. All of my stories are written and organized in the wiki. While my customers are reasonably local (we can have face-to-face meetings), they aren't co-located. To enable better customer interaction I've resorted to a wiki instead of a wall-based story tracking mechanism. It also works a little better for me due to the fact that I often have multiple, concurrent projects and limited wall space in my cube. In a larger team with more focused projects and more wall area, I'm not sure I'd make the same choice.
My company uses a wiki for project-planing but also for storing documentation and ideas.
I have found that a wiki is a great way to link the programmers in the company with the business-people.
When someone who are not on the programming-team comes up with an idea or finds a bug, it's a loot simpler to let that person document it in the wiki.
I think it's an important aspect for a small company like mine to easily synchronize the business-team with the development-team. A wiki helps with that, since it gives the feeling of being a part of the development process, instead of having to ask the programmer directly about every little detail.
we have MediaWiki to store technical information that is not ready to be published in other formats - specification drafts, diagrams (via GraphViz extension), results of short investigations, etc.
I also think this question is a wiki too :)
I'm playing around with Django on my website hosting service.
I found out that a simple Django page, which has only some static text, and is rendered from a very simple template I created takes a significant time to render. When compared to a static HTML page, I am getting ~2 seconds difference in the load times. Keep in mind this is a simple test of mine with nothing complicated. Also note that my web hosting is on a shared server (not dedicated), so I might be hitting some CPU limitations.
Seems to me that either:
I have some basic CGI/Apache/Django configuration wrong
Django takes significant overhead, at least in this specific scenario.
I find #1 not probable since I followed my web hosting service wiki on how to set up Django. So we are left with the overhead problem.
My question is which web framework do you find the best to use in scenarios where the website is hosted on a shared server, and CPU/memory overhead must be kept to minimum?
Edit: seems that my configuration is something I might want to look at, and perhaps later on I'll be opening a question on how to best configure Django.
For now, I would appreciate answers focusing on your experience, in general, with web frameworks, and which of those you found to be the best in terms of performance in the aforementioned scenario.
"I have some basic CGI/Apache/Django configuration wrong"
Correct.
First. The very first time Django returns a page, it takes forever. A lot of initialization happens for the first request.
Second. What specific configuration are you using. We just switched from mod_python to mod_wsgi in daemon mode and are very happy with the performance changes.
Third. What database are you using?
Fourth. What test configuration are you using?
Fifth. What caching parameters and reverse proxy are you using?
Odds are good that you have a lot of degrees of freedom in your configuration.
Edit
The question "which of those you found to be the best in terms of performance" is largely impossible to answer.
See http://wiki.python.org/moin/WebFrameworks
There are dozens of frameworks. Few people can examine more than a few to do head-to-head comparison.
The best possible performance is achieved through static content. A Python app that makes static pages (for instance a collection of Jinja templates) is fastest.
After that, it's largely impossible to say. Even http://werkzeug.pocoo.org/ involves some processing overheads that may be unacceptable in the above scenario. Python can be slow.
Django, with a modicum of effort, is often fast enough. Serving static content separately from dynamic content, for example, can be a huge speedup.
Since Django does so much automatically, there's a huge victory in not having to write every little administrative page.
I'd say there has to be something funky with your setup there to get such a large performance difference. Try mod_wsgi (if you're not already) and follow the excellent suggestions by the posters above. If Django genuinely was this slow in all cases, there's just no way companies would be able to use it for production applications. It's more than likely not to be Django that is holding the request up. Once you have the .pyc files all sorted (automatically generated bytecode), then the execution should be fairly zippy.
However, if you don't actually need all Django has to offer, then why use it? I'm using it in quite a large production application, and we're not using all of its features… if you're doing something fairly simple, you may want to consider using something like web.py or Werkzeug (or something non-Python-based if you'd rather).
Frameworks like Django or Ruby on Rails grew out of real world needs. As different as these needs were, as different they turned out.
Here is my Experience:
As a former PHP programmer, I prefered CakePHP for simple stuff and Symfony for more advanced applications. I had a look into Ruby, but the documentation sucked back then. Now I'm using Django. Django works very well for me. In contrast to Symfony I feel like Django brings less flexibility out of the Box, but its easier to extend.
Another approach would be to use 'no framework' CherryPy
I think the host may be an issue. I do Django development on my localhost (Mac) and it's way better. I like WebFaction for cheap hosting and Amazon ec2 for premium hosting.
The framework is strong and it can handle heavy sites - don't obsess about that stuff. The important thing is to create a clean product, Django can handle it. There are about a thousand steps to take when you see how the application handles in the wild, but for now, just trust us that you don't need to worry about the inherent speed of the framework before exhausting a whole slew of parameters including a dedicated VPS/instance when you need it.
Also, following on your edit - I personally don't think performance is a major issue in programming. Here are the issues in terms of concern:
UI/UX efficiency
UI/UX speed (application caching)
Well designed models/views
Optimization of the system (n-tier architecture, etc...)
Optimization of the process (good QA to reduce failures/bottlenecks from deployment)
Optimization of the subsystems (database, etc...)
Hardware
Framework internal optimization
Don't waste time with comparing framework speeds. Their advantage is in extensible code, smart architectures, etc...
On a side note, DO NOT NOT USE A FRAMEWORK FOR A NEW WEB APPLICATION. I'm sorry I can't say it loud enough, but it's an absolute requirement nowadays. It's not even a debate about not using one, just which one to use.
I personally chose Django, which is great. But I can't definitively knock the others out there.
It's possibly both. Django does have stuff for caching built-in, which would be worth trying. Regardless, any non-cached page will nearly always take longer than a static file. A file has to be read in both cases, and in the case of a dynamic page, it also must be executed. And then, in both cases, sent over to the client.
Definetely shared hosting is not the best choice to run heavy frameworks such as Django or CakePHP. If you can afford it, buy VPS.
As for performance, probably your host uses Python with mod-python, which is not recommended now. WSGI is preferred standard for Python powered webapps.