Why Django and Rails CMS Are So Rare
gadgetopia.com
gadgetopia.com
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.)
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).
Plus, with the modules we're using we're more or less forced to use MySQL.
Rails site will be using Postgres.
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 are not doing this lightly. The current codebase has ~2.5 man years invested in it.
So in summary, I bet that purging PHP was tough, and I think you made the right choice.
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)
Most people have heard of WordPress. Some have heard of Rails. Almost no one has heard of Django.
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.
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).
e.g. http://www.itjobswatch.co.uk/jobs/uk/ruby%20on%20rails.do vs http://www.itjobswatch.co.uk/jobs/uk/django.do
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.
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)
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
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.
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”.
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.
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.
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.
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".
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.
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.
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.
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
Django was originally developed to build a CMS, for the Lawrence Journal-World
What part of Rails or Django do you have to rewrite because you are building a CMS?
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.
deploying a rails app on a server where ruby and the needed databse is installed is also "easy"
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.
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.
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)
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.
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.
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.
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'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.
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.
- 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.
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.
For this reason I usually use FeinCMS (http://www.feincms.org/) and configure/customise things according to my client's needs.