Django is massive and ton of baggage to be carrying if you are only doing REST APIs.

This sounds like standard case going with what developers know instead of evaluating tool for job.

I think the baggage goes both ways - Django has the advantage of being a "complete & proven recipe" vs. Node where you try to lego-together an app out of dependencies that have deprecation warnings even in their latest versions.

▲

everforward 3 days ago | parent | next [-]

> Django has the advantage of being a "complete & proven recipe"

I work on a large Django codebase at work, and this is true right up until you stray from the "Django happy path". As soon as you hit something Django doesn't support, you're back to lego-ing a solution together except you now have to do it in a framework with a lot of magic and assumptions to work around.

It's the normal problem with large and all-encompassing frameworks. They abstract around a large surface area, usually in a complex way, to allow things like a uniform API to caches even though the caches themselves support different features. That's great until it doesn't do something you need, and then you end up unwinding that complicated abstraction and it's worse than if you'd just used the native client for the cache.

	▲	macNchz 3 days ago \| parent \| next [-]
		I’ve always found the Django codebase to be easy to read and override, making it pretty straightforward to color outside the lines.
	▲	pdhborges 3 days ago \| parent \| prev \| next [-]
		I don't agree with this cache take. Adding operations to the cache is easy. Taking the django-redis project as an example there are only two levels until you reach redis-py: The cache abstraction and the client abstraction.
	▲	DangitBobby 3 days ago \| parent \| prev [-]
		I'm having a hard time imagining a case where you'd be worse off with Django (compared to whatever alternative you may have chosen) in the case where the happy path for the thing you're trying to do doesn't exist natively in Django. Either way you're still farming out that capability to custom code or a 3rd party library. I guess if you write a lot of custom code into specific hooks that Django offers or use inheritance heavily it can start to hurt. But at the end of the day, it's just python code and you don't have to use abstractions that hurt you.

▲

chrisweekly 3 days ago | parent | prev [-]

"dependencies that have deprecation warnings even in their latest versions"

Could you be more specific? Don't get me wrong, I'm well aware that npm dependency graph mgmt is a PITA, but curious where you an into a wall w/ Node.

▲

dec0dedab0de 3 days ago | parent | prev | next [-]

you can just run part of django. So the negatives of it being “massive” is really just the size of the library that will just be sitting there on disk. which is really not a big deal in most situations.

As far as going with what you know vs choosing the best tool for the job, that can be a bit of a balancing act. I generally believe that you should go with what the team knows if it is good enough, but you need to be willing to change your mind when it is no longer good enough.

▲

e145bc455f1 3 days ago | parent | prev | next [-]

How would you compare this with spring?

▲

stackskipton 3 days ago | parent [-]

Spring is massive as well but since Java is compiled, it’s baggage is less noticeable.

▲

mrits 3 days ago | parent [-]

Curious what you think a .pyc is

	▲	stackskipton 3 hours ago \| parent [-]
		Python compiles and then interpret currently. Before you throw things back, learn how a language works.

▲

icedchai 3 days ago | parent | prev [-]

I worked at a mid-size startup that was still running on Python 2.7 and Django for their REST APIs, as late as 2022. It was pretty meh and felt like traveling back in time 10 years.

▲

JimDabell 3 days ago | parent | next [-]

Python 2.7 was released in 2010. Of course using it in 2022 felt like travelling back in time ten years‽

▲

mywittyname 3 days ago | parent [-]

2.7 was end-of-life in 2020! And Python 3 outdates 2.7 by a few years.

A company using 2.7 in 2022 is an indicator that the company as a whole doesn't really prioritize IT, or at least the project the OP worked on. By 2017 or so, it should have been clear that whatever dependencies they were waiting on originally were not going to receive updates to support python3 and alternative arrangements should be made.

▲

icedchai 3 days ago | parent [-]

You captured the fundamental issues. There were mountains of technical debt. I recall encountering a dependency that had not been updated in over 10 years.

	▲	Izkata 3 days ago \| parent [-]
		We have VB deployments that haven't been changed at all in about that long. Finally got approval to do a rewrite last year, which is python 3.6 due to other dependencies we can't upgrade yet. It got this bad because the whole thing "just worked" in the background without issues. "Don't fix what isn't broken" was the business viewpoint.

▲

gjvc 3 days ago | parent | prev [-]

python2 will have that effect tbh