5 ms·

> For building prototypes, Django is the fastest framework I've ever used. I worked with Django full time for about 6 years. It scales up and out pretty well,

> For building prototypes, Django is the fastest framework I've ever used. I worked with Django full time for about 6 years. It scales up and out pretty well, too. There was a peer comment about Rails. I'm a big fan of Rails, and Ruby is one of my favorite languages. But one thing I've noticed is the lack of magic inside the Django codebase vs. Rails' codebase. Spelunking in the codebases feels night and day different: I found Django very intuitive and Rails... less so. I think that was a combination of my lack of skill with Rails' internals, and the different in languages and communities. Python (and Django) try to follow the Zen of Python. Rails felt like every other method was monkey-patched and reduced to a single line or two. It was odd: I think the expressiveness of Ruby was actually a negative at large scale (sort of like Lisp vs. Go) For 99% of use cases, you never need to get to this level of the frameworks, but it was an interesting experience.

airstrike 7y ago
I echo this sentiment. I've learned a ton of Python from reading the Django source code. There's definitely something to be said about the DSF and the many contributors over the years who've worked tirelessly to push the envelope with the framework (and the ORM, in particular) while also keeping the codebase sane. It's not all perfect, but it's about as good as it gets for FOSS with so many people chiming in over more than a decade
debuggerpk 7y ago
That is exactly my experience. RoR was too much magic for me.
- hombre_fatal 6y ago
  To put a finer point on "magic", Rails requires a lot more knowledge about what's going on behind the scenes. One major reason is that a central tenet of Rails since its inception seems to be to eliminate any and all boilerplate or glue code. But boilerplate and glue code also serve a purpose of showing you how things are hooked up. And they tend to have very tiny one-time costs whereas abstracting them away may incur rather heavy costs of knowing the abstraction exists, how it works, where in the Rails code it's actually implemented, and always remembering all of this whenever you touch Rails again in the future even after a long hiatus. Without glue code, you have to just know how everything works: How does the router know to route GET /users to UsersController and its index() method? You never see an invocation. And there seems to be middleware code that runs before my index() method is called. Where is it defined and what makes it run before my code? How do I get a list of all middleware that might run before my code? Oh, libraries can install their own middleware code? etc, etc. You end up doing a pretty deep dive in the abstractions of Rails and your gems to understand these questions and all questions like them. You basically become a Rails expert when you truly hold all of this in your head. Meanwhile, you don't need to deep dive on any code to understand what `router.get('/users', UsersController.index)` might be doing. To Rails' credit, I remember how much it was compared to things like Spring in its early days and I imagine the sort of XML config nightmare you could get with old Java frameworks is what DHH must have had in mind when he sought to improve the state of web development. I think Rails represents an interesting experiment in the timeline of software development where we played with zero boilerplate. And I think since then the ecosystem's views on boilerplate and glue code has swung back to a less squeamish middle ground. I think this is really what people generally mean by "too much magic". DHH has a twitter thread (https://twitter.com/dhh/status/1226296264469336064 https://twitter.com/dhh/status/1226296264469336064) where he attacks the idea of "too much magic", but I think it's obvious to anyone who has used Rails that there is definitely a spectrum of magic and Rails certainly ranks towards one pole more the other. And to defend DHH's twitter thread, he's always been kind of a harsh speaker like that. And you also have to keep in mind how long he's had to deal with the "ugh too much magic" dismissal. I would expect him to generally agree with this post.
jvdongen 6y ago
There was once actually an active effort to remove magic from Django: https://code.djangoproject.com/wiki/RemovingTheMagic https://code.djangoproject.com/wiki/RemovingTheMagic
- wiremine 6y ago
  Good point. Most of my experience with Django was on and after the 0.96 release
virvar 6y ago
Isn’t the Django vs Ruby mainly about just picking one and not looking back? They seem to do the same thing extremely well and both have active communities.
- wiremine 6y ago
  Yeah, I'd agree with that for the most part. I think Django's strength is in rapidly building out custom CMS systems. It isn't bad a web apps, but I still think Rails would be my go-to for those.

airstrike 7y ago

I echo this sentiment. I've learned a ton of Python from reading the Django source code. There's definitely something to be said about the DSF and the many contributors over the years who've worked tirelessly to push the envelope with the framework (and the ORM, in particular) while also keeping the codebase sane. It's not all perfect, but it's about as good as it gets for FOSS with so many people chiming in over more than a decade

debuggerpk 7y ago

That is exactly my experience. RoR was too much magic for me.

hombre_fatal 6y ago
To put a finer point on "magic", Rails requires a lot more knowledge about what's going on behind the scenes. One major reason is that a central tenet of Rails since its inception seems to be to eliminate any and all boilerplate or glue code. But boilerplate and glue code also serve a purpose of showing you how things are hooked up. And they tend to have very tiny one-time costs whereas abstracting them away may incur rather heavy costs of knowing the abstraction exists, how it works, where in the Rails code it's actually implemented, and always remembering all of this whenever you touch Rails again in the future even after a long hiatus. Without glue code, you have to just know how everything works: How does the router know to route GET /users to UsersController and its index() method? You never see an invocation. And there seems to be middleware code that runs before my index() method is called. Where is it defined and what makes it run before my code? How do I get a list of all middleware that might run before my code? Oh, libraries can install their own middleware code? etc, etc. You end up doing a pretty deep dive in the abstractions of Rails and your gems to understand these questions and all questions like them. You basically become a Rails expert when you truly hold all of this in your head. Meanwhile, you don't need to deep dive on any code to understand what `router.get('/users', UsersController.index)` might be doing. To Rails' credit, I remember how much it was compared to things like Spring in its early days and I imagine the sort of XML config nightmare you could get with old Java frameworks is what DHH must have had in mind when he sought to improve the state of web development. I think Rails represents an interesting experiment in the timeline of software development where we played with zero boilerplate. And I think since then the ecosystem's views on boilerplate and glue code has swung back to a less squeamish middle ground. I think this is really what people generally mean by "too much magic". DHH has a twitter thread (https://twitter.com/dhh/status/1226296264469336064 https://twitter.com/dhh/status/1226296264469336064) where he attacks the idea of "too much magic", but I think it's obvious to anyone who has used Rails that there is definitely a spectrum of magic and Rails certainly ranks towards one pole more the other. And to defend DHH's twitter thread, he's always been kind of a harsh speaker like that. And you also have to keep in mind how long he's had to deal with the "ugh too much magic" dismissal. I would expect him to generally agree with this post.

jvdongen 6y ago

There was once actually an active effort to remove magic from Django: https://code.djangoproject.com/wiki/RemovingTheMagic https://code.djangoproject.com/wiki/RemovingTheMagic

wiremine 6y ago
Good point. Most of my experience with Django was on and after the 0.96 release

virvar 6y ago

Isn’t the Django vs Ruby mainly about just picking one and not looking back? They seem to do the same thing extremely well and both have active communities.

wiremine 6y ago
Yeah, I'd agree with that for the most part. I think Django's strength is in rapidly building out custom CMS systems. It isn't bad a web apps, but I still think Rails would be my go-to for those.