Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For building CRUD web apps Django and Rails are truly in a league of their own[^1].

Many frameworks try to be good at this but finish development at a level of abstraction below these frameworks, leaving the last level to a plugin ecosystem that requires so much more work to wrangle into a fully working web app (see: Flask and its modern successors in Python).

Other systems come at this from the opposite end, trying to be low-code or less-code, like headless CMSs or static site generators. The problem at that end always seems to be a lack of flexibility and over-reliance on proprietary systems or SaaS products.

Django is just Python. Rails is just Ruby. There's nothing special to them and extending when necessary is often trivial, particularly because they have such mature extension points.

There's a lot of criticism that can be levelled at these ecosystems for not keeping up with whatever the hype of the year is, or failing to "scale" in various ways, but damn do they get you a very long way with very little work.

[^1]: Phoenix may be just about in this category, I don't have personal experience with it though, just going on the fact it seems to be very Rails inspired.



> Django is just Python. Rails is just Ruby. There's nothing special to them and extending when necessary is often trivial, particularly because they have such mature extension points.

Eh, I wouldn't agree with that. Both Django and Rails extend the languages quite a bit with deep class overloading, reflection and fluidic approaches.

Especially Rails, which pushes Ruby's DSL-like abilities to an extreme. If you go from learning RoR to then having to make a standard Ruby script, you quickly realize how much of what you built relied on Rails-specific functionality. Django, more or less, is just Python with a bunch of logic built for you, relative to that.


As someone who's been using Django for the past 12 years in apps big and small, it blows my mind the trends towards microframeworks and minimalist frameworks that are objectively less productive in pretty much every metric.

Sometimes it feel like a minor superpower in just how much more productive it is over pretty much everything, especially in the early stages of development.

Even later on things like working auth and permission systems and API frameworks are huge timesavers.

Proof that we are a fad-driven industry.


And in exchange for a free auth system and a automatically generated basic admin interface you gain:

- inability to use static type checker without writing most of the annotations yourself

- half jinja2 functionality

- ORM that makes it impossible to get your query count down to a manageable level

- 3rd party modules that break the types even more

I am lobbying for moving to FastAPI with Jinja2 and SQLAlchemy. We write our admins in Vue anyway.


I've not seen another ORM with tools as powerful as Django's select_related() and prefetch_related() when it comes to addressing the N+1 query problem, but maybe I haven't been looking hard enough.

Jinja2 is a supported template backend for Django these days: https://docs.djangoproject.com/en/4.2/topics/templates/#djan...


I believe these complaints may be caused by lack of experience with Django:

- There is nothing wrong with the ORM, you may be resorting to using deferred attributes too much. There are ways to eliminate them (select_related, prefetch_related) if you are having performance issues.

- Jinja2 has been a supported templating engine for years.

- I don't understand the question about static type checking. Can you elaborate?


I agree with these.

I think of the all the ORM's, I've ever used. Django was the greatest.

However django is living in the age of past glories. The admin is extremely unacceptable for anything beyond trivial borderline trivial use cases, and the modifications you'd have to make are just awful especially the more interactive something needs to be. The extremely tight integration between models and the modeladmin is a blessing and curse.

The people who like Django,also tend to overload it to do everything. This makes sense at small companies. The only place I really see Django at large companies is as an api using DRF or something.

For internal admins, I've been lobbying to use https://directus.io/ at my company.


> The only place I really see Django at large companies is as an api using DRF or something.

This is not a bad thing. Using Django as an API backend is amazingly fast in terms of development time, especially with modern frameworks such as django-ninja [1].

Just use the built-in ORM to create models, write your endpoints, and use the built-in admin interface to play with the database if you don't have endpoints for everything.

There is also a less known feature of Django called admindocs [2], which automatically generates a human readable, hyperlinked documentation for your models and relations between them.

[1] https://django-ninja.rest-framework.com/

[2] https://docs.djangoproject.com/en/4.2/ref/contrib/admin/admi...


> We write our admins in Vue anyway

And with Django you often don't need to write anything.

You're right to some extent with all of your points (jinja2 is available, not default, ORM is equivalent to SQLA most but not all of the time), but they're one side of the trade-off. The other is that you're writing admin views that you likely wouldn't need to with Django.

It's not perfect for everything, but it is much faster to write with than anything else for reasons like this.


Django is Python, but very heavily leans on Python's metaprogramming, which can make things complicated to understand.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: