6 ms·

1) Documentation is too verbose 2) Onboarding new developers lacks IDE specific tooling for free 3) Admin GUI isn't great 4) Async support is still incomplet

1) Documentation is too verbose 2) Onboarding new developers lacks IDE specific tooling for free 3) Admin GUI isn't great 4) Async support is still incomplete 5) Static types aren't used in Django 6) Django is MVC which isn't useful if you just need a light V 7) People ignore other, newer tech because Django exists What??? 4 and 5 are legit complaints, the rest is literally the nittiest of picks, in my opinion. You don't like a framework because it's so good, people don't experiment with newer frameworks?? And that's in your article about the decline of that framework? This is a weird article, man. I am surprised they haven't figured out async yet, and I guess if you really like static types the lack of them in Django would be annoying, but otherwise this just seems like you set a goal to write about a topic, and forced yourself to come up with an article you thought hasn't been written before. Like, it feels like you wrote the title of the article, and then tried to come up with the rest of it after the fact.

dc-programmer 5y ago
Number 1 isn’t a show stopper in any way but is it pretty annoying. The primary django docs are very textual and place more emphasis on developing intuition and understanding context, than something that can be quickly referenced. Also a lot of the method parameters are either not documented or not explained. I think Django would benefit from a more technical and complete but less dense secondary reference.
- grenoire 5y ago
  I fully agree, it usually ends up being barely useful, and not enough. It does not explain how certain parts of the magic happen, what the best practices are, what the expected types for arguments may be, etc. It's not bad, but usually verbose in the wrong bits, and sparse in the details.
- ianai 5y ago
  “ more technical and complete but less dense secondary reference.” Isn’t that basically just reading the source code? Like I get that’s probably not right to throw everyone toward, but reading source code is a staple task for working with FOSS.
  - Areading314 5y ago
    A lot of devs don't understand this, but can save a lot of time, especially when the code is all python. Especially if you questions are off the beaten track
    - pbalau 5y ago
      Django has one of the best source code base I ever saw, in 20+ years of doing software. If anyone has issues reading the Django source code, they probably should stay away from software development.
      - deleted 5y ago
        [deleted]
      - scrollaway 5y ago
        > If anyone has issues reading the Django source code, they probably should stay away from software development. First of all, juniors exist you know that right? Please don't gatekeep. Second, you're wrong. The Django codebase is overall good quality but if it's "one of the best you ever saw in 20 years" you haven't dug deep. Django has a lot of horrible no good bad awful parts to it. To their credit they tend to improve with age, not get worse, but it's certainly not worthy of such praise imo.
        pbalau 5y ago
        > Second, you're wrong. So you know better than me what source code I've read so far? Do you also happen to know what did I do with my spare camera battery? That could be useful.
        scrollaway 5y ago
        Did you check your desk? Get a second pair of eyes, it's always in front of you and you don't realize it. If you're going to state opinions as facts, you can't then come back and tell people "oh so you know my own opinions better than me?!".
- ajford 5y ago
  Are you talking about an API reference? Django has that: https://docs.djangoproject.com/en/3.2/ref/ https://docs.djangoproject.com/en/3.2/ref/ They have an entire set of tutorial/getting started type docs that are definitely very wordy and based around getting you comfortable with Django's paradigm, but they do have a rather well done API/Module reference that does a good job getting to the meat of the topic imo.
tedmiston 5y ago
This was my response exactly. The article is a list of nits, not major issues, and most are not about the framework itself, but rather things like tooling conveniences. I'm surprised someone finds room to criticize the Django docs. It's got the best docs of any web framework I've used in the past decade. It's great to be able to find everything you need easily in one place and not have to go searching for Stack Overflow answers or blog posts just to solve common problems.
nuerow 5y ago
> What??? 4 and 5 are legit complaints, the rest is literally the nittiest of picks, in my opinion. I'd argue that 4) (async support) is the only meaningful point and 5) , given it's a Python framework, is at most a nice-to-have. But yes, this article is a complete waste of a click.
- paganel 5y ago
  > I'd argue that 4) (async support) is the only meaningful point and 5) , given it's a Python framework, is at most a nice-to-have. Same thing here, and I've been writing Django code for a living for 15 years now. What baffled me was the complaint about the admin interface, if used right can get a small business up and running almost instantly.
- ledauphin 5y ago
  I'd recommend giving a bit more weight to the experiences of other developers. Static typing in Python has become fairly widespread and even idiomatic in some circles, even if you haven't experienced that yet.
  - nuerow 5y ago
    > I'd recommend giving a bit more weight to the experiences of other developers. Static typing in Python has become fairly widespread and even idiomatic in some circles, even if you haven't experienced that yet. You should really refrain from filling in the void in your understanding or knowledge of anyone else's experience with output from your imagination. Also, I'm not sure you noticed the absurdity of trying to sell Python's type hints as being "idiomatic in some circles" when you're discussing a specific circle of Python which is renowned for not using type hints at all.
    - ledauphin 5y ago
      I took the point of the article to be that Django is making no effort to enter the now fairly idiomatic world of static type checking in Python? I guess we could reasonably debate about the meaning of "nice-to-have", but for some people including me, I would find working with a framework that thwarted my efforts to statically type my code to be more than just "not nice" - I would actively avoid it. Which, again, I believe gets at the heart of the article. There are plenty of folks who will choose not to use Django precisely because it seems not to be evolving alongside the language.
cosmosgenius 5y ago
the one thing I actually like about django is consistency, which is exactly what i am looking for when i am deploying something to production. Async support is nice and all, but i fell in love with django (and the eco system) mainly because it solves problems which i really don't want to concentrate on.
ehutch79 5y ago
I don't know about #4. I use async several places in my django 2.x project without issue. I'm not entirely sure where django it self might need to be made async
zer01 5y ago
I love Python, and I love Django, but I think async support would be a bad idea personally. I’ve written a lot of things using asyncio and steered into it hard when it was first stable, but I’ve found it cumbersome and (zooming out) pretty unnecessary in the grand scheme of things. Asyncio is cooperative concurrency where you’re supposed to politely yield back to the event loop when you’re blocking on IO, but the event loop doesn’t bawk (that I’ve seen) when things are blocking accidentally. I’ve chased a number of very real bugs around this in production and I will say it’s some of the most infuriatingly difficult to pin down set of bugs I’ve encountered to date (for example, redis is fast enough to not notice any issues until your redis query grows slow enough that you do, and at that point things behave strangely with no clear indication why). Remember, even printing things to stdout is still technically a blocking IO operation. Same with reading/writing any files. Lots of issues can crop up in weird ways with stuff like this. On the other hand, the “boring” Python threading library is preemptive concurrency, meaning your libraries can’t hold things up even if you wanted to. In general give me preemptive concurrency any day - I find it easier to carefully code around state mutations than diagnose why a library might be blocking the event loop. I haven’t noticed a massive perf difference between the two and to guarantee that I don’t have weird “you’re blocking accidentally” sorts of issues means I’ll stick with threads any day of the week. Also exception handling in asyncio land is (again just from my experience, it’s been a couple years) not great, I subscribe to the mantra of letting things crash, but things silently crashing is a deep seeded behavior change that seems to go against the Python mantra of “throw exceptions and let things fail”. For now I keep things boring with Python, and if I need massive concurrency just rewrite things in elixir (which is preemptive concurrency and the actor model which is super powerful as a combo).

dc-programmer 5y ago

Number 1 isn’t a show stopper in any way but is it pretty annoying. The primary django docs are very textual and place more emphasis on developing intuition and understanding context, than something that can be quickly referenced. Also a lot of the method parameters are either not documented or not explained. I think Django would benefit from a more technical and complete but less dense secondary reference.

grenoire 5y ago
I fully agree, it usually ends up being barely useful, and not enough. It does not explain how certain parts of the magic happen, what the best practices are, what the expected types for arguments may be, etc. It's not bad, but usually verbose in the wrong bits, and sparse in the details.
ianai 5y ago
“ more technical and complete but less dense secondary reference.” Isn’t that basically just reading the source code? Like I get that’s probably not right to throw everyone toward, but reading source code is a staple task for working with FOSS.
- Areading314 5y ago
  A lot of devs don't understand this, but can save a lot of time, especially when the code is all python. Especially if you questions are off the beaten track
  - pbalau 5y ago
    Django has one of the best source code base I ever saw, in 20+ years of doing software. If anyone has issues reading the Django source code, they probably should stay away from software development.
    - deleted 5y ago
      [deleted]
    - scrollaway 5y ago
      > If anyone has issues reading the Django source code, they probably should stay away from software development. First of all, juniors exist you know that right? Please don't gatekeep. Second, you're wrong. The Django codebase is overall good quality but if it's "one of the best you ever saw in 20 years" you haven't dug deep. Django has a lot of horrible no good bad awful parts to it. To their credit they tend to improve with age, not get worse, but it's certainly not worthy of such praise imo.
      - pbalau 5y ago
        > Second, you're wrong. So you know better than me what source code I've read so far? Do you also happen to know what did I do with my spare camera battery? That could be useful.
        scrollaway 5y ago
        Did you check your desk? Get a second pair of eyes, it's always in front of you and you don't realize it. If you're going to state opinions as facts, you can't then come back and tell people "oh so you know my own opinions better than me?!".
ajford 5y ago
Are you talking about an API reference? Django has that: https://docs.djangoproject.com/en/3.2/ref/ https://docs.djangoproject.com/en/3.2/ref/ They have an entire set of tutorial/getting started type docs that are definitely very wordy and based around getting you comfortable with Django's paradigm, but they do have a rather well done API/Module reference that does a good job getting to the meat of the topic imo.

tedmiston 5y ago

This was my response exactly. The article is a list of nits, not major issues, and most are not about the framework itself, but rather things like tooling conveniences. I'm surprised someone finds room to criticize the Django docs. It's got the best docs of any web framework I've used in the past decade. It's great to be able to find everything you need easily in one place and not have to go searching for Stack Overflow answers or blog posts just to solve common problems.

nuerow 5y ago

> What??? 4 and 5 are legit complaints, the rest is literally the nittiest of picks, in my opinion. I'd argue that 4) (async support) is the only meaningful point and 5) , given it's a Python framework, is at most a nice-to-have. But yes, this article is a complete waste of a click.

paganel 5y ago
> I'd argue that 4) (async support) is the only meaningful point and 5) , given it's a Python framework, is at most a nice-to-have. Same thing here, and I've been writing Django code for a living for 15 years now. What baffled me was the complaint about the admin interface, if used right can get a small business up and running almost instantly.
ledauphin 5y ago
I'd recommend giving a bit more weight to the experiences of other developers. Static typing in Python has become fairly widespread and even idiomatic in some circles, even if you haven't experienced that yet.
- nuerow 5y ago
  > I'd recommend giving a bit more weight to the experiences of other developers. Static typing in Python has become fairly widespread and even idiomatic in some circles, even if you haven't experienced that yet. You should really refrain from filling in the void in your understanding or knowledge of anyone else's experience with output from your imagination. Also, I'm not sure you noticed the absurdity of trying to sell Python's type hints as being "idiomatic in some circles" when you're discussing a specific circle of Python which is renowned for not using type hints at all.
  - ledauphin 5y ago
    I took the point of the article to be that Django is making no effort to enter the now fairly idiomatic world of static type checking in Python? I guess we could reasonably debate about the meaning of "nice-to-have", but for some people including me, I would find working with a framework that thwarted my efforts to statically type my code to be more than just "not nice" - I would actively avoid it. Which, again, I believe gets at the heart of the article. There are plenty of folks who will choose not to use Django precisely because it seems not to be evolving alongside the language.

cosmosgenius 5y ago

the one thing I actually like about django is consistency, which is exactly what i am looking for when i am deploying something to production. Async support is nice and all, but i fell in love with django (and the eco system) mainly because it solves problems which i really don't want to concentrate on.

ehutch79 5y ago

I don't know about #4. I use async several places in my django 2.x project without issue. I'm not entirely sure where django it self might need to be made async

zer01 5y ago

I love Python, and I love Django, but I think async support would be a bad idea personally. I’ve written a lot of things using asyncio and steered into it hard when it was first stable, but I’ve found it cumbersome and (zooming out) pretty unnecessary in the grand scheme of things. Asyncio is cooperative concurrency where you’re supposed to politely yield back to the event loop when you’re blocking on IO, but the event loop doesn’t bawk (that I’ve seen) when things are blocking accidentally. I’ve chased a number of very real bugs around this in production and I will say it’s some of the most infuriatingly difficult to pin down set of bugs I’ve encountered to date (for example, redis is fast enough to not notice any issues until your redis query grows slow enough that you do, and at that point things behave strangely with no clear indication why). Remember, even printing things to stdout is still technically a blocking IO operation. Same with reading/writing any files. Lots of issues can crop up in weird ways with stuff like this. On the other hand, the “boring” Python threading library is preemptive concurrency, meaning your libraries can’t hold things up even if you wanted to. In general give me preemptive concurrency any day - I find it easier to carefully code around state mutations than diagnose why a library might be blocking the event loop. I haven’t noticed a massive perf difference between the two and to guarantee that I don’t have weird “you’re blocking accidentally” sorts of issues means I’ll stick with threads any day of the week. Also exception handling in asyncio land is (again just from my experience, it’s been a couple years) not great, I subscribe to the mantra of letting things crash, but things silently crashing is a deep seeded behavior change that seems to go against the Python mantra of “throw exceptions and let things fail”. For now I keep things boring with Python, and if I need massive concurrency just rewrite things in elixir (which is preemptive concurrency and the actor model which is super powerful as a combo).