5 ms·
Whoah! I think the surprising thing about this comment is that you actually developed using Django for all those years, and you still prefer RoR. The vast maj
by projectramo 8y ago
Whoah!
I think the surprising thing about this comment is that you actually developed using Django for all those years, and you still prefer RoR.
The vast majority of people on the web that comment invariably say they are pretty much the same and it depends on whether you know ruby or python better.
So people who already use python for finance or data science pick django.
I saw a study (old now, from the early days) that claimed they were about the same but that the admin page on django cut dev time by some %.
This is the first I've heard a long time django user say that rails was faster to develop and not about the same. Can you elaborate on why?
- mcintyre1994 8y agoI've used Django a little bit, I can definitely believe the admin page cuts dev time if Rails doesn't have an equivalent. But I know Python well, and Ruby not-at-all, and I'm not sure I'd choose Django over Rails, because Ruby gems seem better for RoR than Python has in terms of Django-compatible packages. Maybe I'm just not looking in the right place but there doesn't seem to be nearly as much of an ecosystem there.
- swlkr 8y agoRails has this: https://github.com/activeadmin/activeadmin https://github.com/activeadmin/activeadmin
- Daishiman 8y agoYou should look in https://djangopackages.org/ https://djangopackages.org/
- mcintyre1994 8y agoThat's really helpful, thanks! :)
- whalesalad 8y agoPlease note these are my opinions. The efficiency you gain using Django on the admin side is lost with every other part of your app. 1. Active Record is superior to the Django ORM (which is still good). Being able to set scopes and do a lot of conveniences right on the model without needing to extend/override a manager is great. Being able to connect to an existing database for free is also great. 2. Controllers are great. The way they can be nested and composed is also powerful. Being able to mount a resource at any level in the hierarchy either alongside or beneath (or both!) is hugely powerful. I can state concerns at each level and 'forget about it' deeper. Eg, if my controller A needs to ensure a given user has access to that resource and all children, I can do that at level A and trust its handled so in the controller for level B or C (deeper layers) I am not worried about it. 2b. The syntactic sugar to add authentication/authorization/guards in controllers is incredible. `before_request :ensure_access` 3. Active Support is phenomenal. 4. You can build very elegant, flexible and powerful RESTful and RESTish API's REALLY quickly. And not just naive stuff that you can do with something like 10 lines of Flask ... but really foundational stuff that allows you to hit the ground running and then build on it layering in more security and functionality. 5. Polymorphic/STI power with Active Record. AR gives you so much more freedom to do polymorphism and bend your database to model your data as you see fit. With Django you are oftentimes stuck doing things their way. For instance if I want multiple classes to share a single database and get instantiated based on a 'type' field ... that is trivial in Rails and difficult with Django. Even moreso if you want to do relationships with those polymorphic objects. 6. Finally... the most important thing... it's sometimes difficult to model your domain/business inside of Django and by extension the Django admin tool. Let's say you have a friendship between two people. How do you create that in Django? You might have a many-to-many which means there is gonna be a join table somewhere. Do you ask your customer support folks to go into the FriendRelationship UI and 'create an object' connecting person_a to person_b and ensuring to choose the correct relationship type from the enum? Worse, you have too many users so you cant use a select field or search box without plugins and are left with two input boxes that expect a valid person ID to the FK. So now customer support needs a workflow for managing this data. I'd rather build my own "manage friends" page that will take me all of an hour and provide an experience modeled after the problem/task not the database. Or let's say you have a more intricate transactional type of process where an object needs to be created with 3 or 4 child objects. The parent needs to be created first, then the children need to be created and linked to that parent. Sure, you can do this in the Django admin flow but at that point you might as well be writing `INSERT INTO...` queries. Again, I'd rather build my own tool. I will save SO much time building the API and the business logic for my program that I'll be afforded the time to build an administrative tool that is focused on tasks specific to my team/business not just a graphical representation of my SQL tables. I could go on and on and on. I was a Django zealot for a long time and refused to drink the kool-aid. I bought into the hype from the community and trusted folks when they said "rails is magic, I don't like it" but that is a horribly naive approach and frankly I only hear it from less experienced engineers. When you get acclimated to Rails you realize there is no magic, it's all just straightforward code written by people who truly want to get things done. Perhaps I just align more with the Ruby way of thinking. Django folks tend to pride themselves on boilerplate and more complex interactions... like it's some kind of badge of honor.