4 ms·

People basically don't know what they want. That applies to developers as well. Sometimes we want things to be built-in. Sometimes we want to bring our own modu

by mdew 5y ago

People basically don't know what they want. That applies to developers as well. Sometimes we want things to be built-in. Sometimes we want to bring our own modules. Can we just agree to do and choose whatever works best for us at any point of our developer's life?

ajford 5y ago
Totally agreed. That's why I pointed out the difference. I've used many frameworks, and each brings it's own flavor and benefits to the table. I wasn't disparaging Django, just commenting on my issue with it. I still used it for 2yrs, but the batteries included nature of it is something that most of my projects don't call for. When I was primarily working on web apps, I made heavy use of Flask for back-ends and APIs, with various flavors of JS for front-ends. In one role however, we had an entire CMS/CRM/Subscription engine written in Django, and it was rather solid. Since everything was in Django, it all worked together well. When I started working with this app, it was in poor shape (and a couple versions out of date) but when we brought it up to date it was real nice. We could make good use of Django signals for all sorts of things with little extra effort, and the variety of plugins available was just fantastic. I think the biggest skill a dev can develop is learning to recognize the pros and cons of a framework or language or tool without developing too much of a prejudice for any given one. Recognize that they are all just tools, and some are better suited for some tasks then others. Doesn't mean you can't press one into service if it's a poor fit, just means you'll need to do extra work. Python might be a poorer fit for a highly parallel real-time task compared to something like Rust or Go. Doesn't mean you couldn't use it, but using a better option would make things easier. If you want something with an ORM, template engine, signaling system, and caching layer all built in with minimal fussing about with other libraries, Django is perfect. If you JUST want a rest api, perhaps FastAPI or Flask might be a better choice.

by mdew 5y ago

ajford 5y ago

Totally agreed. That's why I pointed out the difference. I've used many frameworks, and each brings it's own flavor and benefits to the table. I wasn't disparaging Django, just commenting on my issue with it. I still used it for 2yrs, but the batteries included nature of it is something that most of my projects don't call for. When I was primarily working on web apps, I made heavy use of Flask for back-ends and APIs, with various flavors of JS for front-ends. In one role however, we had an entire CMS/CRM/Subscription engine written in Django, and it was rather solid. Since everything was in Django, it all worked together well. When I started working with this app, it was in poor shape (and a couple versions out of date) but when we brought it up to date it was real nice. We could make good use of Django signals for all sorts of things with little extra effort, and the variety of plugins available was just fantastic. I think the biggest skill a dev can develop is learning to recognize the pros and cons of a framework or language or tool without developing too much of a prejudice for any given one. Recognize that they are all just tools, and some are better suited for some tasks then others. Doesn't mean you can't press one into service if it's a poor fit, just means you'll need to do extra work. Python might be a poorer fit for a highly parallel real-time task compared to something like Rust or Go. Doesn't mean you couldn't use it, but using a better option would make things easier. If you want something with an ORM, template engine, signaling system, and caching layer all built in with minimal fussing about with other libraries, Django is perfect. If you JUST want a rest api, perhaps FastAPI or Flask might be a better choice.