7 ms·

Shame about Channels, but I see the logic in not including it. Django is pretty awesome as a backend, and while it's not a 'cool' framework anymore (I feel old!

by orf 10y ago

Shame about Channels, but I see the logic in not including it. Django is pretty awesome as a backend, and while it's not a 'cool' framework anymore (I feel old!) it's amazing for writing back-office applications. I use it as an API backend with Django-rest-framework. The advantage is you get ridiculous amounts of packages that all integrate with Django that does pretty much anything you want. Also the ORM doesn't suck now so that's a bonus.

graffitici 10y ago
Why did the ORM suck before? Were there major changes done to the ORM?
- sneakymichael 10y ago
  Potentially in part because, until fairly recently (version 1.7 I believe), Django didn't have support for database schema migration built-in- https://docs.djangoproject.com/en/1.7/topics/migrations/ https://docs.djangoproject.com/en/1.7/topics/migrations/
  - graffitici 10y ago
    I see. If that's the only reason, not sure if it's a major problem with the ORM, given that you could use South instead with almost the same outcome.
    - swinglock 10y ago
      The built-in migration code is even the continuation of South. https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django/description https://www.kickstarter.com/projects/andrewgodwin/schema-mig...
- orf 10y ago
  Was pretty limited and very very inferior to SQLAlchemy. It still is, but it's bearable. As an example off the top of my head when I started with Django you couldn't bulk create objects, if you wanted to create 100 records it needed 100 separate INSERT statements. That got old fast. Edit: Not sure why the downvotes, perhaps comment on why you think I'm wrong?
  - SEJeff 10y ago
    That is true, but it was fixed in Django 1.4... in 2012. Technology moves a bit in 4 years.
    - orf 10y ago
      Yep, but as I said it's still rather limited compared to SQLAlchemy. Stuff like aggregations are cumbersome, and it's really really easy to shoot yourself in the foot and cause O(n) queries (especially in templates and in custom admin views). Things specific to Postgres are rather lacking. While they added support for advanced datatypes like arrays, hstore, intervals and search recently (yay!) you still can't use any other index than a standard btree one or things like recursive queries. SQLAlchemy supports all of these, and has done since forever. Things are progressing, don't get me wrong, but there is a long way to go.
      - jsmeaton 10y ago
        SQLAlchemy has a lot more power than Django's ORM. I'd argue that Django's ORM is more accessible to beginner SQL users though. Django handles joins for you (which admittedly breaks down with very complex queries) which is the only ORM I'm aware of that does. SQLAlchemy maps much more closely to SQL and is a tighter abstraction. A GSOC project is currently adding customisable indexes: https://groups.google.com/forum/#!topic/django-developers/XAZNApcFFsk https://groups.google.com/forum/#!topic/django-developers/XA...
- rtpg 10y ago
  sibling mentioned ORM migrations not being built in. It used to be that it was very hard to write custom expressions or aggregations (like `SUM`) in a way that would be first-class with ORM-provided expressions. This has been massively improved, and been made into a public API. So if the ORM doesn't support something you can write it easily. The core has also been majorly rewritten, which has made entire classes of bugs disappear. Before 1.8, it was possible to write expressions where the filters got so complex that the ORM would just give up. The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare. This doesn't happen anymore. A lot of old Django core code isn't really super durable, and you get a lot of pain because of it. But the past couple of releases have cleaned up a lot of code, making Django into an extremely clean project.
  - jsmeaton 10y ago
    > The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare. Is this really true? Can you point me at any tickets or examples? Everything else you've said is bang on though.
    - rtpg 10y ago
      Ah, I feel bad, because I ran into this twice and didn't report this properly. The situations I ran into happened whenever I would combine filters and excludes, along with some joins. The system would simply drop filters, and just do a plain SELECT on the table. But ever since the 1.8 ORM update, I have no longer been able to reproduce this, so have assumed it was fixed through cleaning up the internals. I did report a related bug[0] where the ORM gets confused by complex queries, but it didn't just drop the filter. It blew up, which is better but still a bit concerning. [0]: https://code.djangoproject.com/ticket/24386 https://code.djangoproject.com/ticket/24386
      - jsmeaton 10y ago
sdegutis 10y ago
Huh. Your argument in favor of Django is basically "it may not be cool, but it's got a lot of libraries written for it." Which is basically the same thing people used to say (and still say) about Java, compared to something "cool" and "new" like, say, Django or Rails (at the time). In other words, Django used to be picked because it was the hot new thing, but since then it's no longer hot or new, but since enough people adopted it, they wrote enough libraries for it to make it worth continuing to use on new projects.
- TylerE 10y ago
  Well, that's basically it. It certainly isn't cutting edge, nor anything close to it. It's stable and boring. Some people like that, believe it or not.
- hrayr 10y ago
  Sometimes maturity trumps fads, in other words boring > hot.
- vertex-four 10y ago
  And there's still a lot of stuff - even new projects - written in Java and on the JVM.
- coldtea 10y ago
  >* In other words, Django used to be picked because it was the hot new thing, but since then it's no longer hot or new, but since enough people adopted it, they wrote enough libraries for it to make it worth continuing to use on new projects.* Yeah, in other words, it's now both mature and with a rich ecosystem. Just the ticket! And I wouldn't even say that people went for it because it was "hot new" back in the day. People went for it because it solved their problems. Being in fashion was never it's strong point, Rails and Node/Express did far better with that.
- paganel 10y ago
  > In other words, Django used to be picked because it was the hot new thing I picked up Django in February 2006, in fact the (very cool) boss I had back then picked it up for me and my other programmer colleague, I think it was version 0.96 (or maybe 0.92 ?, not sure). Anyway, we didn't pick Django because it was "new and cool", my boss had a business to run (which folded two years later for unrelated reasons), but instead because Django seemed like a pretty good candidate back then at doing a decent job. Which it did, admirably well, I think ours might have been one of the first lead-management systems built on top of Django's admin interface (lots of monkey-patching involved, which is still one of my "guilty" soft-spots as a programmer 10 years later). Anyway, web programming back then was, how to put it, in a very interesting place. In Python's case we had Zope/Plone, which had sort of its separate ecosystem doing weird (but sometimes very interesting things) like an object-oriented database (hello, ZODB!) with a very interesing routing mechanism on top of it, Quixote (https://wiki.python.org/moin/Quixote https://wiki.python.org/moin/Quixote) and mod_python (on top of which I built my first personal Python web-project). PHP was the hot thing, even though not the newest thing, Java's web offering consisted in Struts and some other thing which had a related name for which you needed to be an "Java architect" in order to put 2 forms and 3 templates together, Rails was just about to be launched, ASP was a joke (at least according to my other programmer colleague, who was also teaching ASP at University) and I won't comment on Perl, of which I know not too many things (and which seemed pretty cool, I have to admit). Considering all this of course that Django (and Rails) was a huge breath of fresh air. People nowadays take things like JS web frameworks for granted, but until not too long ago the web was a very different place (which sometimes I really miss).
rdudek 10y ago
So does that mean we should pick a new language/framework that is "hot" now and write a bunch of libraries for it? Basically, reinventing the wheel over and over and over again?
- passiveincomelg 10y ago
  There are some differences that one could call objectively better in other technologies compared to Python/Django. I'm somewhat conflicted about Channels. On the one hand it's cool what you can do with it and the design cleverly avoids rewriting all of Django to be async. On the other hand it is crazy how many shenanigans one needs to pull off to achieve what comes for free with Go or Erlang. Fashion-like churn is obviously nonsense and reinventing the wheel usually a waste of time. But when you need a really round wheel and your current tools can only make hexagons...
hrayr 10y ago
Why a shame? What would Channels buy you if it were included into the framework? I would love to see Django split up into smaller official external packages and repackaged as two or three different official starter packs (Traditional, API, SPA, etc.) with each containing a different set of packages that make sense (DRF, Channels, Models, Views, Forms, etc.). I know this goes against the current "Batteries are included" model, but why can't we treat Django as the standards body, and the various starter packs as the more targeted "batteries are included" frameworks.
- rukittenme 10y ago
  You might as well use Flask at that point. You can use cookie-cutter to create the starter packs.
  - cmdrfred 10y ago
    I love Flask. People say Django is easier to use but I had a much easier time with Flask. It's well documented and very flexible.
    - knabacks 10y ago
      Maybe not easier to use in general, but you don't have to replicate all the daily stuff you maybe need for your project. With Flask you have to recreate many things (for example acc management) or rely on a thrid party-dev. In django you get core stuff from the core team(also with the freedom of recreating it yourself or use some app from a thridparty-dev).
  - hrayr 10y ago
    Sure, I love Flask but Django has it's own ecosystem and that's what I'm talking about. I know anyone can use cookie-cutter, but I'm talking about trimming Django itself. Externalize Forms, Templates, etc. and build several core starter packages (including current Django). This gives a few base starting points.
    - 10y ago
ubernostrum 10y ago
Channels will get there. It just wasn't quite ready on time for 1.10. Hopefully it will be ready on time for 1.11, and then it'll ship in Django.
- xlxlxlx 10y ago
  I just used Channels in a personal project and it's great! My requirements were mostly basic and I haven't put it into production yet, but everything has gone smoothly so far.
  - brianwawok 10y ago
    What did you do with it? I still haven't figured out what to do with them...
    - xlxlxlx 10y ago
      I made something like a cross between a chat room and reddit. There are any number of possible rooms (like subreddits), with new top level posts popping up in real time, and when you click on a post, it expands and the replies become visible as a comment chain. It's not done yet though. For a while now I've been trying to do as much as I can on a single project for one week, and then start another. I definitely plan to come back to this one when I can. This week I'm using Channels again too. I'm making a head-to-head Minesweeper web app where you can challenge and compete against other players. After finding an opponent, essentially you'll see your own board and your opponent's board side by side, and each players' progress is broadcast in real time via Channels to one another.
      - brianwawok 10y ago
        Cool games and chat both seem like obvious uses.

by orf 10y ago

graffitici 10y ago

Why did the ORM suck before? Were there major changes done to the ORM?

sneakymichael 10y ago
Potentially in part because, until fairly recently (version 1.7 I believe), Django didn't have support for database schema migration built-in- https://docs.djangoproject.com/en/1.7/topics/migrations/ https://docs.djangoproject.com/en/1.7/topics/migrations/
- graffitici 10y ago
  I see. If that's the only reason, not sure if it's a major problem with the ORM, given that you could use South instead with almost the same outcome.
  - swinglock 10y ago
    The built-in migration code is even the continuation of South. https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django/description https://www.kickstarter.com/projects/andrewgodwin/schema-mig...
orf 10y ago
Was pretty limited and very very inferior to SQLAlchemy. It still is, but it's bearable. As an example off the top of my head when I started with Django you couldn't bulk create objects, if you wanted to create 100 records it needed 100 separate INSERT statements. That got old fast. Edit: Not sure why the downvotes, perhaps comment on why you think I'm wrong?
- SEJeff 10y ago
  That is true, but it was fixed in Django 1.4... in 2012. Technology moves a bit in 4 years.
  - orf 10y ago
    Yep, but as I said it's still rather limited compared to SQLAlchemy. Stuff like aggregations are cumbersome, and it's really really easy to shoot yourself in the foot and cause O(n) queries (especially in templates and in custom admin views). Things specific to Postgres are rather lacking. While they added support for advanced datatypes like arrays, hstore, intervals and search recently (yay!) you still can't use any other index than a standard btree one or things like recursive queries. SQLAlchemy supports all of these, and has done since forever. Things are progressing, don't get me wrong, but there is a long way to go.
    - jsmeaton 10y ago
      SQLAlchemy has a lot more power than Django's ORM. I'd argue that Django's ORM is more accessible to beginner SQL users though. Django handles joins for you (which admittedly breaks down with very complex queries) which is the only ORM I'm aware of that does. SQLAlchemy maps much more closely to SQL and is a tighter abstraction. A GSOC project is currently adding customisable indexes: https://groups.google.com/forum/#!topic/django-developers/XAZNApcFFsk https://groups.google.com/forum/#!topic/django-developers/XA...
rtpg 10y ago
sibling mentioned ORM migrations not being built in. It used to be that it was very hard to write custom expressions or aggregations (like `SUM`) in a way that would be first-class with ORM-provided expressions. This has been massively improved, and been made into a public API. So if the ORM doesn't support something you can write it easily. The core has also been majorly rewritten, which has made entire classes of bugs disappear. Before 1.8, it was possible to write expressions where the filters got so complex that the ORM would just give up. The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare. This doesn't happen anymore. A lot of old Django core code isn't really super durable, and you get a lot of pain because of it. But the past couple of releases have cleaned up a lot of code, making Django into an extremely clean project.
- jsmeaton 10y ago
  > The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare. Is this really true? Can you point me at any tickets or examples? Everything else you've said is bang on though.
  - rtpg 10y ago
    Ah, I feel bad, because I ran into this twice and didn't report this properly. The situations I ran into happened whenever I would combine filters and excludes, along with some joins. The system would simply drop filters, and just do a plain SELECT on the table. But ever since the 1.8 ORM update, I have no longer been able to reproduce this, so have assumed it was fixed through cleaning up the internals. I did report a related bug[0] where the ORM gets confused by complex queries, but it didn't just drop the filter. It blew up, which is better but still a bit concerning. [0]: https://code.djangoproject.com/ticket/24386 https://code.djangoproject.com/ticket/24386
    - jsmeaton 10y ago

sdegutis 10y ago

Huh. Your argument in favor of Django is basically "it may not be cool, but it's got a lot of libraries written for it." Which is basically the same thing people used to say (and still say) about Java, compared to something "cool" and "new" like, say, Django or Rails (at the time). In other words, Django used to be picked because it was the hot new thing, but since then it's no longer hot or new, but since enough people adopted it, they wrote enough libraries for it to make it worth continuing to use on new projects.

TylerE 10y ago
Well, that's basically it. It certainly isn't cutting edge, nor anything close to it. It's stable and boring. Some people like that, believe it or not.
hrayr 10y ago
Sometimes maturity trumps fads, in other words boring > hot.
vertex-four 10y ago
And there's still a lot of stuff - even new projects - written in Java and on the JVM.
coldtea 10y ago
>* In other words, Django used to be picked because it was the hot new thing, but since then it's no longer hot or new, but since enough people adopted it, they wrote enough libraries for it to make it worth continuing to use on new projects.* Yeah, in other words, it's now both mature and with a rich ecosystem. Just the ticket! And I wouldn't even say that people went for it because it was "hot new" back in the day. People went for it because it solved their problems. Being in fashion was never it's strong point, Rails and Node/Express did far better with that.
paganel 10y ago
> In other words, Django used to be picked because it was the hot new thing I picked up Django in February 2006, in fact the (very cool) boss I had back then picked it up for me and my other programmer colleague, I think it was version 0.96 (or maybe 0.92 ?, not sure). Anyway, we didn't pick Django because it was "new and cool", my boss had a business to run (which folded two years later for unrelated reasons), but instead because Django seemed like a pretty good candidate back then at doing a decent job. Which it did, admirably well, I think ours might have been one of the first lead-management systems built on top of Django's admin interface (lots of monkey-patching involved, which is still one of my "guilty" soft-spots as a programmer 10 years later). Anyway, web programming back then was, how to put it, in a very interesting place. In Python's case we had Zope/Plone, which had sort of its separate ecosystem doing weird (but sometimes very interesting things) like an object-oriented database (hello, ZODB!) with a very interesing routing mechanism on top of it, Quixote (https://wiki.python.org/moin/Quixote https://wiki.python.org/moin/Quixote) and mod_python (on top of which I built my first personal Python web-project). PHP was the hot thing, even though not the newest thing, Java's web offering consisted in Struts and some other thing which had a related name for which you needed to be an "Java architect" in order to put 2 forms and 3 templates together, Rails was just about to be launched, ASP was a joke (at least according to my other programmer colleague, who was also teaching ASP at University) and I won't comment on Perl, of which I know not too many things (and which seemed pretty cool, I have to admit). Considering all this of course that Django (and Rails) was a huge breath of fresh air. People nowadays take things like JS web frameworks for granted, but until not too long ago the web was a very different place (which sometimes I really miss).

rdudek 10y ago

So does that mean we should pick a new language/framework that is "hot" now and write a bunch of libraries for it? Basically, reinventing the wheel over and over and over again?

passiveincomelg 10y ago
There are some differences that one could call objectively better in other technologies compared to Python/Django. I'm somewhat conflicted about Channels. On the one hand it's cool what you can do with it and the design cleverly avoids rewriting all of Django to be async. On the other hand it is crazy how many shenanigans one needs to pull off to achieve what comes for free with Go or Erlang. Fashion-like churn is obviously nonsense and reinventing the wheel usually a waste of time. But when you need a really round wheel and your current tools can only make hexagons...

hrayr 10y ago

Why a shame? What would Channels buy you if it were included into the framework? I would love to see Django split up into smaller official external packages and repackaged as two or three different official starter packs (Traditional, API, SPA, etc.) with each containing a different set of packages that make sense (DRF, Channels, Models, Views, Forms, etc.). I know this goes against the current "Batteries are included" model, but why can't we treat Django as the standards body, and the various starter packs as the more targeted "batteries are included" frameworks.

rukittenme 10y ago
You might as well use Flask at that point. You can use cookie-cutter to create the starter packs.
- cmdrfred 10y ago
  I love Flask. People say Django is easier to use but I had a much easier time with Flask. It's well documented and very flexible.
  - knabacks 10y ago
    Maybe not easier to use in general, but you don't have to replicate all the daily stuff you maybe need for your project. With Flask you have to recreate many things (for example acc management) or rely on a thrid party-dev. In django you get core stuff from the core team(also with the freedom of recreating it yourself or use some app from a thridparty-dev).
- hrayr 10y ago
  Sure, I love Flask but Django has it's own ecosystem and that's what I'm talking about. I know anyone can use cookie-cutter, but I'm talking about trimming Django itself. Externalize Forms, Templates, etc. and build several core starter packages (including current Django). This gives a few base starting points.
  - 10y ago

ubernostrum 10y ago

Channels will get there. It just wasn't quite ready on time for 1.10. Hopefully it will be ready on time for 1.11, and then it'll ship in Django.

xlxlxlx 10y ago
I just used Channels in a personal project and it's great! My requirements were mostly basic and I haven't put it into production yet, but everything has gone smoothly so far.
- brianwawok 10y ago
  What did you do with it? I still haven't figured out what to do with them...
  - xlxlxlx 10y ago
    I made something like a cross between a chat room and reddit. There are any number of possible rooms (like subreddits), with new top level posts popping up in real time, and when you click on a post, it expands and the replies become visible as a comment chain. It's not done yet though. For a while now I've been trying to do as much as I can on a single project for one week, and then start another. I definitely plan to come back to this one when I can. This week I'm using Channels again too. I'm making a head-to-head Minesweeper web app where you can challenge and compete against other players. After finding an opponent, essentially you'll see your own board and your opponent's board side by side, and each players' progress is broadcast in real time via Channels to one another.
    - brianwawok 10y ago
      Cool games and chat both seem like obvious uses.