5 ms·

I'm the author. Yeah, there is a non-zero chance of that happening. However, I keep discovering more and more Rails design choices that either match or closely

I'm the author. Yeah, there is a non-zero chance of that happening. However, I keep discovering more and more Rails design choices that either match or closely align with my preferences. The three biggies comparing to Django are: 1) Powerful templates (including the convenience of "Helpers") 2) Non-declarative schema ORM with full migration support 3) Form validation and generation with Rails doesn't suck Lastly, Rails feels battle tested and production ready. Everything from the Rake tasks, to the framework surface area, to the plugins available seems tuned for real applications. Python stacks I have tried often require a lot of hackery to handle server configurations, deployment, content builds, template helpers, ... the list goes on and on.

andrewingram 16y ago
I can't disagree on ORM and templates (I disagree with the lack of proper method invocation in Django templates, it annoys me having to create tags for trivial things). I kind of disagree on the form validation though. Having used a number of frameworks prior to Django (including Rails for about a year), I love the way forms are handled in it - it just seems to make sense to me.
jnoller 16y ago
I think you and I both know - once you've run with something long enough, you hit a wall. Everything - every language, framework or tool hits a wall. You hit yours with Django because you fundamentally disagreed with some of the design decisions. I personally have not hit my wall (with django) but I see plenty of room for improvement. It's awesome you built something so quickly with Rails - I have a similar experience with Django (a tiny amount of time to build a really deep application). I personally found it amusing/bothersome that you were lauding a fairly magical and opinionated framework when you had old posts deriding Django (and it's ORM) in the past.
- snprbob86 16y ago
  I like opinionated software. Especially when it matches my opinions. And if it doesn't match my opinions, it is easy to dismiss it. It isn't the magic about Django (and it's ORM) that I didn't like. It was the design decisions that didn't match how I think (and approach of declaring the DB schema in code).
  - jnoller 16y ago
    We (mostly) agree then. The non-opinionated stuff makes me 1000x more angry then something silly like lack of class-based views, or the inclusion of GIS in contrib (for Django). I was probably overly sarcastic in my original comment, so for that I'm sorry.
- berntb 16y ago
  >>once you've run with something long enough, you hit a wall. Hmm... resonates. Sounds like an insight. That would implicate flexibility in languages, editors and frameworks -- so you can tunnel through the wall. More Ruby/Perl than Python and more Emacs/Vim than most IDEs. Etc.
  - jnoller 16y ago
    Nice try; but having more flexibility can be just as damning as not enough. Me, and plenty of others, have found that we know where, say, Python's wall is and accept it or we go around it. The wall I'm talking about is the mental barrier where you either no longer want the tradeoffs involved, or find you disagree with a fundamental axiom of the thing under inspection. Drilling through it is impossible without discarding it entirely. Having flexibility to drill through that wall just puts a bigger, harder wall someplace else. And other people find Emacs/VIM ideas perfectly workable IDEs, and find the flexibility of Emacs and VIM horribly confusing. You have to know, and accept the wall and limitations - it's a series of tradeoffs, and you just need to know what you're getting in the trade. In the case of frameworks, it's just a bigger set of tradeoffs as they tend to be a lot more opinionated, which means you're trading more for comfort.
    - berntb 16y ago
      Hmm... I don't yield the point yet. :-) Emacs is use optimized, not learning optimized. It takes lots of time -- if you don't use it for hours a day, it is probably not worth it. Org mode in Emacs is a good example. It took embarrassing long to learn for me -- while the GUI variants (e.g. gjots2) are trivial. But now, I can take notes and doodle with Org mode that I could only do on paper before. It is built into my fingers in a way which IDEs/GUIs failed for lots of years. I'd argue that Emacs is without a wall for programmers. (-: As long as you don't want to do word processing with WYSIWYG. :-) The problems will be new areas, like how will text understanding libraries (theoretical concept, not in that area) integrate with Emacs compared to others. You could probably do the same arguments for Perl and Lisp. But I don't know any framework I'd say the same about. Edit: Thinking back on my life, I'll yield the point re frameworks. Not libraries, for a not too large problem (a pack of collected libraries would have a wall in a bad Big-O for complexity/time). Edit 2: You could put my argument to be that the last decades of history shows Emacs to be, for all practical [programmer] purposes, infinitely flexible -- as long as new functionality can be integrated to the normal Emacs usage. Which is a big caveat, yes. Org isn't the first generation of that kind of note taking modes in Emacs, the evolution was afaik in much how Org was used.
ubercore 16y ago
Can you elaborate on the non-declarative schema point? With something like Django's South handling migrations, what problems does the declarative schema introduce that Rails side-steps?
- snprbob86 16y ago
  I wrote about this here: http://blog.brandonbloom.name/2009/10/orms-and-declarative-schemas.html http://blog.brandonbloom.name/2009/10/orms-and-declarative-s... It is a subtle, but fundamental distinction: Django expects me to declare my schema in Python. Rails (and optionally SqlAlchemy, which I like) operate via schema reflection. The declarative approach is redundant, error prone, and resistent to migrations, even with South. The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment.
  - Pewpewarrows 16y ago
    The declarative approach is only redundant if you're inheriting a project, and even then it's only redundant that first time you mirror the existing db schema in Python. How can you call a declarative method redundant and not schema reflection? They're reverse processes of the exact same thing. The only "errors" I can think of that can arise from declarative over reflection is when someone decides to manually fuck with your database while ignoring your framework's tools. And even then, South basically handles every use case. How exactly do you think South is resistant to migrations? Updating your models.py and running two manage.py commands seems pretty damn straightforward to me. "The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment." So, you're saying that because one way looks like what you were doing before a framework, it's somehow "better?" What kind of backwards logic is that? It's basically the definition of abstraction.
  - phaylon 16y ago
    Sounds like what's missing is the ability to create the schema from the declared code. Which I actually like better. Because it means I can re-use parts of my model like any other code.
deleted 16y ago
[deleted]
neeleshs 16y ago
I am building an app with Django. Can you elaborate on #1 and #3? While I agree with you on #2 to a certain extent, the extend/include and templatetags of django templates is reasonably powerful and at the same time does not pollute the templates with lot of code. Form validation - Custom form fields and custom widgets/multiwidgets actually have made my life simpler by allowing me to build reusable form widgets+validation logic. One piece I sorely missed in Django was model level validations. With the latest version, this is included as well. Note: This comment is definitely not to ridicule your conclusion, but more to learn from your experience. [Edit: Formatting]
Pewpewarrows 16y ago
1) I haven't run into a single instance where custom django template tags can't do exactly what I want with the same ease as Rails' Helpers. 2) http://south.aeracode.org/ http://south.aeracode.org/ 3) I don't understand how anyone can prefer another framework's form tools after using django. Like others have said, considering your past posts, it's just a matter of time before you starting hating Rails. To each their own, but I don't see any of your points as being a valid reason to like Rails over django.
- rcoder 16y ago
  I don't want to get into a framework war or anything -- in fact, I'm a Django developer currently after several years working with Rails, and relatively happy with the switch. That being said, both #1 and #2 above are plain wrong. Django template tags are a PITA to write, have weird inconsistencies (largely due to the first issue causing them to be implemented in a very hack-ish way) and don't have access to any request or application state that isn't explicitly added to the template context. Rails template helpers are powerful, easy to write, and ubiquitous. Those properties also make them easy to abuse for functionality that should absolutely be in a model or view function. South, on the other hand, is powerful, complex, and not part of the Django core. That simple fact immediately makes is less useful. Any Rails developer (and by extension, any Rails codebase) will be familiar with AR migrations. No extra dependencies, training, or versioning issues to worry about. I mostly agree with #3, though I definitely still find some funky edge cases with Django form validation. They aren't a terribly gently introduction to the "Right Way" of doing form handling for someone more comfortable with HTML than Python, either.
  - Pewpewarrows 16y ago
    You make some good points. I've always felt that if your template tags are doing too much, your front-end is getting too bloated. That kind of logic should be left to your models/views. I know there's a lot of disagreement in the community over the lack of real Python code in your templates, but it just encourages sloppy spaghetti. Forcing you to not rely on advanced logic in your templates makes you a better developer. I do agree that migrations should be a part of core/contrib, given how common of a use case they are. I don't agree that it makes it less useful. You need plenty of gems to get Rails to satisfy many common use cases. No framework plugs all the holes, you always have to extend. Both django and Rails make getting and using those extensions hilariously easy, so there's really no barrier to entry for any developer.
bad_user 16y ago
I worked with both Rails and Django and I like Django's approach better ... simply because the fields declaration is higher-level. I.e. you don't have a "filepath varchar" field, but a "photo=ImageField(thumbnail_size=[320,200])". I've had a good experience with South for database migrations, used it in every Django project I tried ... the only things bothering me is that the generated files are too verbose (not much of a problem, since you don't need to modify the auto-generated code), plus a migration-based system doesn't really blend if you've got multiple apps in the same project (refactoring becomes painful). Other than that, Rails is pretty good because of its declarative APIs. Django has too much boilerplate for my taste ... but I like that for complex projects where I need to tweak things.

andrewingram 16y ago

I can't disagree on ORM and templates (I disagree with the lack of proper method invocation in Django templates, it annoys me having to create tags for trivial things). I kind of disagree on the form validation though. Having used a number of frameworks prior to Django (including Rails for about a year), I love the way forms are handled in it - it just seems to make sense to me.

jnoller 16y ago

I think you and I both know - once you've run with something long enough, you hit a wall. Everything - every language, framework or tool hits a wall. You hit yours with Django because you fundamentally disagreed with some of the design decisions. I personally have not hit my wall (with django) but I see plenty of room for improvement. It's awesome you built something so quickly with Rails - I have a similar experience with Django (a tiny amount of time to build a really deep application). I personally found it amusing/bothersome that you were lauding a fairly magical and opinionated framework when you had old posts deriding Django (and it's ORM) in the past.

snprbob86 16y ago
I like opinionated software. Especially when it matches my opinions. And if it doesn't match my opinions, it is easy to dismiss it. It isn't the magic about Django (and it's ORM) that I didn't like. It was the design decisions that didn't match how I think (and approach of declaring the DB schema in code).
- jnoller 16y ago
  We (mostly) agree then. The non-opinionated stuff makes me 1000x more angry then something silly like lack of class-based views, or the inclusion of GIS in contrib (for Django). I was probably overly sarcastic in my original comment, so for that I'm sorry.
berntb 16y ago
>>once you've run with something long enough, you hit a wall. Hmm... resonates. Sounds like an insight. That would implicate flexibility in languages, editors and frameworks -- so you can tunnel through the wall. More Ruby/Perl than Python and more Emacs/Vim than most IDEs. Etc.
- jnoller 16y ago
  Nice try; but having more flexibility can be just as damning as not enough. Me, and plenty of others, have found that we know where, say, Python's wall is and accept it or we go around it. The wall I'm talking about is the mental barrier where you either no longer want the tradeoffs involved, or find you disagree with a fundamental axiom of the thing under inspection. Drilling through it is impossible without discarding it entirely. Having flexibility to drill through that wall just puts a bigger, harder wall someplace else. And other people find Emacs/VIM ideas perfectly workable IDEs, and find the flexibility of Emacs and VIM horribly confusing. You have to know, and accept the wall and limitations - it's a series of tradeoffs, and you just need to know what you're getting in the trade. In the case of frameworks, it's just a bigger set of tradeoffs as they tend to be a lot more opinionated, which means you're trading more for comfort.
  - berntb 16y ago
    Hmm... I don't yield the point yet. :-) Emacs is use optimized, not learning optimized. It takes lots of time -- if you don't use it for hours a day, it is probably not worth it. Org mode in Emacs is a good example. It took embarrassing long to learn for me -- while the GUI variants (e.g. gjots2) are trivial. But now, I can take notes and doodle with Org mode that I could only do on paper before. It is built into my fingers in a way which IDEs/GUIs failed for lots of years. I'd argue that Emacs is without a wall for programmers. (-: As long as you don't want to do word processing with WYSIWYG. :-) The problems will be new areas, like how will text understanding libraries (theoretical concept, not in that area) integrate with Emacs compared to others. You could probably do the same arguments for Perl and Lisp. But I don't know any framework I'd say the same about. Edit: Thinking back on my life, I'll yield the point re frameworks. Not libraries, for a not too large problem (a pack of collected libraries would have a wall in a bad Big-O for complexity/time). Edit 2: You could put my argument to be that the last decades of history shows Emacs to be, for all practical [programmer] purposes, infinitely flexible -- as long as new functionality can be integrated to the normal Emacs usage. Which is a big caveat, yes. Org isn't the first generation of that kind of note taking modes in Emacs, the evolution was afaik in much how Org was used.

ubercore 16y ago

Can you elaborate on the non-declarative schema point? With something like Django's South handling migrations, what problems does the declarative schema introduce that Rails side-steps?

snprbob86 16y ago
I wrote about this here: http://blog.brandonbloom.name/2009/10/orms-and-declarative-schemas.html http://blog.brandonbloom.name/2009/10/orms-and-declarative-s... It is a subtle, but fundamental distinction: Django expects me to declare my schema in Python. Rails (and optionally SqlAlchemy, which I like) operate via schema reflection. The declarative approach is redundant, error prone, and resistent to migrations, even with South. The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment.
- Pewpewarrows 16y ago
  The declarative approach is only redundant if you're inheriting a project, and even then it's only redundant that first time you mirror the existing db schema in Python. How can you call a declarative method redundant and not schema reflection? They're reverse processes of the exact same thing. The only "errors" I can think of that can arise from declarative over reflection is when someone decides to manually fuck with your database while ignoring your framework's tools. And even then, South basically handles every use case. How exactly do you think South is resistant to migrations? Updating your models.py and running two manage.py commands seems pretty damn straightforward to me. "The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment." So, you're saying that because one way looks like what you were doing before a framework, it's somehow "better?" What kind of backwards logic is that? It's basically the definition of abstraction.
- phaylon 16y ago
  Sounds like what's missing is the ability to create the schema from the declared code. Which I actually like better. Because it means I can re-use parts of my model like any other code.

deleted 16y ago

[deleted]

neeleshs 16y ago

I am building an app with Django. Can you elaborate on #1 and #3? While I agree with you on #2 to a certain extent, the extend/include and templatetags of django templates is reasonably powerful and at the same time does not pollute the templates with lot of code. Form validation - Custom form fields and custom widgets/multiwidgets actually have made my life simpler by allowing me to build reusable form widgets+validation logic. One piece I sorely missed in Django was model level validations. With the latest version, this is included as well. Note: This comment is definitely not to ridicule your conclusion, but more to learn from your experience. [Edit: Formatting]

Pewpewarrows 16y ago

1) I haven't run into a single instance where custom django template tags can't do exactly what I want with the same ease as Rails' Helpers. 2) http://south.aeracode.org/ http://south.aeracode.org/ 3) I don't understand how anyone can prefer another framework's form tools after using django. Like others have said, considering your past posts, it's just a matter of time before you starting hating Rails. To each their own, but I don't see any of your points as being a valid reason to like Rails over django.

rcoder 16y ago
I don't want to get into a framework war or anything -- in fact, I'm a Django developer currently after several years working with Rails, and relatively happy with the switch. That being said, both #1 and #2 above are plain wrong. Django template tags are a PITA to write, have weird inconsistencies (largely due to the first issue causing them to be implemented in a very hack-ish way) and don't have access to any request or application state that isn't explicitly added to the template context. Rails template helpers are powerful, easy to write, and ubiquitous. Those properties also make them easy to abuse for functionality that should absolutely be in a model or view function. South, on the other hand, is powerful, complex, and not part of the Django core. That simple fact immediately makes is less useful. Any Rails developer (and by extension, any Rails codebase) will be familiar with AR migrations. No extra dependencies, training, or versioning issues to worry about. I mostly agree with #3, though I definitely still find some funky edge cases with Django form validation. They aren't a terribly gently introduction to the "Right Way" of doing form handling for someone more comfortable with HTML than Python, either.
- Pewpewarrows 16y ago
  You make some good points. I've always felt that if your template tags are doing too much, your front-end is getting too bloated. That kind of logic should be left to your models/views. I know there's a lot of disagreement in the community over the lack of real Python code in your templates, but it just encourages sloppy spaghetti. Forcing you to not rely on advanced logic in your templates makes you a better developer. I do agree that migrations should be a part of core/contrib, given how common of a use case they are. I don't agree that it makes it less useful. You need plenty of gems to get Rails to satisfy many common use cases. No framework plugs all the holes, you always have to extend. Both django and Rails make getting and using those extensions hilariously easy, so there's really no barrier to entry for any developer.

bad_user 16y ago

I worked with both Rails and Django and I like Django's approach better ... simply because the fields declaration is higher-level. I.e. you don't have a "filepath varchar" field, but a "photo=ImageField(thumbnail_size=[320,200])". I've had a good experience with South for database migrations, used it in every Django project I tried ... the only things bothering me is that the generated files are too verbose (not much of a problem, since you don't need to modify the auto-generated code), plus a migration-based system doesn't really blend if you've got multiple apps in the same project (refactoring becomes painful). Other than that, Rails is pretty good because of its declarative APIs. Django has too much boilerplate for my taste ... but I like that for complex projects where I need to tweak things.