Devils advocate question

102 views
Skip to first unread message

Sayth Renshaw

unread,
Dec 16, 2014, 4:15:57 PM12/16/14
to django...@googlegroups.com
With django what benefit do I get for the extra build time over Drupal or Rails. Configuration I assume but real world benefits not my/our joy of configuration.

Why hasn't a cms been designed off django or python? A language cultural effect yoy would think python would be more stable than php/drupal.


Sayth

Avraham Serour

unread,
Dec 16, 2014, 4:18:47 PM12/16/14
to django...@googlegroups.com
What extra build time?

you mean like https://www.django-cms.org/en/ or http://mezzanine.jupo.org/ ?



Sayth

--
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...@googlegroups.com.
To post to this group, send email to django...@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/a4c22366-0f9d-417c-8d09-5a0501f2f964%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tim Chase

unread,
Dec 16, 2014, 4:40:05 PM12/16/14
to django...@googlegroups.com, flebbe...@gmail.com
On 2014-12-16 13:15, Sayth Renshaw wrote:
> With django what benefit do I get for the extra build time over
> Drupal or Rails. Configuration I assume but real world benefits not
> my/our joy of configuration.

You're asking about two separate products.

Over Rails, the feature-sets are fairly even, so it's mostly a matter
of language preference. Some folks prefer Ruby and thus choose
Rails, while I prefer Python so I choose Django.

Regarding Drupal, that's a CMS. You can shoehorn it into
providing other features, but it will always carry those CMS biases
with it. While you can make your own bespoke CMS in Django (or, as
Avraham wrote, use one of many pre-existing projects). I'd much
rather make a domain-specific application in Django than try to
hammer Drupal to my will (omitting the fact that any significant
changes in Drupal require using PHP is an instant turn-off for me).

One of Drupal's biggest advantages is the same as for any PHP
project: deployment. For PHP projects, deployment can be done on
free or very cheap hosting services (under $5 (USD) per month)
and usually just involves dumping a bunch of files on a server via
ftp/ssh/scp/sftp or a web interface. For Django, it requires a lot
more configuration with mod_wsgi/wsgi/uwsgi/gunicorn/fastcgi/mod_python
and a server that lets you have such long-running processes.

-tkc



Sayth Renshaw

unread,
Dec 16, 2014, 7:03:01 PM12/16/14
to django...@googlegroups.com
Wow never knew mezzanine existed, that's interesting. Yes php hosting is cheap, but so is digitalocean and it fully supports python and django.

Sayth

Cal Leeming

unread,
Dec 16, 2014, 7:14:30 PM12/16/14
to django...@googlegroups.com
One thing to note, DigitalOcean is truly awesome but it is a no-frills service. You get an API and raw performance at dirt cheap pricing, everything else you have to handle yourself. 

If you don't have the necessary devops/sysadmin skills, e.g. knowledge of how to recover crashed databases, corrupt filesystems etc, then you might want to consider something like Heroku where you can leverage the power of build packs. This can get *very* expensive, very quickly, but for small databases and minimal throughput, you'll be fine.

To be clear, I don't want to put you off using DigitalOcean because I honestly think they are the best thing to happen to the unmanaged hosting industry in a long time. At the same time, you should be aware that this cheap, raw performance comes with a trade off. If you want to push and forget, use Heroku. But if you want excellent performance, low pricing and complete control, look at DigitalOcean + Packer + CircleCI. (you can push to git, which then triggers a CircleCI build, which then triggers a packer build, which then spins up a new VM at DO on that snapshot. However you then need to handle destroying old instances, and automating the switch over between instances, which would need to be some sort of LB or DNS change over using something like CloudFlare). It gets pretty intense :)

tl-dr; Deployment of Rails vs Django has the same considerations and complexities. You'd have to consider the above no matter which you use anyway.

As for which would be more preferable, that comes down to personal taste. My advice would be to review them all, pick two or three, and see which one excites you the most.

Hope this helps dude!

Cal

On Wed, Dec 17, 2014 at 12:03 AM, Sayth Renshaw <flebbe...@gmail.com> wrote:
Wow never knew mezzanine existed, that's interesting. Yes php hosting is cheap, but so is digitalocean and it fully supports python and django.

Sayth
--
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...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

Sayth Renshaw

unread,
Dec 16, 2014, 7:28:23 PM12/16/14
to django...@googlegroups.com
Definitely Thanks Cal.

Hadn't realized that with digitalocean. Been spending my time in ipython and R and plotly and wanted to get some stuff out there.

Rails not really in the equation too much black magic.

Saw pythonanywhere, Heroku, Bitnami they just don't have a fixed cost. Eg Bitnami says about $6.95 a month but it's about. I do something random abs could cost myself a bucket.

Sayth

You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/NmnbelIldz8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

Cal Leeming

unread,
Dec 16, 2014, 7:41:02 PM12/16/14
to django...@googlegroups.com
For what it's worth, you can cap your usage on Heroku, so any exceeded usage will just result in slow application rather than additional fees. For a small application with minimal traffic, a database, basic monitoring etc, you're looking around $40/month all in. Heroku is *not* a viable long term solution for growth, as the pricing really does become ridiculously high, but it'd perfect for small projects with low traffic projections and small budget :)

Cal

Tim Chase

unread,
Dec 16, 2014, 9:51:44 PM12/16/14
to django...@googlegroups.com
On 2014-12-17 00:14, Cal Leeming wrote:
> One thing to note, DigitalOcean is truly awesome but it is a
> no-frills service. You get an API and raw performance at dirt cheap
> pricing, everything else you have to handle yourself.

I'd call it "cheap pricing", not "dirt cheap pricing" since PHP
hosting can be had for $3/mo or even pushing free, depending on the
conditions & limitations you're willing to accept. For a small
one-off site, demo, or playground, the difference between hosting for
$60/yr vs. under $36 may make or break the hosting decision.

Ubiquitous availability and ease of deployment are the only things
that PHP has going for it, IMHO. If Django/Python could make
deployment as easy & ubiquitous as PHP, the world would be a much
better place. :-D

-tkc


Daniele Procida

unread,
Dec 17, 2014, 2:59:04 AM12/17/14
to Django Users
On Tue, Dec 16, 2014, Sayth Renshaw <flebbe...@gmail.com> wrote:

>Why hasn't a cms been designed off django or python? A language cultural
>effect yoy would think python would be more stable than php/drupal.

You mean like django CMS, to Fein CMS, Mezzanine, Wagtail or any of the other Django CMSes?

Daniele

Cal Leeming

unread,
Dec 17, 2014, 4:08:44 AM12/17/14
to django...@googlegroups.com
Deployment is completely separate to the code base, and the challenges faced from deploying a PHP/Rails app is exactly the same as you'd face with Python. It all comes down to what your release process is.. it could be argued that PHP can just be uploaded via FTP to XYZ host, but it could (and should) also be argued that this is not how you should do deployment properly.

The decision of language, framework, hosting, devops workflow (e.g. deployment etc) does not have a one size fits all. These decisions should be made based on your own use case and situation, including the skill set of your team, timescales, project goals, expected lifetime of the application etc. 

Sadly, despite all the tooling that exists, none of them really satisfy real world needs. And the ones that do are either hideously complex or excessively priced. There will always be some trade offs.


-tkc



--
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...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

Scot Hacker

unread,
Dec 17, 2014, 11:38:01 AM12/17/14
to django...@googlegroups.com


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:


./s



 

James Schneider

unread,
Dec 17, 2014, 7:12:13 PM12/17/14
to django...@googlegroups.com
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



--
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...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

Mario Gudelj

unread,
Dec 17, 2014, 11:32:15 PM12/17/14
to django...@googlegroups.com
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. 

Reply all
Reply to author
Forward
0 new messages