Hacker News Reader

Comment by snprbob86 | Hacker News Reader

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.

View on HN

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.

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).

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.

>>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.

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.

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.

Emacs might be insanely flexible, sure, but at what cost? Bloat? Infinite complexity? Heck, I get frustrated with my VIM configuration sometimes because I forget the less used keybindings when I really need them, and need to go spelunking.

So sure; if you're willing to trade the up-front investment of time (not insubstantial) Emacs will go far - and the wall is way off on the horizon and someone scribbled "complexity" on it.

Up-front investment can't be underestimated; there's a reason why things like Textmate (which starts simple, and grows out well) are so popular. Low initial investment, and plenty of ramp, and it works out well until it simply doesn't.

That low initial barrier is easier to climb, and while emacs (or even VIM) might have a wall that, when compared to Textmate's, is infinitely far away, textmate will still have fantastic adoption. The wall textmate has is further off then most people are willing to worry about.

For most people, a framework, like, say, Django or even Rails offers a wall far enough out that most people don't need to worry about it, but when they hit that wall, they're going to hit it hard, and kinda be mad.

>>That low initial barrier is easier to climb

You're mostly rewriting my points. Let's leave this for half a year and discuss it again. It seems we both need to let it fes.. think about it. :-) Or at least I know I do.

What I'm trying to say, I think, is that there is a tension between flexible/pluggable frameworks and integrated ones, like with e.g. Emacs and simple IDEs. (Yeah, there are IDEs on top of Emacs; those doesn't remove complexity.)

(The main complexity problem with Emacs isn't the code which is neat with the lisp layer (imho, I'm very far from being a real Emacs hacker). The complexity is use complexity -- lots of modes, etc. More broad than deep.)

But unless some totally new idea comes along, people will use Emacs when we both have forgotten the present frameworks...

>>I get frustrated with my VIM configuration sometimes because I forget the less used keybindings

I haven't used vi for quite a few years. There is still no good search/browsing/M-x? Never mind, some really good people use vim, so I assume there is something there.

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.

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.

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/

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.

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.

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.

> I know there's a lot of disagreement in the community over the lack of real Python code in your templates, but it would just encourages sloppy spaghetti.

You'll see a lot of this in the Rails community too; lots of people use haml over erb for exactly this reason.

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?

I wrote about this here: 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.

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.

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.

I thought django had that. ???

Grails does, and it's part of the reason I like it so much.

> I thought django had that. ???

It does.

The parent poster wrote

"Sounds like what's missing is the ability to create the schema from the declared code."

Which is what I was questioning. I thought (rightly) Django had that functionality.

I don't use Django and so I simply didn't know. From the description it just sounded like such a solution would fit the problem.

Even if Django wouldn't have such a system yet, nothing would be keeping someone from writing it.

Having used both (though Django much more heavily) I don't see any practical differences between migrations in a non-declarative system (Rails) and a declarative one (Django). Migrations are always a bit of a pain, but database changes (at least to any field managed by a framework) will almost always require code changes -- so what are you gaining by leaving the field declaration out of the model?

I'd say that the declarative syntax is actually a bonus. It makes the code much more discoverable, and I haven't seen a real downside.

I understand the need to have the schema where it's being used but if you ever need to make modifications like custom fields (say an email field) then your schema isn't just stored in the DB any more. With Django your custom field declarations live in the same place as more mundane fields. If you port that models file to another machine and run syncdb you are going to be left with the same schema with the same restrictions.

Reply on news.ycombinator.com