[dinkleberg]

Whenever I read about Rails it makes me want to try it again and "understand" it this time... But it always ends up feeling wrong, and I go back to old reliable Django.

I can't put my finger on it, but Django just feels intuitive to me and Rails just feels strange. Maybe it is the convention over configuration mindset which results in lots of magic, but I just can't get comfortable using Rails.

I love the idea of Rails and it's community, but I don't think it will ever be the tool for me.

And as a Django + Python lover, I feel the need to refute the idea (not just in this article) that it is mainly for academic/scientific purposes. Python is a great general purpose language which can do just about anything. It's not the best tool for every job, but for the generalist, it is wonderful. And Django is incredibly solid and can build an MVP in no time. And maybe I'm just a bad developer, but I don't see how the extra configuration necessary when using Django vs Rails is going to add up to much time at all when building your MVP. Is a couple of extra hours really going to make a difference?

[hervature]

Mostly interested in commenting on your last paragraph. But I think your first point of Django being more intuitive is probably due to your (I'm assuming here) background of growing with Django through time. As someone who has developed in both, I find that Django is basically RoR version (n-1). People claim that Django is too complex for them over Flask. I say it just takes time to learn all the features.

Anyway, as for the academic/scientific thing. I couldn't agree more. I feel like they are just perpetuating something silly. I can guarantee you that no one in academia is using Django for research. Probably some weird transitive logic like science => numpy/pandas => python => django.

But I think this stems from the target audience of the article:

""" The only person who won’t find much use for this guide would be a high-level master Ruby on Rails developer. If you’re not on that level yet, then you’ll definitely be able to learn something! """

That is, if it's useful for everyone, it's useful for no one. The whole comparison table is unsubstantial. As interpreted languages, they are going to be roughly the same performance especially on a single thread. If anything, Ruby might be better on multi threaded due to the GIL but then this is contradicted in the table where it claims that Django is more scalable which I think is more of a comment as to how project architecture is laid out in Django with everything supposed to be a separate app.

[tabtab]

Re: Maybe it is the convention over configuration mindset which results in lots of magic

Yes, the "magic" is a double-edged sword. I find a similar problem with Dot-Net MVC: when the "helpers" work as intended, they are great. But when they don't, troubleshooting takes way too long. (MS-MVC is more or less a clone of R-on-R.)

Its auto-matching of URL's to controllers & methods etc. (routing) is an example of this. A bunch of IF or CASE statements to do the same thing would probably be much quicker to debug, even if it's more typing up front. (Or even put the mappings into data tables for bigger apps.) One can scaffold (auto-generate) IF/CASE statements for such if needed to reduce the original build grunt-work.

All these "magic helpers" are over-complicated and opaque. Yes, I know that once one gets used them they know how to cajole them, but the learning curve is unacceptable for things that should be relatively simple. The helpers are more trouble than they are worth because they try to fit too many application types and styles, and rely on reflection, which makes following the actual helper code a pasta factory visit.

Must it be that way? I want clear and logical processing, not a bunch of organic dark-grey boxes. Maybe I'm old fashioned and relying on a bunch of dark-grey boxes glued together is the proper "new way"? #Idontgeddit

Maybe it's better for big projects or large pool of devs where you hire plug-and-play specialists who know a specific technical area well such as routing or views. But in shops with smaller staff or that divide tasks by project or entity instead of tech specialties, this doesn't make sense. But orgs feel compelled to do it that way because "everybody else is": MVC-Lemmings.

[canadapups]

Yeah, the magic is a big problem for me. When I was a absolute beginner, even knowing which magic (ruby gems) to pick was a problem. In contrast, Django has all of the functionality within the library, all working together. After I launched my website and became more experienced, I started replacing the default parts with custom parts. Django's explicitness and lack of magic made that easy.

[sk221]

When I initially started learning Rails, I was feeling similar. I was concerned about code feeling like "magic" and things happening w/o my understanding.

However, I got more comfortable with it and soon, for the most part, I LOVED the way everything was structured. Other frameworks just felt off.

I credit a lot of this to just understanding the internals of how Ruby works. I highly recommend the Well Grounded Rubyist. If you go through it, you'll be comfortable digging through your code, gems, etc. Things won't feel like magic and you'll be able to pinpoint how and why things are happening in your application.

Rails is one of the most productive web frameworks out there and once you know how things work, you're off to the races.

That Elixir/Phoenix combo though...