Not looking to start a fanboy-war here; but i would like to hear some opinions. If you were to start a new small to medium sized web app today, would choose Ruby on Rails or Django?
That said I'll take a stab with it, as I've worked with both. First off they're both MVC frameworks that prioritize a fast, convention-first, development cycle. They both are very well proven, they both have great documentation, and they both have a large number of resources detailing nearly every aspect of their deployment.
So for me it is really a question of these three things:
* what your team is used to
* what resources (capital to buy talent if need be, time to invest in research, etc.) are available to you
* what edge-cases your app might come across over the development cycle (do you need real-time features? might you use a niche data-store? do you have to connect with particular third-party services?)
For each of those points you need to do some planning and decide what the answer if for your team. I believe if you have a grasp on this the answer will be some what evident to you. If it's not, then I think you can just flip a coin because it won't matter to you.
It made debugging issues much easier than in the equivalent Ruby on Rails project (I tried to build the same proof-of-concept using both frameworks.) When something broke in Django I could usually just follow the code to find what was wrong. With RoR sometimes I would put stuff in some place, expect the framework to pick it up (convention-over-configuration) and the code wouldn't work. Much head scratching ensued.
If you like Python, Django.
Both are full featured with active communities. The 10,000ft view of each is very similar.
Rails is built with a "convention over configuration" philosophy. Rails apps tend to look similar whereas Django apps tend to be setup in a number of different ways. The downside of Rail's "convention over configuration" setup is that devs can get things up and running fast and then get frustrated and lost if something breaks....but it's really not that hard to dig around the code. With Django new devs get lost first and figure everything out. After a few months of heavy use and breaking things you won't notice much of a difference between the two. I find rails a bit easier to work with but I like python so I use django/flask.
If you're familiar with both, and have no clear preference, the question becomes a lot less clear-cut.
With that said, if you want something up & running asap, pick whatever you're good with and if you want to learn, pick whatever you didn't use before. Django and RoR are comparable.
I can't believe this is the current state of web app development. I know everyone's moved on to Node and Angular, but, c'mon!
Django really is quick and easy to get going though. If you can make your way past the email based usernames, I think you'd find a really capable and easy system waiting for you.
[0] - https://github.com/pydanny/cookiecutter-django
[1] - https://github.com/pennersr/django-allauth
[2] - http://django-allauth.readthedocs.org/en/latest/configuratio...
I agree this should probably have a solution or at least documentation to be wary of.
My big issue with the current state though is that if you're relying on usernames or email addresses being unique then you're potentially opening yourself up to all sorts of security issues without realizing it.
I'd probably prefer a functional unique index since it would be easier to maintain (rather than duplicate fields). We just need to get expression support into indexes.
1. https://docs.djangoproject.com/en/1.9/topics/auth/customizin...
And I don't see how assertions like this can be made: "This will usually be a username of some kind, but it can also be an email address"
Except for HN, Twitter & Reddit, are there any services that don't use email for login?
I guess sites that use the username as a form of identity within a site. Email address usernames are just identifiers and contact information, without really being linked to an identity.
I would think if auth was being written from scratch it'd probably default to email based usernames. That ship has sailed though.
Which meant that Django's database models couldn't migrate.
Even now, there is no real way to start with Django's own User model and switch your project over to a custom one later (because you'd have many database tables with foreign keys to the Django one). The current recommendation is to start new projects with a custom User model always.
However, you can use Django AllAuth (https://github.com/pennersr/django-allauth) to achieve an email login system by tweaking its settings.
Specifically:
ACCOUNT_AUTHENTICATION_METHOD = "email"
ACCOUNT_USERNAME_REQUIRED = False (if you do not want to use the username field)
More here: http://django-allauth.readthedocs.org/en/latest/configuratio...
Cheers!
In Django's case I would say their Authentication model was an opinionated choice that has since become a major staple of Django. Many frameworks will not include default ORM-models and will instead defer to the user to implement their own authentication scheme.
Personally I disagree with this choice, I think database schemas have to be flexible and an in-framework authentication setup will only encourage users to lean more on the framework even when it is working against them. I've burned plenty of hours in Django trying to work / extend the authentication model. While I have no doubt much of this was due to my inexperience with Django, there is a certain responsibility with having a framework used by many beginners who will struggle and perhaps pick up bad habits (like expecting your web framework to automagically solve everything) if you do not design it for them.
Overall I think Django is awesome. But it's not for every use-case, or every developer. About a year ago I moved over to NodeJS professionaly, some day I will perhaps go back but have yet to have any significant reason to do so.
(scientific) Python is definitely better at stats out of the box than Ruby is though.
I wouldn't use either.
Edit: added the following...
I've dabbled with both, and they suffer from the same kind of problem that all frameworks on top of dynamic languages suffer from. You essentially have to do all the checks that the compiler /should/ do for you, by using unit tests. That gets old fast. Also, on large code bases, I now prefer having real refactoring support.
I'd rather pick something on top of a compiler that is not brain dead.
If I had to do python again, I'd use pyramid or flask, and if I had to do ruby, I'd look at Sinatra.
I stand by my original statement, on the basis that both of the offered frameworks are built upon shaky ground to start with.
I'd rather pick something on top of a compiler that is not brain dead.
If I had to do python again, I'd use pyramid or flask, and if I had to do ruby, I'd look at Sinatra.
I stand by my original statement, on the basis that both of the offered frameworks are built upon shaky ground to start with.
I'm just speaking from the practical experience I have.
It's just that in static languages, you write unit tests more around business functionality. In dynamic ones you end up writing unit tests essentially for typing and stuff like that. And, you know, you have tooling so you can actually perform the refactorings at scale across the code base. Like real tools, that the rest of your team know how to use, and your business can hire another person from the same hemisphere to work with after you've moved on.
The tooling around static languages is generally stronger. I've written very similar types of code in both Java and Python, and hands down, I've found it easier to develop and maintain in big code in Java.
I still script quick stuff up in python for personal use.
YMMV.
That would be news to me.