4 ms·

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?

by winrid 4y ago

procinct 4y ago
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.
- rochak 4y ago
  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.
- fernandotakai 4y ago
  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!).
  - KyeRussell 4y ago
    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.
    - rajamaka 4y ago
      What JS based ORMs did you use that you weren't a fan of?
      - AeroNotix 4y ago
        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.
      - ackfoobar 4y ago
        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.
      - winrid 4y ago
        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.
    - kdazzle 4y ago
      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.
- black3r 4y ago
  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...
- simonw 4y ago
  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.
Aeolun 4y ago
Ah, NodeJs developers are fine with a single dependency too. As long as that dependency is NPM.
wg0 4y ago
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.
- winrid 4y ago
  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.
- Kwpolska 4y ago
  > 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 https://github.com/django/django/blob/main/setup.cfg#L39-L42 [1] https://github.com/django/asgiref/blob/main/setup.cfg#L34-L35 https://github.com/django/asgiref/blob/main/setup.cfg#L34-L3...
danielheath 4y ago
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.
- nicoburns 4y ago
  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.
  - danielheath 4y ago
    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.
    - iudqnolq 4y ago
      Funnily it's now outdated. The brand new react docs don't even mention it: https://react.dev/learn/start-a-new-react-project 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-1409720741 https://github.com/reactjs/react.dev/pull/5487#issuecomment-...

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?

by winrid 4y ago

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?

procinct 4y ago

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.

rochak 4y ago
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.
fernandotakai 4y ago
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!).
- KyeRussell 4y ago
  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.
  - rajamaka 4y ago
    What JS based ORMs did you use that you weren't a fan of?
    - AeroNotix 4y ago
      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.
    - ackfoobar 4y ago
      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.
    - winrid 4y ago
      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.
  - kdazzle 4y ago
    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.
black3r 4y ago
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...
simonw 4y ago
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.

Aeolun 4y ago

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

wg0 4y ago

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.

winrid 4y ago
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.
Kwpolska 4y ago
> 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 https://github.com/django/django/blob/main/setup.cfg#L39-L42 [1] https://github.com/django/asgiref/blob/main/setup.cfg#L34-L35 https://github.com/django/asgiref/blob/main/setup.cfg#L34-L3...

danielheath 4y ago

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.

nicoburns 4y ago
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.
- danielheath 4y ago
  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.
  - iudqnolq 4y ago
    Funnily it's now outdated. The brand new react docs don't even mention it: https://react.dev/learn/start-a-new-react-project 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-1409720741 https://github.com/reactjs/react.dev/pull/5487#issuecomment-...