Functional Benchmark : Django, Rails, CakePHP
jchatard
Hello,
I'm currently writing a functional benchmark for french press (IT
news, programming magazine) about Django, Ruby on Rails and CakePHP.
I started to fill one Excel sheet with Django's assets but then I
thought that Django's community would be interested and much more
skilled than me to do that intself.
So I'm asking you if you could add some more stuff to this spreadsheet.
Feel free to send it to other Django users, so that I could have more
information.
The only problem, is that I'm kinda in a rush right now since I have
to finish this benchmark next week so it would be perfect if you can
send me this back on ASAP to jeremy....@gmail.com
Youc can find the sheet at http://www.jchatard.info/django.xls
Best regards,
Jérémy
--
View this message in context: http://www.nabble.com/Functional-Benchmark-%3A-Django%2C-Rails%2C-CakePHP-tf2466473.html#a6875806
Sent from the django-developers mailing list archive at Nabble.com.
Malcolm Tredinnick
On Wed, 2006-10-18 at 06:07 -0700, jchatard wrote:
>
> Hello,
>
> I'm currently writing a functional benchmark for french press (IT
> news, programming magazine) about Django, Ruby on Rails and CakePHP.
>
> I started to fill one Excel sheet with Django's assets but then I
> thought that Django's community would be interested and much more
> skilled than me to do that intself.
I'm always inherently suspicious of benchmarks like this, since my
natural question is "how much has the author actually *used* the thing
he is evaluating? Has he done real work with it?"
> So I'm asking you if you could add some more stuff to this spreadsheet.
> Feel free to send it to other Django users, so that I could have more
> information.
Most of what you have in the spreadsheet seems reasonable, although
there a few items that are close to IT buzzwords there that don't really
convey a lot of specific information (for example, what does
"internationalization really *mean* if an app gets a "yes").
You've left out email support and the standard Python exception handling
abilities in the error handling section.
The Operating Systems row isn't complete (also GNU is an acronym and is
all capitals and Django even runs on Linux systems that aren't
GNU-based :-) ). Django runs on any system that supports a database and
Python -- so pretty much any Unix-based system will suffice as well:
*BSD, Solaris, AIX, ....
You've written "no" for documentation generation, which is incorrect.
Have a look under the documentation tab in the admin interface. All of
the developer's models, filters, views and URL configs are documented
there using the information extracted via introspection.
The distinction between "built-in" and extensions seems a little
arbitrary. Syndication, site maps, multiple sites are all part shipped
with core, just like admin, for example. Yet the latter is considered
built-in and the former three are marked as extensions in your table.
The difference seems a bit arbitrary there.
Completely customisable URLs is an evaluation point (presumably the
other two platforms you are comparing do this as well, but it's clearly
not a truism in the industry).
I think most of your points under Documentation/Community are low when
compared genuinely to the other two products you are evaluating. You
should probably add mailing lists as a line-item there, too, since both
RoR and Django have extremely high-volume, very helpful mailing lists
(no idea about CakePHP).
Some Ruby-on-Rails bias shows through in the "scaffolding" line, since
that's not really an industry-standard term and Django has similar
helpful support to a lot of the RoR things in that area (not identical,
but not a subset, either). Things like support for existing database
tables and so on. You could just as easily have put in "automatic
support for populating models via web interface" (i.e. admin interface)
and have a Django bias and then Ruby gets a "no (but has scaffolding)".
Both approaches are not really comparing apples and oranges.
Your annotation for "language" in the "development" section just says
"Django templating language", which isn't even half the story. That is
one portion of on piece of the framework. The bulk of the coding is done
in Python -- the views, the models and the template tags. Django has a
separate language for the templates themselves in order to provide a
lower barrier to entry for page developers, but that is just one corner
of the Django world.
I would dispute your technology risk assessment (assuming three stars
means high risk), since Django is built on extremely well-established
technology (Python had public releases before PHP or Ruby -- or even
Java for that matter -- and the databases it is built on have been
around "forever" in Internet years). Experience suggests that, despite
the hype around Ruby, experienced Python developers are easy enough to
find (As easy as any other good quality experienced software developer).
It often seems like there are truckloads of PHP developers around, but
the pool empties out a lot when you attach "high quality" to the
requirements list. It is very easy for an experienced Python dweveloper
to understand how Django works, because working out even the tricky bits
from the source just isn't that hard if things get really hard (Python
source code has a real advantage in that it's naturally very readable).
Still, a judgement call like that is always going to be debatable,
regardless of what you put there. But the *technology* risk with Python
+ PostgreSQL/MySQL + Apache stacks is very, very low these days.
Difficult to judge some of the other assessments you've given, since I
don't know the calibration scale and it always depends upon prior
experience.
> The only problem, is that I'm kinda in a rush right now since I have
> to finish this benchmark next week so it would be perfect if you can
> send me this back on ASAP to jeremy....@gmail.com
If you would like us to help you with your work, please keep the
discussion on the mailing list. That's only reasonable.
Regards,
Malcolm
Kenneth Gonsalves
On 19-Oct-06, at 7:29 AM, Malcolm Tredinnick wrote:
> should probably add mailing lists as a line-item there, too, since
> both
> RoR and Django have extremely high-volume, very helpful mailing lists
and i hope he has mentioned our #django IRC channel - with a
reputation for never RTFM'ing anyone ;-)
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
jchatard
First, thank you for your answer, which is quite completed. I give some
answers next.
Malcolm Tredinnick wrote:
> I'm always inherently suspicious of benchmarks like this, since my
> natural question is "how much has the author actually *used* the thing
> he is evaluating? Has he done real work with it?"
I agree.
> Most of what you have in the spreadsheet seems reasonable, although
> there a few items that are close to IT buzzwords there that don't really
> convey a lot of specific information (for example, what does
> "internationalization really *mean* if an app gets a "yes").
I'm writing a document mainly for french companies IT deciders, so I
have to create a document which is easy to read. For exemple
"internationalization" with a "yes" only means that french companies
will be able to create a multilingual site. I know it doesn't speak
much but I think it's all they wants to know.
> You've left out email support and the standard Python exception handling
> abilities in the error handling section.
Ok, I'll correct it.
> The Operating Systems row isn't complete (also GNU is an acronym and is
> all capitals and Django even runs on Linux systems that aren't
> GNU-based :-) ). Django runs on any system that supports a database and
> Python -- so pretty much any Unix-based system will suffice as well:
> *BSD, Solaris, AIX, ....
Ok, I'll be more precise.
> You've written "no" for documentation generation, which is incorrect.
> Have a look under the documentation tab in the admin interface. All of
> the developer's models, filters, views and URL configs are documented
> there using the information extracted via introspection.
I've already corrected it.
> The distinction between "built-in" and extensions seems a little
> arbitrary. Syndication, site maps, multiple sites are all part shipped
> with core, just like admin, for example. Yet the latter is considered
> built-in and the former three are marked as extensions in your table.
> The difference seems a bit arbitrary there.
Well, I agree with you but in Django's wiki they are listed in the
add-on section, so that's why I mentionned them this way.
> Completely customisable URLs is an evaluation point (presumably the
> other two platforms you are comparing do this as well, but it's clearly
> not a truism in the industry).
Yeah, you're right.
> I think most of your points under Documentation/Community are low when
> compared genuinely to the other two products you are evaluating. You
> should probably add mailing lists as a line-item there, too, since both
> RoR and Django have extremely high-volume, very helpful mailing lists
> (no idea about CakePHP).
Be sure that Django is very well positionned concerning documentation
and community.
For my part as well as Rails.
> Some Ruby-on-Rails bias shows through in the "scaffolding" line, since
> that's not really an industry-standard term and Django has similar
> helpful support to a lot of the RoR things in that area (not identical,
> but not a subset, either). Things like support for existing database
> tables and so on. You could just as easily have put in "automatic
> support for populating models via web interface" (i.e. admin interface)
> and have a Django bias and then Ruby gets a "no (but has scaffolding)".
> Both approaches are not really comparing apples and oranges.
The way I describe features in the sheet isn't the final term (of
course it will be
in french at first). But my goal was to target frameworks users so that
they can quickly
give me their point of view. And it worked for you!
> Your annotation for "language" in the "development" section just says
> "Django templating language", which isn't even half the story. That is
> one portion of on piece of the framework. The bulk of the coding is done
> in Python -- the views, the models and the template tags. Django has a
> separate language for the templates themselves in order to provide a
> lower barrier to entry for page developers, but that is just one corner
> of the Django world.
For this point, what I want to point out, is that a Django newbie will
have to learn
Django template syntaxe, which isn't bad, but deciders have to know
that their
developers will have to learn it too!
One thing to remember, is that this benchmark is made to give
information about those 3 frameworks
for people who just know the name of "Rails, Django & CakePHP", but
don't really know much about them. This is not for geek or developers,
who already know about this stuff =)
> I would dispute your technology risk assessment (assuming three stars
> means high risk), since Django is built on extremely well-established
> technology (Python had public releases before PHP or Ruby -- or even
> Java for that matter -- and the databases it is built on have been
> around "forever" in Internet years). Experience suggests that, despite
> the hype around Ruby, experienced Python developers are easy enough to
> find (As easy as any other good quality experienced software developer).
> It often seems like there are truckloads of PHP developers around, but
> the pool empties out a lot when you attach "high quality" to the
> requirements list. It is very easy for an experienced Python dweveloper
> to understand how Django works, because working out even the tricky bits
> from the source just isn't that hard if things get really hard (Python
> source code has a real advantage in that it's naturally very readable).
> Still, a judgement call like that is always going to be debatable,
> regardless of what you put there. But the *technology* risk with Python
> + PostgreSQL/MySQL + Apache stacks is very, very low these days.
Yeah you're right, this is ambigous. What I wanted to say is that
Django isn't risky
at all ! So I've already removed stars and type "NONE" :)
> Difficult to judge some of the other assessments you've given, since I
> don't know the calibration scale and it always depends upon prior
> experience.
You already gave me lots of answers!
> If you would like us to help you with your work, please keep the
> discussion on the mailing list. That's only reasonable.
No problem!
> Regards,
> Malcolm
Thanks again,
Jérémy
jhernandez
>
> The Operating Systems row isn't complete (also GNU is an acronym and is
> all capitals and Django even runs on Linux systems that aren't
> GNU-based :-) ).
I think it's quite the opposite :-)
Django can run on GNU systems that doesn't use a Linux kernel.
And now show me a system that runs a Linux kernel and not use the GNU
programs :-)
--
Julián
Sung-Jin Hong
Bryan
reputation for never RTFM'ing anyone ;-)"
Bahahaha. And so true.
On Oct 18, 7:23 pm, Kenneth Gonsalves <law...@thenilgiris.com> wrote:
> On 19-Oct-06, at 7:29 AM, Malcolm Tredinnick wrote:
>
> > should probably add mailing lists as a line-item there, too, since
> > both
> > RoR and Django have extremely high-volume, very helpful mailing listsand i hope he has mentioned our #django IRC channel - with a
Kenneth Gonsalves
On 19-Oct-06, at 7:06 PM, jhernandez wrote:
> Django can run on GNU systems that doesn't use a Linux kernel.
seems like i have hurd this before