6 ms·

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 Rub

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?

ebbv 11y ago
For me this is the wrong question to start with. The right question is what language do you want to work in first. Then determine which framework for that language best suits your needs.
ahmad19526 11y ago
I would say if you anticipate any sort of data science and machine learning potential in your application, then you should choose Django (Python) because you'll be in the home turf for this sort of work and you won't have to deal with language context switching... But this is a big if and may not be worth considering.
- huac 11y ago
  If your app has data of a large enough size for serious analysis, shouldn't you be building a data warehouse separately and performing analysis on that? (scientific) Python is definitely better at stats out of the box than Ruby is though.
pbreit 11y ago
I'm shocked, frankly, at how lousy both are out-of-the-box. I just don't get why a simple CRUD app (which many/most apps are) has to be so difficult. I had trouble figuring out how to do email login on Django and just gave up. At first, Rails seems like it's going to be a lot better. I don't care for generating files. Don't like TDD. And found the migrations very confusing (if I make a typo in a field name, I delete the whole project and start over). 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!
- jsmeaton 11y ago
  Unfortunately it looks like you hit a bit of a sore spot with regards to django auth. There isn't a good out of the box solution for email based usernames. There are patterns available, and the "swappable" user framework is there to allow email based usernames. But an email based model isn't available. I'm fairly sure there are tickets or ideas to make this happen, but we're not there yet. 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.
  - iyn 11y ago
    One can use Custom User Models for things like email logins. I've done this in a few projects and it works great. More info: https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#substituting-a-custom-user-model https://docs.djangoproject.com/en/1.8/topics/auth/customizin...
  - japhyr 11y ago
    Do you know how well cookiecutter-django [0] handles email logins? I've been meaning to play around with cookiecutter, but I haven't started a new project recently. Cookiecutter uses django-allauth [1], which seems to offer email login methods, from what I see in a cursory look at the docs [2]. [0] - https://github.com/pydanny/cookiecutter-django https://github.com/pydanny/cookiecutter-django [1] - https://github.com/pennersr/django-allauth https://github.com/pennersr/django-allauth [2] - http://django-allauth.readthedocs.org/en/latest/configuration.html http://django-allauth.readthedocs.org/en/latest/configuratio...
    - jsmeaton 11y ago
      I asked pydanny on twitter and he says yes, thanks to django-allauth. Requires a setting in your settings.py file and it should just work.
  - Alex3917 11y ago
    I think a bigger issue with regards to usernames and email is the fact that neither are titlecased before getting indexed. I get that there are certain legacy considerations or whatever, but it really seems like there should at least be a note in the documentation about this given the massive clusterfuck that would potentially ensue should someone not figure this out before launching.
jsmeaton 11y ago
If you like Ruby, Rails. If you like Python, Django. Both are full featured with active communities. The 10,000ft view of each is very similar.
- greendata 11y ago
  I mostly agree. At this point they are both excellent frameworks with all similar features. Django has a really nice admin out of the box that some people love. 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.
- FireBeyond 11y ago
  Right - if you're not familiar with either language, then have a look. For me, at least, I could never really wrap my head around some Rubyisms. Python on the other hand, just "made sense" to the way my brain works. I can parse Ruby mentally, it just takes more effort. If you're familiar with both, and have no clear preference, the question becomes a lot less clear-cut.
nine_k 11y ago
For a small project I'd take Flask :)
dguaraglia 11y ago
I'll give my stock response when this question comes out: the reason why I chose Django back in the day (we are talking pre 1.0) was because it stuck with the Python philosophies of configuration-over-convention and "principle of least surprise". 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.
xirdstl 11y ago
Don't forget Grails
- Omnipresent 11y ago
  Still waiting on REST profile for grails.
  - vorg 11y ago
    Is anyone starting new projects in Grails, or upgrading from version 2 to 3 ? Perhaps that's why other projects are overlooking Grails nowadays.
    - xirdstl 11y ago
      Good question, I'm not really sure. HN isn't the right place to find out, though. There isn't a lot of interest in Grails in the Bay Area.
throwaway_ghj 11y ago
Are those options the state of the art? 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.
- sauere 11y ago
  Care to elaborate?
  - throwaway_ghj 11y ago
    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. 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.
    - ubernostrum 11y ago
      This is, of course, why nobody has ever bothered developing a unit-testing framework for a statically-typed language, and why it would have been impossible for the idea of automated refactorings to have originated in a dynamically-typed language.
      - throwaway_ghj 11y ago
        I didn't claim either of those things. 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.
deleted 11y ago
[deleted]
scrollaway 11y ago
I'd choose Django hands down between the two, but I'd pick Flask in the case of a smaller or less generically-cms app. 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.
jonesb6 11y ago
I don't think this is really the right medium to ask that question. You'll find certain topics (Golang, Django, Unicorns) get up voted heavily on Hacker news and I think this indicates a bias that'll hurt discussions like yours. 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.
jpmec 11y ago
Neither, I would choose Elixir with Phoenix Framework
chrismcb 11y ago
I just started a small site and chose django route over rails because I knew python and not ruby. This will be one of your biggest driving forces

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?

ebbv 11y ago

For me this is the wrong question to start with. The right question is what language do you want to work in first. Then determine which framework for that language best suits your needs.

ahmad19526 11y ago

I would say if you anticipate any sort of data science and machine learning potential in your application, then you should choose Django (Python) because you'll be in the home turf for this sort of work and you won't have to deal with language context switching... But this is a big if and may not be worth considering.

huac 11y ago
If your app has data of a large enough size for serious analysis, shouldn't you be building a data warehouse separately and performing analysis on that? (scientific) Python is definitely better at stats out of the box than Ruby is though.

pbreit 11y ago

I'm shocked, frankly, at how lousy both are out-of-the-box. I just don't get why a simple CRUD app (which many/most apps are) has to be so difficult. I had trouble figuring out how to do email login on Django and just gave up. At first, Rails seems like it's going to be a lot better. I don't care for generating files. Don't like TDD. And found the migrations very confusing (if I make a typo in a field name, I delete the whole project and start over). 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!

jsmeaton 11y ago
Unfortunately it looks like you hit a bit of a sore spot with regards to django auth. There isn't a good out of the box solution for email based usernames. There are patterns available, and the "swappable" user framework is there to allow email based usernames. But an email based model isn't available. I'm fairly sure there are tickets or ideas to make this happen, but we're not there yet. 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.
- iyn 11y ago
  One can use Custom User Models for things like email logins. I've done this in a few projects and it works great. More info: https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#substituting-a-custom-user-model https://docs.djangoproject.com/en/1.8/topics/auth/customizin...
- japhyr 11y ago
  Do you know how well cookiecutter-django [0] handles email logins? I've been meaning to play around with cookiecutter, but I haven't started a new project recently. Cookiecutter uses django-allauth [1], which seems to offer email login methods, from what I see in a cursory look at the docs [2]. [0] - https://github.com/pydanny/cookiecutter-django https://github.com/pydanny/cookiecutter-django [1] - https://github.com/pennersr/django-allauth https://github.com/pennersr/django-allauth [2] - http://django-allauth.readthedocs.org/en/latest/configuration.html http://django-allauth.readthedocs.org/en/latest/configuratio...
  - jsmeaton 11y ago
    I asked pydanny on twitter and he says yes, thanks to django-allauth. Requires a setting in your settings.py file and it should just work.
- Alex3917 11y ago
  I think a bigger issue with regards to usernames and email is the fact that neither are titlecased before getting indexed. I get that there are certain legacy considerations or whatever, but it really seems like there should at least be a note in the documentation about this given the massive clusterfuck that would potentially ensue should someone not figure this out before launching.

jsmeaton 11y ago

If you like Ruby, Rails. If you like Python, Django. Both are full featured with active communities. The 10,000ft view of each is very similar.

greendata 11y ago
I mostly agree. At this point they are both excellent frameworks with all similar features. Django has a really nice admin out of the box that some people love. 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.
FireBeyond 11y ago
Right - if you're not familiar with either language, then have a look. For me, at least, I could never really wrap my head around some Rubyisms. Python on the other hand, just "made sense" to the way my brain works. I can parse Ruby mentally, it just takes more effort. If you're familiar with both, and have no clear preference, the question becomes a lot less clear-cut.

nine_k 11y ago

For a small project I'd take Flask :)

dguaraglia 11y ago

I'll give my stock response when this question comes out: the reason why I chose Django back in the day (we are talking pre 1.0) was because it stuck with the Python philosophies of configuration-over-convention and "principle of least surprise". 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.

xirdstl 11y ago

Don't forget Grails

Omnipresent 11y ago
Still waiting on REST profile for grails.
- vorg 11y ago
  Is anyone starting new projects in Grails, or upgrading from version 2 to 3 ? Perhaps that's why other projects are overlooking Grails nowadays.
  - xirdstl 11y ago
    Good question, I'm not really sure. HN isn't the right place to find out, though. There isn't a lot of interest in Grails in the Bay Area.

throwaway_ghj 11y ago

Are those options the state of the art? 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.

sauere 11y ago
Care to elaborate?
- throwaway_ghj 11y ago
  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. 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.
  - ubernostrum 11y ago
    This is, of course, why nobody has ever bothered developing a unit-testing framework for a statically-typed language, and why it would have been impossible for the idea of automated refactorings to have originated in a dynamically-typed language.
    - throwaway_ghj 11y ago
      I didn't claim either of those things. 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.

deleted 11y ago

[deleted]

scrollaway 11y ago

I'd choose Django hands down between the two, but I'd pick Flask in the case of a smaller or less generically-cms app. 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.

jonesb6 11y ago

I don't think this is really the right medium to ask that question. You'll find certain topics (Golang, Django, Unicorns) get up voted heavily on Hacker news and I think this indicates a bias that'll hurt discussions like yours. 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.

jpmec 11y ago

Neither, I would choose Elixir with Phoenix Framework

chrismcb 11y ago

I just started a small site and chose django route over rails because I knew python and not ruby. This will be one of your biggest driving forces