Deploying your Django site doesn't have to be that painful. You can do it in a single command with https://github.com/gcollazo/Fabulous. It'll take you about an hour to have a full stack running with a bit of tweaking.
On 18 December 2014 at 11:11, James Schneider <jrschneide...@gmail.com> wrote: > > As a reformed PHP and Drupal developer, I can say with 100% certainty that > trying to crowbar Drupal (or any CMS) in to performing actions that are > outside of the built-in core functionality is a nightmare at best. I wrote > half a dozen custom modules (~6K SLOC), and at least 30% of that was wasted > code that simply overrode the default behavior of the CMS. I grew weary of > playing whack-a-mole with built-in constraints, and hit a point of > diminishing returns where I spent more time fighting with the Drupal > internals than adding needed functionality. > > Drupal is a relatively good CMS and has regular updates with an active > community. If your planned app fits within the CMS model, even with a few > tweaks from 3rd party modules, you can be up/running with a smaller amount > of raw developer effort if you keep within their sandbox. The biggest draw > for me at the time was not needing to build the HTML presentation layer and > letting Drupal handle the formatting using their theme system. As my > requirements grew outside of the CMS box, it became a hindrance. Obviously > I don't have that [dis]advantage with Django, and even the built-in admin > portal would likely cause me the same grief, so I'm rolling my own custom > HTML templates (which for me takes more time than the functional code > underneath). Authentication/authorization was another pain point with > Drupal, as it is much more tightly integrated into their core. I'm rolling > a custom auth solution for Django as well to meet my requirements. Don't > even get me started on the ridiculous amount of expensive SQL queries that > were run per request...almost everything in a CMS comes from the database. > I needed APC caching just to have a usable site for 20 concurrent users. > PHP just feels dirty, especially with inconsistent function naming schemes > using CamelCase or under_scores. Maintaining raw PHP code intertwined > inside of HTML templates is obnoxious. Django template abstraction with > tags, etc. is a much cleaner way to go, and keeps you honest in terms of > littering inside of your HTML templates. > > In terms of development time, I can have a blog running in Drupal in 10-15 > minutes with a custom theme. The equivalent in Django would probably be a > day or two's worth of work at best assuming that you already know what you > are doing and are awesome with HTML. There are probably Django packages > that would shorten that time, though. However, trying to build a pizza > ordering system in Drupal would require psychological therapy and probably > never be finished, but the raw logic of how to do it can be a day or two's > work in Django (depending on how good your HTML skills are). You might even > be able to do that in the admin and skip the HTML all together. Development > and time to production are heavily dependent on your skill set and > available resources for either product. If you don't know Python/HTML, > don't expect a fully working application in the blink of an eye. > > Keep in mind that Drupal is a CMS, with an obvious bias towards CMS-type > functionality (and is designed to be an almost entirely point and click > solution). Django is a lower-level framework that provides a toolkit to > build whatever you want (including not being limited to just rendering > HTML). Think of Django as a work truck loaded with construction tools and > lumber, and Drupal as a pre-fabricated house that just gets placed on the > foundation. You can pick the color of the house, but that's it, although, > for some people, a blue house is all they need. It's hard to compare the > two as they have different uses in mind. Not to mention that Python is a > much cleaner language in many respects, most notably for syntax and memory > management. > > As mentioned before, Rails is similar to Django with the big exception > being written in Ruby, rather than Python. Not sure what other magic secret > sauce they include, but I found anything with Ruby tends to be more magical > than pragmatic in my limited experience with it when I considered it when I > chose the Django path. > > > HTH, > > -James > > > > On Wed, Dec 17, 2014 at 8:38 AM, Scot Hacker <scot.hac...@gmail.com> > wrote: >> >> >> >> On Tuesday, December 16, 2014 1:15:57 PM UTC-8, Sayth Renshaw wrote: >>> >>> With django what benefit do I get for the extra build time over Drupal >>> or Rails. >> >> >> I'd strongly contest that statement. Development time might be roughly >> equivalent to Rails (given equally experienced developers), but compared to >> Drupal? I see Drupalistas struggling to convince the platform to do the >> simplest things, on a regular basis. With Django or Rails you build what >> you need and nothing gets in your way. I just blew the minds of people in a >> predominantly Drupal-centric establishment with a Django intranet/portal >> demo I built in three weeks - they couldn't believe it. Especially for >> development of more advanced features, I'd go head-to-head with a Drupal >> dev any day of the week. >> >> This is five years old now, and a bit long-winded, but I still stand >> behind most of it: >> >> http://birdhouse.org/blog/2009/11/11/drupal-or-django/ >> >> ./s >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-users+unsubscr...@googlegroups.com. >> To post to this group, send email to django-users@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/ff329c68-151c-41a5-a203-d66b6c8c6616%40googlegroups.com >> <https://groups.google.com/d/msgid/django-users/ff329c68-151c-41a5-a203-d66b6c8c6616%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVC4eDhiwa%2BibFeOThiOik%2BToaMTqukx6xxwCH9Kxboww%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVC4eDhiwa%2BibFeOThiOik%2BToaMTqukx6xxwCH9Kxboww%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAHqTbjm-m%3D30n1ANe6JMt%3DbN4-aKS2TbY2BAN%2BGDvZtCrDU%2B9Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.