Hacker News new | comments | show | ask | jobs | submit login
Why Django and Rails CMS Are So Rare (gadgetopia.com)
51 points by bergie 1696 days ago | hide | past | web | 63 comments | favorite



Additionally, if you're doing the build/buy/etc decision for any project which is going to need a CMS, you're not competing just against "Do it ourself in Rails, which we like", you're competing with "Download WordPress and get 80% of the way there for free."

WordPress is not the world's best software, but the ecosystem is fairly compelling, and it solves a lot of customer needs very, very quickly. (An off the shelf theme for tens of dollars or custom theme for hundreds gets many projects 100% of the way there.)


I'm actually going the other direction.

Our current implementation is a Drupal 6 site, and we are gearing up for a re-write in Rails.

For us, we find the 20% that isn't easily achievable to be a real pain point, and also that at our scale some of the design decisions in Drupal are pretty painful (20k+ users, 500k+ nodes).


Could you clarify on which design decisions prevents you from scaling to these numbers?


I'd like to know as well...the bottleneck with those numbers is likely to be the database, not Drupal, so if you switch to Rails and keep the same database, not much will change.


The DB setup in Drupal is very join heavy - on the new site many things that are joins in Drupal will be single table - many things drupal offers one-to-many on we only need one-to-one, so can avoid the join.

Plus, with the modules we're using we're more or less forced to use MySQL.

Rails site will be using Postgres.


So basically, because default Drupal's database schema is too normalized and generic you experience problems.

As for Postgresql - you are going to write new code anyway - either in Rails or patch Drupal modules to work correctly with Postgresql. So this one is definitely not a deal breaker.

I would advise also to look into option of upgrading to Drupal 7 and using its DB stuff. While it is still join-heavy by default, you have more power to manipulate schema and for example to have flat tables for your content types or store some stuff in MongoDB. And all of it with still Drupal's flexibility and mostly configuring stuff instead of writing it.


We've made the corporate decision - after many bad experiences - to purge PHP from production, for the sake of our sanity.

We are not doing this lightly. The current codebase has ~2.5 man years invested in it.


I strongly endorse this idea. The faster and more completely the development community moves away from using PHP in production, the better. I've started telling people not that PHP is bad, but that PHP is the avatar of technical debt. No matter what you personally do with PHP, the creators of the language and the other participants in the PHP ecosystem make it impossible to create a significant project in PHP without taking on ruinous amounts of technical debt - some of which takes the form of critical security problems! Python and Ruby, despite their faults, are more secure by default and have better security teams.

So in summary, I bet that purging PHP was tough, and I think you made the right choice.


From my experience technology is a big factor, but not ultimate. Ultimate factor is community around particular project. I truly believe Drupal community at this point is just right mix of following standrds and being focused on innovating in the same time. Whenever you custom code - you loose this huge leverage otherwise you could have by re-using existing UI/code/architecture (where architecture might be first and most important in the list.)

Anyway, I truly wish you luck with you project, but I would advise not to drop any particular technology just for sake of dropping it.

(I am not PHP fan, I am Drupal and Drupal community fan)


More importantly, the consumer knows that if they use WordPress they can fire their current programmers and find someone else.

Most people have heard of WordPress. Some have heard of Rails. Almost no one has heard of Django.


That is absolutely not even close to true unless you are talking about solely non-technical types, who have no reason to even consider FRAMEWORKS like Rails and Django vs CMSs like Wordpress. Instagram, Pinterest, NASA, Disqus, Mozilla, The Onion, Washington Post, NY Times, PBS, etc. all used Django heavily.

Just because YOU don't use it, doesn't mean it isn't popular. You committed a social proof. Django is far more popular in many circles than Rails. As Rails is far more popular in others.


There's a difference between big sites using a particular stack and people (thinking mainly pointy haired boss MBA types) having heard of it.

Lots of people have heard of wordpress because they have probably visited blogs with URLs that look like something.wordpress.com and they may have used it to write their own blog.

Some people will have heard of rails because it had huge hype at around ~2006 and very vocal advocates including 37s who were known through other avenues because of basecamp and because they blogged a lot.

Django on the other hand you may well not have heard of unless you have some knowledge of python or MVC frameworks (or read HN).



> I can think of only four offhand (meaning, without using Google): > Ellington and the inventively-named Django CMS for Django

http://mezzanine.jupo.org/ is quite popular, I think.

The answer to the main question lies somewhere else IMO. Those CMS from the PHP family got their fame because of the very low barrier of entry to deploying a PHP app (read: ftp). No mommy-blogger will have a clue how to install a Rails/Django CMS, so the target audience is different. Putting it short: PHP CMS are for users, Django/Rails CMS are for developers.


There are approaches for bridging this developer - content producer gap. http://createjs.org helps to bring sensible editing tools to any web app, and for example Symfony CMF provides content management functionalities to the popular Symfony2 MVC framework.


I hadn't seen createjs before, interesting.

It's not obvious that it's quite a drop in fit for a Django app though - is there an existing createjs/django app I could look at? (googling the obvious is not showing anything)


Some of our guys have been looking at that, but I don't know if they've released any code for it yet.

However, Create works quite well with various different back-ends (PHP, Java, Node.js, ...) as the only things you need to support are RDFa annotations in your templates, and some way to Backbone.sync changes back in. So I don't think Django integration would be particularly difficult.

Previous HN discussion on Create: https://news.ycombinator.com/item?id=3344412


I've also used http://www.feincms.org/ on a few projects with success. Was the most minimalistic CMS out of all the ones I tried.


Your point could have done without the [casual?] [unintended?] sexism: “mom” is not synonymous with “technically unskilled”.


The only sexism evident here is your own. Why did you assume that "mom" is the dominant descriptor in the term "mommy blogger" rather than "blogger" or the whole term? Why did you jump on the chance to cry sexism without knowing the definition of the term you were taking issue with? "Mommy blogger" is a term with a specific meaning, not just a synonym for mother.

It seems that the language police have been ramping up their efforts recently on HN. That is extremely unfortunate. Reading comments would be a much better experience if the pseudo-causeheads would at least attempt a rational discourse.


I once said something about teenage coders and someone raised the ageism banner. Political correctness is getting natzee in here sometimes, like we got binders full of women or sth.


> Why did you assume that "mom" is the dominant descriptor in the term "mommy blogger" rather than "blogger" or the whole term?

If he'd meant "blogger" generically he could simply have used the word unmodified. Instead, he specialized it by using a gendered term to repeat a common stereotype about a broad class of people. Have you ever heard anyone use a neutral or male identified term in a context like this? Would the point have any way been worse as “No sports-blogger“ or “No photo-blogger”?

As for your attempt to claim that this is somehow due to my not knowing the definition of the term, I would note that your choice to resort to personal attacks rather comically undercuts your proclaimed desire for “rational discourse”.


>Have you ever heard anyone use a neutral or male identified term in a context like this?

How about "brogrammer"?

>your choice to resort to personal attacks rather comically undercuts your proclaimed desire for “rational discourse”.

It's actually not ad hominem, since I'm using your own words against you. What you typed betrays latent sexism. I'm not just calling you a sexist without evidence.



And he could have done with less unprovoked politically correct corrections on HN, especially when they are factually false. A programmer's mom may not be synonymous with "technically unskilled", but statistically speaking, the overwhelming majority of them are. Should we pretend that this is not the case in order to satisfy some "non sexism" criterion?

Not to mention that HN's readership is not just US based. It is cultural imperialism to enforce US-centric PC notions on a international platform. At the least, it is provincialism.


> And he could have done with less unprovoked politically correct corrections on HN, especially when they are factually false. A programmer's mom may not be synonymous with "technically unskilled", but statistically speaking, the overwhelming majority of them are

So are the overwhelming majority of many other types of bloggers - in fact, the unmodified term “blogger” would have carried the meaning equally well. The choice to specialize the term in a highly-gendered manner is unnecessary, particularly when it reinforces common stereotypes and using it adds nothing to the actual point being made. That's why I suggested this was not deliberate: it's so common in mainstream society that many people aren't even consciously using it.

As for your “cultural imperialism“, “provincialism”, those terms have specific meanings which aren't relevant - they are not simply free passes for you not to have to think about topics which make you uncomfortable.


>The choice to specialize the term in a highly-gendered manner is unnecessary, particularly when it reinforces common stereotypes and using it adds nothing to the actual point being made.

It does: it presents the point in a well understood idiom, something people can easily relate to, not to mention being statistically correct. It also avoids him self-censoring his speech because of what some vocal over-tight prudes might think. The republican right does enough censorship --there's no need for a progressive censorship to pile up on it.

>As for your “cultural imperialism“, “provincialism”, those terms have specific meanings which aren't relevant - they are not simply free passes for you not to have to think about topics which make you uncomfortable.

No, they are perfectly relevant here. You come here thinking that your little PC diatribe applies the world over. It is not.

There are cultures in perfectly modern western societies that view those PC notions with ridicule (of which "So he said mom to imply non-tech-savvy-person? Big f'n deal" is the more polite version), if not frown upon them. Not everyone shares the very protestant hypocrisy of covering their past crimes (e.g racism, sexism) with current guilt.

To project that PC ideology (and to ask to enforce it) to the international HN audience is the very core of provincialism, in the sesse of the George Bernard Shaw quote: "[H]e is a barbarian, and thinks that the customs of his tribe and island are the laws of nature".


You keep misusing the term censorship: asking someone to reconsider their choice of words is not the same as saying that they should not be allowed to say it. Freedom of speech is not freedom from criticism.

I find amusing that you ended it with a quote which more accurately describes your own actions. I hold no illusion that cultures vary or that equality is far from a law of nature – that was rather the point in asking someone to consider how unconscious statements might sound to other people.


>You keep misusing the term censorship: asking someone to reconsider their choice of words is not the same as saying that they should not be allowed to say it.

No, but it's close enough for our purposes. They main difference is that you have not the power to forbid them. If you had, you might have gone the full way. There are, after all, many politically correct prohibitions in place in a few western cultures that made it into law.

>Freedom of speech is not freedom from criticism.

Criticism of the other's _way of speaking_, instead of criticism of their ideas, borders, as I say above, with censorship.

>I find amusing that you ended it with a quote which more accurately describes your own actions. I hold no illusion that cultures vary or that equality is far from a law of nature

Yes, but apparently you still hold the illusion that your (culture's) way is the one that has achieved the more equality, and that the method your culture has chosen to deal with equality is the correct one.

Which is kind of amusing from a culture with, say, an embarrassingly disproportionate percentage of their black population in jail.


The target audience for a CMS and a Framework are quite different. CMS is aimed at the end-user while frameworks are for programmers. This is significant if you look at the popular languages for CMSes like PHP or ASP. In these languages you can "deploy" the solution by just unzipping files into a folder. Django and Rails need a lot more work. Practically, if you need a full-blown CMS there is very little need to look at the languages with complicated deployments.

Also, a Framework and a CMS attacks the problems space in two different ways. Frameworks are bottom-up while CMSes are top-down. So solutions built in Django and Rails do not carry all the bloat and latent runtime functionalities that a CMS carries.

Lastly, even though Rails and Django are the leading frameworks, it is wrong to expect a CMS to be built using them. Theoretically, you can use a microframework like Flask because you are going to rewrite most the framework functionality anyways.


"In these languages you can "deploy" the solution by just unzipping files into a folder. Django and Rails need a lot more work."

Totally agree with this. It also smells like an opportunity for someone. In the age of Heroku, it feels like the process should be a lot easier. I.e.:

* Download a Django or Rails based CSM.

* Create a Heroku account

* ./manage.py deploy_heroku

* Profit


Why even require the download and command-line steps? You could probably wrap this all in a nice web interface


> Django ... it is wrong to expect a CMS to be built using them.

Django was originally developed to build a CMS, for the Lawrence Journal-World


> because you are going to rewrite most the framework functionality anyways.

What part of Rails or Django do you have to rewrite because you are building a CMS?


Probably the user model, permission system, flat pages, media handling and comments system. Or probably extend all of that. I am not saying that it is impossible. But merely pointing out that Python web framework ecosystem is rich enough that many of its hundreds of frameworks are possible options.


> I am not saying that it is impossible.

And I am saying far from impossible, it's quite convenient. If I am using rails, I will plugin devise, couple it with can-can and be done with authorization and authentication. Django makes enough assumptions about the user model, but not enough to warrant not using it for a CMS system. Django flat pages is a small CMS system, but in practice is useful only when the developers are creating/editing content. If it meets my requirement, I sure as hell will add admin & flat-pages apps, do minor tweaks and call it a day.

I don't see how any of it is a hindrance.

> But merely pointing out that Python web framework ecosystem is rich enough that many of its hundreds of frameworks are possible options.

I didn't contend Python ecosystem isn't rich enough. I am merely pointing out that "Django or Rails is not suitable for writing a CMS" is not true. A CMS can be as simple or as complex as you want, but the average CMS is the simplest kind of web application. Rails and Django make the task easier, not harder, and Django came out of a newsroom CMS.


this "easy" deployment only works cause most webservers allready got the apache mods,php,mysql dependencys installed.

deploying a rails app on a server where ruby and the needed databse is installed is also "easy"


Having used both Drupal and Rails fairly extensively, I yearn for a Rails CMS with the community and variety of modules in Drupal. I hate doing Drupal development, but from a return on investment prospective, in many use cases, Rails actually loses to Drupal.

In Drupal we can often get 2/3rds of our app for free, which productivity-wise has let us accomplish things in timeframes that would be impossible in Rails.

If something with Drupal's advantages were available within Rails (as an engine or what have you) it would be a clear game-over for other stacks vs. Rails.


> If something with Drupal's advantages were available within Rails (as an engine or what have you) it would be a clear game-over for other stacks vs. Rails.

I have to disagree here. There are clear use cases for either Drupal or Rails. I understand why you yearn for a Ruby Drupal, because dealing with PHP is a hassle, but objectively there is little to be gained since Drupal is already a beast and performance would only be hurt by being ported to Ruby.

Aside from that, the key advantage that Rails or other low-level web frameworks have over Drupal is that they don't make any assumptions beyond the fact that you are using HTTP. With Drupal there is an incredible amount of pre-existing architectural cruft to enable its powerful functionality, but it creates a ton of overhead to deal with as soon as you want to do something that doesn't neatly fit it's paradigm. As soon as you brought something like this into Rails then you'd be defeating the purpose of its simple elegance.

I just don't see any way to separate out the best of both worlds. They have very distinct use cases.


To be clear, I don't want it in Rails core. I want someone to make a framework that can run in Rails where I can pull in giant duplo-blocks of functionality.


But what would be the advantage over just running Drupal on PHP?


> Having used both Drupal and Rails fairly extensively, I yearn for a Rails CMS with the community and variety of modules in Drupal.

Why, if not for religious reasons? Drupal already exists, and there's no compelling business reason to reimplement it in Rails. (otherwise somebody would have done it already)


Because Drupal is a mess. It is like a naturally evolved organism with vestigial organisms and the difficulty in refactoring that comes along with it. The hooks are all global in scope. It all works, but it is all over the place. Using Drupal makes me feel productive, but dirty. And to develop any new functionality the Ruby/Rails stack is much faster. So the reason to want something that marries both is to get fast development for new parts, and giant reusable Duplo's for the repetitive common app parts. If I was religious about these things, I would not be developing in Drupal in the first place... :-)


What if the Drupal productivity is directly a result of the messiness?


Interesting theory, but the productivity is almost entirely due to not having to write large blocks of code. For example, in our last project, I didn't have to write an admin interface, users, roles, authentication, tagging, forms and more. The messiness was tangential, not useful.


There doesn't seem to be as much turnkey rails stuff in use as there is PHP (or perl) stuff across the board. Other examples would be phpBB or phpMyAdmin and vBulletin.

I wonder if part of the gap is perhaps cultural. Rails comes out of 37 Signals who made lots of money doing Saas so they are going to be something that rails developers naturally aspire to.

In an instance where a PHP developer might say "I can make this software, I'll put it up as OSS or I'll make it commercial and charge a fee to download it" a rails developer might think "I'll stick it up on my own servers only and charge people a monthly fee to use it or have an ad supported model".

In other words , rails people may just be a bit more entrepreneurial. PHP also grew up in an age where you would probably be considered a bit crazy to do all your project management on the web.


Aside from PHP being around twice as long and around for years during the nascent phase of open source web apps, the number one reason it has more and more popular turnkey apps is the same reason it "killed" perl: easy deployment.

The secondary reason is indeed cultural, but not it's nothing so abstract as what 37signals does. Rather it's the technical culture of moving fast and breaking things. With Rails you need to stay on top of upgrades all the time. If you are actively working on an app then this is a net benefit because you get new features. But it also creates maintenance work downstream, and not just with application code, but application servers are also relatively unstable. When you have something with a high heterogenous installation count like WordPress or other popular open-source apps, the pain of maintaining version compatibility and keeping it running over time far dwarfs any benefit of using a more powerful language like Ruby.


You would still have an update problem with wordpress since it's a very popular attack target. One of the things that has made me shy away from using it is fear of running into a problem like "we need to upgrade to version X in order to fix a security issue, but version X breaks plugin Y".

I guess what I was mainly getting at was that prior to around the time that rails and 37s got going the idea of paying monthly for web based Saas hadn't really exploded in the public consciousness (of course this was due to many factors other than 37s and rails).

So web developers who didn't want to do consulting would naturally think of the shrinkwrap type model first as a way of selling software.


Sure dependency hell, it's a problem anywhere. It's the worst in Rails though. Absolutely 100 times worse than PHP.


I think timing is big here. These content management systems came out at just the right time and they have had a long period to evolve and further entrench their market positions.

At the time these things came out, even basic features were a big deal. PHP was the only platform which was easy to deploy on shared hosting (VPS and cloud were unknown terms at that time.) Today these systems occupy a niche where there is enough demand to give them a seriously high profile on the web but the space isn't compelling enough to make developers spend a lot of time here. There also isn't compelling reasons for consumers to switch away from the big players.

Today, I think the CMS is an aging idea.It seems that every day I see some new component or service which I could just drop in to an app to build as another piece to building a custom CMS. Eventually it may be as easy to create a custom CMS as it is to configure an existing one today. Not that it's not already easy to throw something together with just Rails and some add-ons. You can get a long way with Rails barely even knowing Ruby.

Also, as we move closer to an API web with a client (mobile and web) heavy in JS consuming JSON, then a CMS probably needs to change quite a bit to stay useful. The CMS would basically just be a publishing tool to create content for the API. It would be less useful for creating layouts and generally dealing with the front-end. Mobile would need something else entirely.

I don't think these things are going to go anywhere for a long time. The niche need will be slow to die. But I just don't see a big opportunity for putting in the hard effort of creating one now. The available systems are largely good enough.


I was discussing this the other evening.

I've written a Django CMS that for in-house use.

In some ways there's not much to it and it could easily be broken into separate things:

Mainly:

1. WYSIWYG integration

2. An extensible 'Page' model

3. A way to generate site navigation

4. Admin customizations to make it more friendly for users.

In addition I reuse some excellent 3rd party packages.

Now - there are alternatives to all 4 things above that I could have reused but they were either lacking or not around when I started. I've ended up with something that covers my target market pretty well.

However I do feel there's room for another layer on top of Django - or maybe just some more reusable app conventions and a kind of 'CMS standard library' that made it more obvious to a newbie what to try first.

I know this isn't far from what Pinax was attempting but that seems to have gone very quiet.

Actually - several of the Django CMS projects are designed to be very lightweight and modular (FeinCMS is one - I borrowed some of their code and the author was very helpful) so maybe they already fit this bill.


They are not rare, there are CMS systems not covered in this blog post. On the Ruby side, take a look at the Ruby Toolbox to see many more content management systems: https://www.ruby-toolbox.com/categories/content_management_s...

It has the built-in "Well, there are a lot of CMS apps but not many used," but the other side of that is that there two (maybe three) very-popular and often-used content management systems in Rails that the author does not even mention. He claims to "spend more time looking at content management than most people" but then he has no knowledge of the most popular ones??

This statement is the biggest whopper:

"The existence and competence of Rails and Django have prevented a serious, shared CMS ecosystem from developing around either Ruby or Python."

I develop apps in Ruby and Rails, and it's the exact opposite. I use great systems like RefineryCMS or Spree to quickly get the framework of a site together, I pull from a massive amount of gems to get most of the functionality that I want, I reuse my private gems to get features specific to my needs, and.... at the end of the day, I only write what little code I need that is truly custom to the client's needs. I'd say that it takes some of the fun out of developing web apps if I wasn't happy being so productive.

The build-your-own aspect he mentions is true, though, but it's a problem with developers more than with the existence of Rails or Django. In my experience, many devs would rather work on their own because programming is fun and they want to solve problems like that -- and they want to be paid for that work. The way it usually works is, a dev will look at a tool, find some obscure reason why it "won't work," and then spend the time building his or her own. And since many managers don't have the knowledge to override bad developer decisions, they get away with it.


So what Ruby or Python framework offers out of the box for the end users:

- Worflows

- Content of management, publication dates, input formats

- Integration with multiple types of data sources

- Easy WYSIWYG manipulation of pages for content editors

- Out of the box integration with multiple notification mechanisms

- Click tracking for report generation

- ...

A CMS is much more than building a frontend with some set of templates and DB plugins.


Another CMS for Rails : http://www.locomotivecms.com/ didn't have much chance to play with it, but on paper, it's support i18n, custom content types and associations (belongs_to, etc.) and also give you an automatic JSON API.


Another major Rails CMS is Refinery CMS. I've been working with it for a while and it is really good! It just follows the Rails way and it has a lovely content-only backend. http://refinerycms.com/


My agency wrote a rails CMS called Atreides powering at least 20 sites with high traffic and recently open sourced it. It was very much inspired by Tumblr's simplicity but adds a lot of flexibility particularly with images, videos, social components, analytics, and mixed media content creation. http://the88.github.com/Atreides/


Looks interesting. Just a quick tip, the <title> tag spells Atreides wrong.


Well, PHP CMS's popped up like crazy because a lot of PHP frameworks didn't exist or weren't popular yet when the CMS's started popping up. Also PHP has had a history of being anti-framework or a lot of reinventing the same framework concepts over and over again. With a decent MVC framework you can roll your own blog/cms in like an hour for the most basic of functionality.

With ruby and python having great frameworks for building things fast, devs are more likely to roll their own custom CMS than they are to use an off the shelf CMS that doesn't quite fit their needs.

In fact, django was built so that the devs working at newspapers could crank out little custom CMS's for their various data projects incredibly fast. It started as a CMS framework, so of course it would remove the need for a generic community CMS.


Built lots of CMS in Django. In my experience, they are usually custom and never the same.

For this reason I usually use FeinCMS (http://www.feincms.org/) and configure/customise things according to my client's needs.


Obligatory link to Django Packages: http://www.djangopackages.com/grids/g/cms/


Django CMS is very good and pretty popular. I've used it on 5 decent sized projects now and my clients love it's in-page editing. The dev community is active and the next version looks really promising.


Could it just be because Rails and Django are FRAMEWORKS and not just CMSs?


Yes this is what the article says. I've started playing around with Ruby On Rails and really appreciate the way the framework is structured. Before that I was dabbling in node.js and had to make up my own project structure, which could end up doing more harm than good by making me confused. Moreover, in node.js I had to download multitude of modules just to get some basic features working whereas with Rails I have a plethora of already available features which really makes my life easier. I have never touched Django but I do believe it comes with lots of boilerplate to help you hitting the ground sprinting!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: