Hacker News Reader

Comment by winrid | Hacker News Reader

I imagine it wouldn't be too hard, since Django only has one dependency - Django itself (NodeJS developers weep).

Is rails the same way dependency wise?

Rails has dependencies, but not like node apps; last time I counted create-react-app vs a new rails app, there was nearly 10x as many distinct maintainers with access to push new releases to the default dependency tree.

I consider that a better measure of dependency risk than absolute count, since different ecosystems have different ideas about how large a library should be.

Create-react-app isn't really a fair comparison. Create-react-app has ridiculous dependency bloat compared to the norm in the JS ecosystem because it includes every possible option rather than just picking one option in each category. Most serious project using React aren't using create-react-app.

I’m not really familiar enough to contradict you, beyond saying that - as an outsider - it has by far the most visibility in its space.

Funnily it's now outdated.

The brand new react docs don't even mention it: https://react.dev/learn/start-a-new-react-project

> We are currently leaning towards Option 5 ("Turn Create React App into a launcher"). The original goal of Create React App was to provide the best way to start a new React web app for the majority of React users. We like that repurposing it as a launcher explicitly communicates a shift in what we think is best for most new web apps, while at the same time leaving an escape hatch for the older workflows. Unlike Option 3, it avoids the perception that "creating a React app" is somehow deprecated. It acknowledges the reality that a bit of choice is needed, but there are now really great options to choose from.

https://github.com/reactjs/react.dev/pull/5487#issuecomment-...

That's not correct. Django isn't independent, depends on lot many packages but that's not the issue. Issue is the frameworks own Interface:

Existing Interface getting removed OR behavior or defaults changing for an already existing Interface.

That's usually the upgrades are about.

Yes the framework's interface can change. But this is usually a piece of cake compared to hundreds of disjoint libraries and leaky abstractions that would be in use in the Node world.

> Django isn't independent, depends on lot many packages

It is quite independent. There are between two and four dependencies: asgiref, sqlparse, tzdata on Windows only [0], and typing_extensions on <3.11 [1]. There are some optional dependencies (argon2-cffi, bcrypt, and a database library like psycopg2), but they are small and mostly self-contained.

[0] https://github.com/django/django/blob/main/setup.cfg#L39-L42 [1] https://github.com/django/asgiref/blob/main/setup.cfg#L34-L3...

Wait is this true? Doesn’t it also use SQLAlchemy at least? Which then likely has its own dependencies? I’d be really surprised if Django had no dependencies at all.

I don’t think Django uses SQLAlchemy. It has its own ORM which is damn good, but you can also use SWLAlchemy instead of that if you want.

django 4.2 has two dependencies: asgiref and sqlparse. other than that, none.

django does not use sqlalchemy as its ORM, it has its own system (which i prefer!).

Amen. Until recently, I was exclusively working with Django for 5+ years. I definitely fell into the trap of making the ORM for granted. Had a brief foray into the JS world and despite plenty of slick-looking projects with fancy pants websites, nothing remotely compares.

What JS based ORMs did you use that you weren't a fan of?

All of them are bad in their own ways. They all fall down in key features, or the non-standard SQL features (hooks, after-save, automatic transactions, etc) all have edge-cases and surprising behaviour.

I have tried a lot and the least worst is Zapatos (and it's not really an ORM) because it at least tries to not paper over SQL and instead just creates a type-safe API for using SQL.

Slightly related, I'm not used to using ORMs. Spoiled by jooq from the JVM world, writing SQL with the query builder in TypeORM was a terrible experience.

The thing is - even if someone creates an amazing ORM for Node, I doubt I'd use it. I am tired and done with async everything. No more NodeJS for business logic.

Now, if someone could create a Django-like ORM for Java or Rust, then we're talking. Hibernate and Diesel are nowhere near Django's ORM in terms of productivity and "it just works" factor. Go's GORM looks pretty good but haven't tried it. jooq does not look as easy to use or setup, and the workflow is entirely different.

Same here, I came into a project that had been started months before and found that they were spending weeks reimplementing stuff that comes out of the box in Django. But not as well.

Django doesn't use SQLALchemy, they have their own ORM system. And it's true that Django used to have 0 real dependencies (now it has 2), but even now many of its "optional builtins" do require some additional external packages, and some of them are really useful.

For example you need an external package to use builtin postgresql, mysql or oracledb support. You need tblib to run tests in parallel using the built-in test runner. You need external packages to use argon2 or bcrypt as password hashers in the builtin auth system, and I'm sure there are others, since Django is very much batteries included, but modular.

The modularity also means you can also use any 3rd party database, use pytest to run tests, make your password hashing on your own, ... so I can understand that these are not listed as dependencies on pypi, but I don't really like that I have to list packages I don't directly import in my code as direct dependencies...

Django had zero external dependencies for a long time, which was a factor of its history.

The first release of Django was in 2005. Back then, the Python Package Index didn't exist yet. Installing Python dependencies was really hard - you pretty much had to grab a copy of the code for each one and put it on your "sys.path" somehow.

So Django avoided the issue entirely by bundling everything you needed to build a web application in a single package.

That's why Django has "django.contrib" - in a time before pip dependencies, it was a way to separate out things like GeoDjango which weren't exactly part of the "core" framework but could be distributed along with it.

Ah, NodeJs developers are fine with a single dependency too. As long as that dependency is NPM.

Reply on news.ycombinator.com