Hacker News new | past | comments | ask | show | jobs | submit login
Django 2.2 (djangoproject.com)
341 points by ataylor32 86 days ago | hide | past | web | favorite | 236 comments



Django/Jupyter/pandas is an ecosystem that's hard to beat.

If you're not already using it, check out `django-extensions`. You can use `./manage.py shell_plus --notebook` to launch a Django-friendly Jupyter notebook.

From there you can prototype with extreme ease and confidence.

I have also built a trivial custom model Manager so I can do stuff like:

    User.objects.all().to_dataframe("first_name", "last_name", "email")
Honestly I can't see myself being even slightly tempted to move to something else unless I can replicate this workflow.


Learning that I could just run pandas.DataFrame(User.objects.all().values()) in a jupyter notebook vastly improved my QoL in some projects.


My god... I can't tell you how happy that just made made me. I've been using runserver_plus for code reloading for a while, but hadn't realised this could do the same for the shell. Thanks!


Wow that looks powerful. I have a YOLO / openCV project I need a web app built for so users can log in and download preconfigurations... was thinking elixir/phoenix framework but i'm second guessing the productivity hit i'd take due to lack of SO questions, and mature libraries.


Not a data engineer / scientist here.

What am I missing with data-frames?

I've written products that utilized them before (years ago), but it's been long enough that I don't know what I would even use them for in daily programming.


From NumPy, you get fast (vectorized) operations on large multidimensional arrays of numbers. This bit not be so useful outside of a data-science context but it depends on what it is you _are_ doing. Most graphics stuff is also arrays of numbers, for example. Also lots of useful indexing/slicing/masking/filtering on those structures. You can also have non-numeric multidimensional arrays, but the performance part might not be there depending on the type.

Pandas adds utility methods like join, groupby, and fromsql. Also hierarchical indexing, and a bunch of other stuff that I don't know much about - I'm not in data-science either, but I work with some of them.

Overall, lots of useful stuff for processing tables locally once you've fetched them from SQL or similar. Also, the simple fact of having a tabular data structure without needing to define a custom Row class. Lists of dicts or tuples have a lot of overhead by comparison.


They're for tables and doing table-ie things: an imperative programming method for the same tasks people use Excel or SQL for.

This dovetails nicely with most data science-ie tasks, like statistical analysis, engineering features, simple machine learning techniques (the tables can be easily transformed into numpy arrays), and plotting results.

You can use them any time you feel the need to do table manipulations on non-insanely-large data: aggregate, transform, combine, split, reshape, join...


Got it, I was aware of this and many of the performance benefits another user mentioned, but wasn't sure how it could be useful in daily operation or quick Django shell_plus style scripting (one-off commands) when inspecting something like a User's table, as the original comment above indicated.


pandas.read_sql('select first_name, last_name, email from users', conn)

this approach avoids the full data copy calling '.all()' materializes.


.all() doesn't actually do anything, and could be omitted. The beauty of this setup is if you need to rewrite the implementation of .to_dataframe() to optimize it, you can (e.g. to remove the .values() you're worries about and use your above code)


You just discovered repl driven development that lisp users have been advocating for years. Check it out in Clojure: https://vvvvalvalval.github.io/posts/what-makes-a-good-repl....


Well, python has had repl driven development for years too, notebooks only change the tooling around that if I’m not wrong.


Yes, Python does have a repl, but I've never seen anyone doing real "repl driven development" in Python in my 15+ years of using it (btw, just testing some code in the repl isn't anywhere near repl driven development). See the blog post linked above to understand what I'm talking about.

In Python, the repl is an accessory that helps testing small portions of code. In Clojure, the repl augments the editor, becoming an integral part of the development process.

My understanding of the parent argument was that the combo Django/Jupyter/pandas is "an ecosystem that's hard to beat" because of the tight feedback loop between writing the code and seeing what it does.


Ive never heard the term repl driven development, but I have been doing most of my coding in a jupyter/ipython notebook for around 7 years now and have been advocating it the whole time. The longer I do this the more I realize that I really need to try lisp


Awesome! That's exactly why I pointed out Lisp. Those who enjoy the tight feedback loop of Jupyter might also enjoy a language where this process is the natural way of doing things.


Agreed, the GUI repl may be more friendly to data scientists and analysts who know some coding but not emacs.

Furthermore, the marriage of application framework / application model wrappers with industry-leading data science tools sounds particularly special, and orthogonal to the presence of a repl.


I think ipython/jupyter notebooks are more analogous to Clojure's REBL[0][1], which is very cool but not nearly as mature.

[0]: https://github.com/cognitect-labs/REBL-distro

[1]: https://www.youtube.com/watch?v=c52QhiXsmyI


Thanks for the link, I'd never heard of REBL. Very cool!


This release includes the Watchman based reloader I worked on for about a year. It turns out auto reloading in Python is not an easy task, and I’m really nervous about edge cases I haven’t considered!

I’ve actually had a nightmare where everyone’s auto reloader was broken. While it never runs in production (right?!) it’s actually a pretty critical bit of Django that had not been touched in about 10 years!


Thank you! The new auto reloader is better by quite a bit. Many people have talked about doing this over the years, but nobody's been willing to do the grunt work and figure out all the corner cases, until you. Nice job!


Congratulations! What a great contribution, thanks very much for your work.


Well nothing like shipping code and letting all your users test it! Congrats.


Thank you!!


I love Django. I've used it for the last 8 years. I'm happy to see the project is still thriving.

At this point, for me Django is pretty much synonymous with Django REST framework (https://www.django-rest-framework.org/). I can't imagine a better API than Django w/ REST framework.

For static sites I use Django's templates. Otherwise, I just use Django w/ REST framework for my API, and to serve up index.html. My index.html will include a link to my JS bundle(s) - I use a separate build system (Webpack/Babel/etc) to handle JS.


I think it's worth mentioning, that the creator of Django REST framework is also working on Starlette [0], which is a modular framework that comes with async support, crazy performance, and more...

[0]: https://www.starlette.io/


What would something like Starlette be used for?


Try serving your static content from a specialized host, for example firebase hosting.

Then, you don’t need to serve any static content from your API server and can do away with nginx.

Use the whitenoise package for serving the Django admin pages if you still need them for administrative tasks.


Or serve statics from uWSGI (which also provides a spooler, cron and shared cachemem that works with python and Django but that's another story), here in optimized version for best results according to lighthouse:

uwsgi --plugin=python3,http,router_static,router_cache --mime-file /etc/mime.types --offload-threads '%k' --file-serve-mode x-accel-redirect --route '^/static/.* addheader:Cache-Control: public, max-age=7776000' --static-map $STATIC_ROOT=$STATIC_URL --static-gzip-all --cache2 'name=statcalls,items=100' --static-cache-paths 86400 --static-cache-paths-name statcalls"


Sane defaults FTW


DRF is awesome. If you're considering moving to or implementing GraphQL, though, Django + Graphile is amazingly productive and performant. No affiliation, just good experiences.

https://www.graphile.org/postgraphile/


If you're using Postgraphile for the API layer and a frontend framework for the view layer, what do you need Django for? Just migrations?


Postgraphile solves the problem of boilerplate CRUD very well but it does not handle custom and complex logic well. For instance, interacting with other APIs like payment.


I’m sorry you feel that way; I use PostGraphile with external APIs frequently, using makeExtendSchemaPlugin to easily add more types and resolvers to my GraphQL schema. Maybe you could go into more detail on the issues you’ve faced here so I can improve the project?


I do wish Django REST Framework shipped with faster serializer code.


You can use Serpy for that, although it will require some hacking for deserialization (a previous client of mine had a custom-built solution that used Serpy for responses but plain Form classes for parsing requests, but that seemed fine and they were handling 3k/requests per second at peak time).


I never quite got Serpy working, but swapping to uJSON and the DRF renderer[0] helped quite a bit in some cases.

[0] https://github.com/gizmag/drf-ujson-renderer


That's essentially what we ended up doing, selectively using Serpy for certain slow responses. It still felt hackish though, as though we were taking the brakes off certain responses because we knew they needed little validation (IIRC). DRF serializers still need work; marshmallow provides a similar feature set to DRF but serializes almost twice as fast:

https://voidfiles.github.io/python-serialization-benchmark/

Disclaimer: The above is not my project


The projects/app relationship never 'clicked' with me. I also have a dislike for the awkward 'polls' example in the django tutorial.

That said, I like Django. Of course, I liked Rails better, but maybe that's because it was my 'first' and I never used any of the big php frameworks for a long period of time.

I quit wasting my time with Flask for projects a while ago. It's a really great project and suited for smaller things, but you just end up re-implenting django. I'd rather someone made those decision for me.


> The projects/app relationship never 'clicked' with me.

This is an area that I think is poorly documented (both in the otherwise-great official docs and in the broader community). My advice for beginners is to just create an app called `core` and put everything there, until you have a reason to do something else. (I'd also propose putting your DJANGO_SETTINGS_MODULE aka "project name" as "django_settings" and only put your Django settings in there, but that's a little more esoteric and I'd not recommend that to a newbie in order to minimize confusion.)

In general, I think you should take the "monolith first" strategy (e.g. https://martinfowler.com/bliki/MonolithFirst.html) and just use a single app, unless you're writing something that is obviously going to be reused elsewhere.

The alternative is to attempt to define service boundaries before you know what your app's structure looks like; you'll inevitably get it wrong. And migrating models between apps is incredibly painful if you have foreign keys spanning apps.

I've also found a couple bugs in Django's migration machinery that only affect multi-app foreign key relationships; I've never seen a single-app migration bug. So there's a real cost to going down the multi-app path, which you need to balance against any benefits (I've seen none).

(Credentials/disclaimer; startup using DRF in prod for 3.5 years, mature domain model with ~50 model classes, feeling the pain of incorrectly choosing 5 apps in the initial setup instead of just using one. I'm sure there's a good argument for apps when you get to a larger scale and are sharing components/functionality between teams.)


>> I quit wasting my time with Flask for projects a while ago. It's a really great project and suited for smaller things, but you just end up re-implenting django

This is spot on .... Flask is great, but it seems that to get anything substantial done with Flask you must first reimplement big chunks of Djangoesque functionality in it - why not just jump straight to Django?


Yeah that or just plug in 5-6 extensions and you end up with the same. Found myself doing flask-sqlalchemy, flask-migrate, etc. after a while.


We split into multiple apps within one project/site for separation of concerns instead of reusability. We have ~370 apps and nest them quite heavily, probably ~30 at the top level. This works well for us and we've managed to scale nicely to 15 people working on the codebase quite nicely.


What do you mean by nesting apps? Like group them into domain folders and have multiple apps within a domain folder?


I assume Dan really means a nested directory structure, like so:

django_project/top_level_app/second_level_app/

in top_level_app you then could do

from second_level_app.models import model1

or from a different top level app:

from other_top_level_app.second_level_app.mixins import a_mixin


Yep, exactly this. For example: project/orders/orders_shipping/orders_ups

Unfortunately app names have a global namespace within Django's model registry, so we often have to prefix nested apps.

The place where this really works nicely is user facing features and internal editing interfaces, or in features where we have N of a feature that are all similar. For the former, we might have an app such as "blog", and then a nested app within that called "blog_editor". This way we can separate blog models, business logic and user-facing behaviour, from CRUD interfaces designed for internal users. In the latter, if we have 3 shipping providers, we might have an app "shipping" with the core shipping models, with nested apps for "ups", "royal_mail", "dpd", etc, each of which might have the necessary models needed to manage uploading to their APIs, business logic, etc. There may be a common-ish interface exposed by these apps.

This structure is probably the thing I like most about Django over, say, Rails. It's not necessary for all Django projects, but I think it's pretty nice.


Within a single app, could this not be done mith multiple model files, and multiple services files.

I usually organize my apps by having a services layer between models and views, such that the view functions have little to no knowledge about the underlying models.

This, in place of nested apps, I have "upsmodels.py" and "upsservice.py" and the view functions handles routing logic.


That would indeed work, however given that one app can have ~20 nested apps at the first level, this might become tricky to manage. There's a lot to be said to having a directory with ~5 files in it that is all you need to keep in your head for a feature.


Two Scoops books about Django have awesome tips and tricks about many topucs and architecture is one of them.

Even if the latest version is for 1.11, the concepts are relevant.


Mozilla has some large, public Django projects on Github that are worth taking a look at to see how they're splitting up apps.

https://github.com/mozilla/addons-server


I feel the same way. Does any one have a good overview on how the community actually separates functionality into “apps”?

I have been looking at a rails like framework in python called Masonite. Does anyone in the python/Django community think this will gain traction?


The separate apps thing is overblown (although that sentiment seems to be shared in these comments). If you're making a monolith web app, you can be safe just chucking it into one django app. If you're concerned about code organization, you can do that in one app with either sub apps or just turning files into packages later. I think this is a more productive strategy for django beginners.

If you've identified some clean, generic problem where you want to reuse the code or open source it, make it a separate app. If you have a web site with areas that barely interact with each other, make it into separate apps (a chef's website where the recipes are separate from the cooking classes calendar). If you know what you're doing and feel like separate apps will help with organization, then split them up as well. Otherwise, one is fine.


> Does any one have a good overview on how the community actually separates functionality into “apps”?

For the most part there isn't any need to, with the exception of things explicitly meant to be shared. So if you are a large company and want a bunch of custom auth logic or something to be shared among many different teams running their own Django service, then you might want to build that as an app. Or else if you were building something as an open source project you might want to do the same.

In terms of separating apps by functionality, I think the main reason many people do it is because they are under the mistaken impression that putting things into different apps will make them magically re-usable. That's not to say you shouldn't do it, only that I think most people do it for the wrong reasons.

In general I would say don't bother splitting up your project into different apps by functionality until you have too many models to comfortably fit into one file. That might not be until 20KLOC. For apps that are less than 10KLOC, I think in most cases the overhead probably outweighs the benefits.

There isn't really any hard rule one how to do this, but you might do something like:

- Account management app for creating and deleting users, getting user profiles, password resets, etc.

- Apps for integrations with third-party APIs, e.g. Duns or Mailgun.

- Apps for different front doors, e.g. if you make a Facebook chat bot that's powered by the same tech that powers your normal website.

And then after that you can possibly split up your business logic of your core website into different logical components, but I would do that last. By the time you get there you should start to have a feel for how to do this.

The one place I use it for our own startup is that we recently built a couple different front doors for our site, and each one accepts data in a slightly different format and has different authentication requirements. I put each of these in their own apps, but everything else is just in one main app.


> until you have too many models to comfortably fit into one file. That might not be until 20KLOC.

Even for larger apps in my django project, I convert my models into a package and split all my models into individual files (same with views and serializers for DRF). This keeps my models easier to manage.


Apps can be a good way to generalize a set of classes for reuse in other projects. For instance we put auth into an app so if we fire up other projects we don’t have to rewrite auth.


Thanks for the thoughtful response. Do you find yourself repeating code, or struggling to decide where code should live and where it should be imported?


I had this problem for the first couple years, but not anymore. What I did:

- I split the core app up into different views and services based on the functionality. For FWD:Everyone this is basically: account_management, admin_apis, content_discovery, organizations, upload_thread, read_thread, comments, and user.

I have a folder for all my views and a folder for all my services, and for each view there is one (or occasionally two) service files.

So e.g. in the views folder there is a file called account_management_views, and then in the services folder there is a file called account_management_service.

For utilities that get re-used across the entire app I have two additional things in the services folder, one is called util.py and the other is io_util.py.

Util is for things like sanitizing XSS that don't require any database access, and io_util is for things like get_user_from_username, get_user_from_email_address, etc.

Then you can import any models into io_util.py, but never into util.py. And you can import anything from util.py into io_util.py, but never the other way around. Then you can import anything from either util or io_util into any service method and shouldn't have any issues. (Although I always just import util or io_util, and then call the methods like util.sanitize_xss.)

Once I structured the services and utilities that way I never had issues again with circular imports or figuring out where to put stuff. Importing with Python is kind of difficult and janky in general, but so far this pattern seems to be working pretty well for both our startup and also for the consulting projects I've done.

Basically for logic that's mostly specific to a single view, put it in the services file for that view. Public functions in that folder can still be re-used in other services, but if they're fairly generic and they're re-used in more than one or two places then consider moving them into util or io_util so as to avoid circular import issues.


There's no hard rules about app separation. Here are some from my experience:

- You may have stuff that may be re-used for multiple projects. For example the departments of your organization and their attributes; these should be extracted to apps so they can be easily used for other projects. Of course this would make sense if you are a software house or an organization that need multiple apps (i.e a bank) not if you are working for a single application.

- Django recommends using a custom user model. I put that in a separate app along with any related classes like user preferences etc. See also my previous bullet.

- Non related models. If you add a model that doesn't have any relation to the rest of your models then maybe you should move it to a different app? For example in one of my applications I have a NewsItem model that is just a bunch of notes that the admins can add and will be visible to the homepage; there's no need to put it in with the rest of the app (of course this also obeys the 1st bullet)

- Beyond that, usually you'll understand when you have to separate your apps. You don't need to force it, I know of huge apps with a models or views py with thousands of lines (of course in such cases even if you think that these should belong to the same app nothing's stopping you from making them a package instead of a module). However you'll usually come to a point where you think that for your reasons you need to separate


I don't use multiple apps anymore and instead treat the project as the app, so my directory structure looks something like this ('project' can change to something specific to what you're working on):

* manage.py

* project/settings.py

* project/urls.py

* project/models/ (each model gets it's own file here)

* project/views/ (same for views)

...and so on. And in `INSTALLED_APPS` I just add 'project'.

Makes it so I don't waste a bunch of time trying to figure out which app to put a model in, etc.


That looks like rails. What made you settle on this given that Django promotes a different structure? I am curious as I like this approach as well, but would be nervous about making life harder by not following the framework and community path.


Been building Django apps for almost 10 years and after seeing the amount of wasted time going into organizing things into apps, I settled on this technique.

It doesn’t really swim against the current as long as you import models into the __init__.py file in their package.


We do this too on some projects, it's painless. As far as I know Django doesn't really have an opinion on this, you have a lot of freedom in how you organize your project.


I've never gone so far as each model getting its own file. Interesting idea.


They're just modules by another name.

The way I think about design is usually centered around the data model, so if some subject has a number of ORM models and is pretty self contained it makes sense to put them in their own app, together with related urls and views and stuff.

They still live in the same repository and aren't meant to be re-used, just split into logical parts to make the code base easier to think about. Modules, in other words.


As a Django enthusiast and python programmer, I often want less magic from Django, not more. This makes pyramid or flask seem tempting to me. If I wanted Rails that badly, I would simply port my code to Ruby.


Django is supposed to be the “Rails” of Python, allowing programmers who want a Rails-like experience to continue using Python instead of switching languages completely.

If you don’t want “magic” then your solution is right - just use Flask.


The thing with the "magic" of django is that you don't need to use it! It's up to you whether you want to use the magic or not! The magic is powerful. The thing that turns users away is learning the magic.


Django's supposedly independent components were built with the context of the rest of Django in mind and have all kinds of default behaviors based on that. Surely they may work without the rest, but it isn't nearly as smooth as working with independent libraries that were designed with a much more limited scope.


> Django is supposed to be the “Rails” of Python, allowing programmers who want a Rails-like experience to continue using Python instead of switching languages completely.

A small nitpick: While Django may indeed fill that role, it's actually older than Rails, so wasn't "supposed" to do that. Both projects have been created independently of each other.


I think pyramid or flask has more traction nowdays.


For small projects, I usually have two apps, the frontend and backend apps.


What I find most curious about Django/Python is that about 30% of the new installs are for legacy Python/Django (2.7/1.11):

  $ pypinfo --start-date 2019-01-01 --end-date 2019-03-31 -- 
  percent --markdown django pyversion
  Served from cache: False
  Data processed: 160.22 GiB
  Data billed: 160.22 GiB
  Estimated cost: $0.79

  | python_version | percent | download_count |
  | -------------- | ------: | -------------: |
  | 3.6            |  39.61% |      3,277,927 |
  | 2.7            |  29.59% |      2,448,652 |
  | 3.7            |  17.53% |      1,450,949 |
  | 3.5            |  10.37% |        858,325 |
  | 3.4            |   2.76% |        228,150 |
  | 3.8            |   0.07% |          5,428 |
  | 2.6            |   0.04% |          3,686 |
  | 3.3            |   0.03% |          2,103 |
  | 3.2            |   0.00% |            220 |
  | None           |   0.00% |             56 |
  | Total          |         |      8,275,496 |
I would expect everybody moving over 3.x by now - we are so close to 2.7 EoL in December...


I wouldn't call it "new installs" - most of the PyPI downloads in any category are going to be from deployment scripts.

It shows that 30% of projects being re-deployed are still on Python 2.7.


I think you nailed it - I wonder how many of those installs are from CI tools.


Trying to move, but it's tough. Old codebase, lots of deps, and no real benefit to upgrading to 3.6, nothing our end users will care about or notice (or pay for).

Upgrading to Python 3 is a chore. We have to do it, but it's not fun and it's barely useful.


Well said.


don't your users in 2020 care you are using an unsupported language? security wise


Of course not. That's the point.


the users care that your site is secure, especially if you're using their confidential info.

can you achieve security with a dead language? I don't think so.


Users care very little about security, actually.


I would argue py3 has negative utility for that reason. Plus, the mess of 3.5 vs 3.6 vs 3.7.


What happened between those?


Nothing obviously a "mess." Your guess is as good as mine.


At worst async became a keyword in 3.5. I have to say I am enjoying f-strings from 3.6.


Many many organizations are acting as if completely unaware of the EOL.

I assume they will simply run on the last 2.7 release until projects are shut down.


If I had any Python 2.7 stuff, I would simply move it to Pypy which has no such obsolescence date.


It's not just Python 2 itself that's going away, it's many of the popular packages for it, as well. Some are specifically waiting for 2.7 EOL to pull the plug on their side, so it's going to get much worse for anybody stuck on it.


Aren't there a ton of legacy 2.7 programs installed onto OS's that then probably download 2.7 to work?

e.g. some script has '$python my_program --arg foo' hardcoded instead of '$python3 my_prgram --arg foo'


2.2 is the first LTS since 1.11. I expect a lot of people will upgrade now that it's out.

Edit: Oh, but that doesn't account for the older Python version. Yeah, that is interesting.


Bitter clinger to 2.7 here.

I'm sure the IPv6 group expected the world to have migrated more quickly, too.


Not to bring back an old debate, but I simply want to point out the obvious: many data scientists disliked Python 3.x. I work with Python people who dislike Python 3.x, and we are still using mostly 2.7, because everyone feels comfortable with it. The upgrade seems to be a large imposition, with zero gain.


Well, it is understandable. Winds are changing though...

The lack of (enough) incentive for upgrading used to be a good excuse but with 3.8 we are getting a few performance updates that are hard to ignore. Also, many projects in data sciences are dropping support for legacy Python so sooner or later data processing pipelines will have to catch up.

Yes, upgrading is unpleasant, but it is becoming a matter of hygiene.


Given the amount of mojibake I've had to clean out of databases I'd have thought that data scientists would be the first to latch on to sane Unicode handling instead of the willy-nilly string handling inherent with py2.


I would just add that if you’re new to Django read https://simpleisbetterthancomplex.com - there are ton of detailed explanations that go deep in how Django can be extended. It’s definitely not the run of the mill tutorial blog that is only surface level.


Yeah I can't recommend simpleisbetterthancomplex enough for anyone into Django. Great tutorials and articles about many issues you typically run into or just best practices for certain things. The guy who runs it even started a nice community forum that's been very helpful too.


Brilliant blog

Also a fan of these:

https://wsvincent.com/ (and his books are excellent)

https://realpython.com/tutorials/django/


Nice. Anyone building fun stuff using Django these days?


Django is still by far the best web framework as far as I can tell. Every couple years I check what's out there for GoLang, Rust, Nodejs, and Swift, and it seems like it will be a decade or more before anything else comes even close.

Even though a lot of people don't like Django's ORM, at least it does almost everything you would want to do with Postgres. (And if you want more you can always use SqlAlchemy.) Most of the other ecosystems don't even have anything near the baseline functionality built into Django.


I have used both Ruby on Rails and Django in large production web applications over 2+ years. Speaking strictly about the web framework, RoR is the slightly better framework IMHO. This includes but is not limited to:

- cleaner internal APIs, models, methods

- a lot more stuff that "just works" out of the box where you would need a third-party package in Django (e.g. RoR gives you different settings for development/staging/production out of the box)

- better static file handling

- third-party packages tend to be a bit more mature and stable in the RoR world

However, using Django gives you easy access to the rest of the Python ecosystem, including all the data science and ML tooling. And that trade is worth it. So if you are starting from scratch today, i'd go with Django.


Being in a similar position, I wanted to post but your post is spot on. ML and DS have basically lifted Python and by association Django quite a lot...


Have you found a decent Rails counterpart to Django Rest Framework?

As an aside, I love seeing how different frameworks implement the same features.


> better static file handling

Don't you just let nginx/CDN handle these?


I think he’s referring to the app being aware of static files so it can resolve their URLs, etc (without having to hardcode paths).

You develop by just assuming all your static files would be served by Django itself (and they will - using the dev server) and then change the project’s configuration to use a CDN or S3 (using a library - which will automatically collect & upload your files too) with no change to the underlying code.


I think they meant the Sprockets/Asset Pipeline or whatever the new Webpack-based solution is.


Asset Pipelining is a dingo plug-in, but a built in for Rails.


IMO PHP's Laravel is competitive with Django.

I think Django, Laravel, and Rails are really the only 3 frameworks with the levels of ecosystem and built in functionality that these 3 have (unless there's something in Java-land that I'm not aware of). ASP.NET Core is close, but the ecosystem around it is weaker.


I reviewed these sort of web frameworks some time ago and went with ASP.NET Core because of the language attached being more to my liking and industrial-strength than Python, PHP or Ruby. I go in assuming every project will be 500KLOC someday, because it can happen. I've seen codebases this large in Python, and it was no bueno. Static typing, forward migration / backwards compatibility take top priority for me.

Laravel was my 2nd choice, the recent adoption of a JIT into the core really adds some desirability to the space. Not to mention HHVM and how much Wordpress is out there.


But then you’re in Microsoft echo system. No bueno.


Would you mind expanding on this?


People with that mentality aren't rational. If MS offers the best product, which they do for an awful lot of tech, especially once you start valuing integration & support, you should use it. It's actually pretty tough to beat, even if there's guys like that who don't believe in using "best of breed". Using "what you know" is usually best from a developer standpoint, but Microsoft has many best-of-breed products, much to his dismay.


Indeed. And PHP has surprsingly good support for typing these days!

I've been giving C#/Asp.Net Core ago since it's been open sourced. I'm loving C# the langauge, but I wish the ecosystem was as rich as the PHP/JS ecosystems.


Php-wise Symfony is easily on par with Laravel and a really well managed project.


Symfony is more like Java Spring, whereas Laravel feels like a port of Django and Rails. Compared to Laravel, it’s easier to use Symfony to build large applications, but it can feel like overkill for smaller CRUD-only applications. It has a steeper learning curve, so Symfony’s developer pool is more skewed to the senior end.


Why would it be on par? Laravel is built with Symfony. [1]

[1] https://symfony.com/projects/laravel


For Java there's Spring, which is like an entire universe in itself.


I’m quite fond of Phoenix and think it compares favorably with Rails and Django (I’ve never used Laravel).


I think you are missing the elephant in the room: Ruby on Rails.


With Python you get:

- The best-governed language in all of software, and the best-governed web framework

- A huge ecosystem of libraries for everything from data science to email processing, that are (mostly) easy to read and modify and free from systemic security issues. And pretty much every major company with an API has an official Python library for that API.

- The standard language taught at most of the top CS programs around the world

- A web framework that's had almost no major security issues over the 10+ years its been around

What exactly would you get in terms of benefits from switching to Ruby? I'm not saying Ruby or Rails are bad tools, I just don't get why someone who already knew Python and Django would switch.

I get that if you run a dev shop it might be a better choice for just cranking out web apps as fast as possible for clients, but if you run an actual startup I don't see that the benefits of saving a couple lines of code would offset the costs of being locked into the ruby ecosystem.


> - A huge ecosystem of libraries for everything from data science to email processing, that are (mostly) easy to read and modify and free from systemic security issues. And pretty much every major company with an API has an official Python library for that API.

I disagree about this, there's not even a basic user signup flow plugin with page templates that would allow SSO and U2F, it was so when I was looking at it three months ago. With Flask I can use Flask-Security, Flask-Dance and I have user signup, pw resets, SSO. With CSRF protection out-of-box and bunch of other security features are easy to turn on compared to Django. What I did like about Django was the idea and maybe I would've liked Django-Admin if I didn't have to reinvent three wheels out of four.


There was a mailing list discussion about building U2F into Django, and I agree that should get done.

I don't know a ton about SSO, although I'm more skeptical about building it into Django only because there are many different ways you might want the business logic to work, so to me that suggests using a library for that might be more appropriate than having it built into the framework.


There's not even a good 3rd party library, I spent like a day testing all of them out and it's so cumbersome compared to what I had to do with Flask-Security and Flask-Dance.


Fair. I had the same issue a few weeks ago implementing OAuth as a provider. There is a library that is reasonably functional, but the documentation is so bad that if you followed it verbatim there would be huge security holes in your app.


U2F and django was easy last time I have done it. Which was about year ago.


I've spent years using Rails and about a year with Django. In general find Rails to be more logical and less cumbersome. Django feels more cobbled together than Rails, with less cohesiveness.

Sorry that these are fairly abstract statements without examples. I need to start tracking them.


I find this comment interesting because my experience is the exact opposite. (I won't bore you or tempt the trolls with details) I don't mean to downplay your experience at all. My working theory is that you just think the way the rails devs do and I think the way the Django devs do.


Could be. Could be that I have more experience with Rails and used it first. Maybe if I used Django first it'd be the other way around.

For the record I didn't want to do Rails work when I started, and begrudgingly accepted being called a Rails developer only after two years of experience.


Django's documentation is also simply top notch.


> What exactly would you get in terms of benefits from switching to Ruby?

You'd get Ruby on Rails.


Python is much easier to learn and most devs already know it. It fosters quick and simple code that is super easy to maintain, and python/django is a huge and accessible ecosystem.

I don't need to learn a new language I won't use for anything else, I don't need to learn a framework that is not as simple as its proponents describe. I also don't need to learn a new package manager or go digging for gems that do what I need.

If you aren't already invested in ruby, there is very little to gain as a web app developer. It would be a huge waste of time to drop django or flask and learn not only a new framework but also a language that is often described as cumbersome to use.

Ruby on rails might make sense if you already know it, but it makes little sense for anyone else to learn it these days.


Django is my number one, but I think certain languages and the communities behind them - including Go and Rust, for sure, fit much different use-cases than Python/Django and thus there's good reason why you don't find massively popular full-featured web frameworks [for those langs].

Node.JS, on one-hand seems to take the approach of Go-lang - standard libraries that do basic web-handling well, but on the other hand, I think it is tarnished by Javascript's reputation for having too many third-party packages, too many options, new framework every week, etc.

C# / .NET core seems to be a strong up-and-comer alternative for teams looking for a full-featured and well-supported application framework with more type safety and performance than Python/Django or RoR. Elixir / Phoenix, as well, but that caters to an entirely different crowd.

I expect most Go users are not using much in the way of frameworks.


Symfony is a great php framework too


I have been leaning on Django a lot in the past couple of years. A couple of highpoints

Everyone talks about the admin. Yes it is nice, but the real core for me is a sensible way to map URLS to queries. I have taken the filtering and sorting of the admin, and extended it to output dataframes. From there I can take the same admin url, change one part and instead get a csv to download, or a matplotlib plot.

The Django ORM is cumbersome to use for complex queries, especially aggregations. I get around this by writing views that I want to express the aggregations that I want, then putting a model on top of the view. From there I can get easy access to the aggregations through a simple foreign key.

When using Django, I often think "there's a lot of convention around doing this simple thing" or "why did they engineer something this odd way". Then I use Flask and I have to poorly reinvent something that Django has already thought of.


The WorkFlowy (https://www.workflowy.com) backend runs on Django. We are on Django 2.1 and planning to upgrade to 2.2 now that it has been released.

One new feature I’m excited about is bulk_update: https://docs.djangoproject.com/en/2.2/ref/models/querysets/#...


I'm excited about that feature as well. It was possible to do bulk updates before, but it was cumbersome. With this new method, it will be super simple.


I've built a bunch of stuff using Django, but my most recent project allows people who play the game ClashRoyale to see if they have played against a streamer on Twitch. If they have, they can view the video directly at the moment their game is shown.

http://playedwith.io

(click "latest games" to see how it works)

Im a big fan of django, and have used it for several projects. Using rest-framework allows you also to make powerful apis, and SPA front ends like Vue or React. It's ORM is also a very user friendly (though aggregations are definitely a pain).

I consistently come back due to the great docs, and the ease of use. Being python based means you can integrate a lot of libraries, especially if you are doing any kind of data science related stuff. Websockets and real time stuff can be cumbersome from my experience, and for that I would stick to node. It's possible to use django-channels but I had a very mixed experience trying this.


cool, do you grab a screenshot off the twitch stream then use character recognition on the UserName/Id to identify them?

I see the esports gaming area exploding over the next 10 years as most people are gaming now instead of other activities.


That was the original plan but it was waaaay to unreliable. The current system is pretty simple as you can synchronize the timestamps of streamers games (I know their Id's!) and their twitch streams.

I use django-background-tasks to run an ETL job every 20 mins that does the matching.


I recently got back into it after many years on flask. Free admin, user accounts, and rest API (django-rest-framework) makes building things so quick and enjoyable.


I’m building my first product that has actually made money and shows signs of real potential in Django. I’m about 3 years into it.

It is growing just among beta customers. Hope to do a release in next month or so. Will post a Show HN.

I also have a client I develop for on a private web app in Django that does a lot of cool stuff w on the fly cloud compute instantiation.

I really like Django and have been hanging out in the #django on freenode.


Me for like 7-8 years. Just building boring intranet apps (some are CRUD, some have a little workflow but nothing too complex) for a public sector organization with only a light touch of JS (some Jquery if needed) and everything else Django request + response.

It may seem boring but it is the most productive setup I've ever experienced; I don't think that there's anything more powerful for such things (except maybe some IDEs like PowerBuilder however I think that these are way too niche on their capabilities; they may be fast and easy to create the thing that they know how to create but god help you if you need to create something more complicated; Django on the other hand is a general purpose framework; whatever you throw at it it will happily eat)



The article was almost 3 years old now. I wonder what they've changed since then


I’m building a tool that will require recruiters pay technical people to speak with them about a job.

http://www.joinjune.com


We built rationalpilot.com using Django, postgres and pandas. I love staying python native and really like Postgres support for the json model field in Django.


We work with a bunch of interesting clients all using Django. Most recently we helped upgrade Politifact.com (https://www.politifact.com/) to a recent Django version, cleaned up a bunch of legacy cruft, and added decent test coverage. We also drastically reduced their infrastructure costs by better utilizing CDNs and caching.


Definitely.

Most of my projects starts with Django. Quick to build quick to test the idea. And because they never grow to 10k concurrent users no need for more scalable solution.


If you want fun and aren't afraid of some AWS, I highly recommend Zappa: https://github.com/Miserlou/zappa

It's an amazing little piece of software, I am gobsmacked by how complete it is.



I'm building an open nuclear reactor lessons learned database where old retirees and current researchers can collect the design/operation/decommissioning lessons learned through the years and share references and knowledge.


The web bits of our ML platform at https://valohai.com/ are Django through and through.


Almost anything, for me is like the only one-to-go that hits all the most important things for a project.


Me! Have been for over 10 years. Still chugging away. :)


Our whole web stack and api, 5 separate domains.


yeah! We use it at https://www.hungryroot.com/ We use Django 2.0


Django is awesome. It is a model Open Source project that everyone should emulate. I have used it in the past and it can make you hyper-productive especially if you're prototyping stuff.


We're a Django shop and it's a pleasure to work with (most of the time). Happy to see a 2.2 LTS release, that should light the fire under some teams to upgrade


I've been away from Django for a few years, and hope to come back one day.

One thing I'm curious about, coming from well-typed JS codebases using Flow, is the quality of typings in major projects like Django, Pandas, etc. Are their APIs well-typed? Can I get quality types for my models?


The PyCharm IDE has extra support for Django to enable some additional type inference, and it works like an absolute (pun intended) charm.

Beyond that, the Django core isn't type-annotated yet likely because of Python version support, but I'm sure you can get typeshed pyis or something.


There's a discussion on the mailing list about this, last updated a few months ago: https://groups.google.com/forum/#!topic/django-developers/tr...


With Pandas, typically the important data types are the series data type for columns in a DataFrame or what not. Which Python will infer when you read in the data, or manually construct. These are data types provided by the Numpy library. And you can manually convert columns as needed with Pandas functions.

If you mean the object itself, then Python is strongly typed and will throw an error if you try to run the wrong method or access the wrong property on an object (although it will let you assign new ones, and it will let you add new columns to DataFrames of any data type, because that's very useful).

If you mean in the method or function calls, then often a parameter will allow different types because you might want to pass in the column name, a list of columns, a function or something else that makes sense for that particular parameter depending on what the method/function does. Pandas has a lot of overloaded parameters because it's a big library that covers a lot of use cases for tabular data.


Sorry, I meant static types, like mypy


Right, my point was that static typing doesn't seem like a good fit for a library like Pandas, which needs to be flexible enough to handle a wide range of use cases for tabular data where you're cleaning, reshaping, etc. At least not without a total rewrite.

With Flow in JS, how would a JSON library for similar purposes work where you don't know what kind of data it will be and you will be doing a lot of transformations on it?


I think designing for static types changes the design of a library’s api. So, in this case, Pandas would likely have to evolve (handwave) in some fashion, if it were to support Mypy types.

One way Mypy could help do this is by implementing a feature like Type Providers https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/typ...


If you _really_ don't know what type of data you have, you type it as `mixed`. But if you _do_ know the shape of your data, you write your own types, and tell the library about those types (eg; with generics). Think like `my_df: DataFrame<MyDataShape> = pandas.DataFrame(my_data)` where you manually define the shape of `MyDataShape`.

Scala is a language that is often used for data processing, and is statically typed.

Depending on the situation, codegen can also be useful in these situations, eg; https://github.com/typeorm/typeorm

EDIT: in any case, this certainly answers my question :-) sounds like they're not there yet, and perhaps not even moving in that direction yet.


I really hope Django can provide some front-end integration like Rails Webpacker or Phoenix does. Setting up a smooth SPA and proxy is such a grunt work which always something holds me back when I trying to set up a small project with Django.


I'm a fan of Django, but I'm in doubt if I must still use it for my new project. I'll develop now an hybrid app that will start life as an mobile web site. I'll use one javascript framework and I'm really in doubt about using Django.

If I use a javascript server framework, I believe that it will prevent me to duplicate forms validation code (in server in frontend) and also easier for SSR (Server Side Rendering). But Django is a robust framework, in my beloved Python language, why should I still use it?


IMHO, code sharing between the frontend and backend is very hard to do properly and you have more changes of making stuff too generic and unmaintanable faster. KISS

As any new project, go with you're most comfortable with, so you can prototype and changes things faster. After you reach a good size and understanding of the problem you may refactor stuff for a different language/framework with better reasons for it.

That being said, if you want to use Python but not a "batteries included" framework like Django, so you have better control of the stack, check out Pyramid, it is really good and scales (I'm talking on code maintainability, but also performance-wise) very well from pet-project phase to complex applications.


A person can use Transcrypt[1] to transpile quite a bit of Python to JavaScript.

As a proof-of-concept, I put together a Django plugin[2] that uses Django's validators[3] along with Transcrypt to share validation logic between the server and a `ModelForm`.

I thought it was a neat way to centralize validation logic.

[1] http://www.transcrypt.org/

[2] https://github.com/johnfraney/django-front-end-validators

[3] https://docs.djangoproject.com/en/2.2/ref/validators/


You're probably going to define those validations in different ways. The frontend gets data from the UI one field at the time, the back end gets them from a JSON all together. Then they react in different ways.


I've used Django for 5 years, but never used it to serve the front-end client. I just use Django Rest Framework (DRF) with React on the front-end or Qt on mobile and desktop. Django is only the database REST interface and the client is either a binary or served over nginx.


Django is a magnificent piece of software.

I'm an experienced ReactJS developer and I discovered Django after ReactJS and I am finding myself developing new projects not with React but just with plain Django/JavaScript/HTML. That's because of the nature of my projects of course which are simple crud applications, but the point is that for simple applications, Django makes things incredibly easy and fast and importantly, easy to understand.

More sophisticated user interfaces I would definitely build in React of course.


That's the real power of Django for me: Good ol' HTML based apps (with a little salt of jquery when needed) using the tools that Django (and friendly projects) generously offer to create Angels in a fraction of the time you'd need with anything else!


I'm coming from a systems and desktop background and looking into a web side project. My only experience with backend frameworks is a few months with Django for a small project at work.

Is Django still a thriving development community? And is it able to handle a large amount of concurrent users? Basically is it a good choice for a backend for a new project? The web tech world moves really fast, and I like that Django has been around for years but wondering if it's still a good option.


I have an assortment of Django and flask-based websites and Django still works fine for new projects from my perspective, with the normal caveat that it really depends on what you want to do with it. If i had to redo some of my projects I'd probably use the Django rest framework more heavily as I ended up duplicating a lot of that functionality writing Ajax endpoints way back in the day, but I've not encountered issues where Django is the bottleneck in the system. Usually the bottleneck is a poorly optimised database index or something, which Django handles fine to a point.

however, since I've ended up utilizing SQLalchemy and Pandas in a lot of my projects I have since tended to use Flask+SQLalchemy a lot more so my old fuzzy brain doesn't have to try and remember the variations between two different ORM syntaxes.


Thanks, I appreciate the info.


Awesome ! we at Careers360 (India top 100 Alexa) use Django for everything, the best thing about an Opinionated stack like django is freshers are production ready at day 1, learning time reduces and maintainability is solid , although i prefer golang where frameworks are particularly not favored ,Django ORM surely lacks a lot of features but does a decent job, async story sucks unless you are willing to give in to Channels i hope Django embraces async officially in the core


I believe I had interviewed once at careers360 a couple of years back, don't think it was mentioned to me then that you guys work majorly on Django otherwise I think I would have had a better chance at clearing it lol... But yeah Django is awesome, It has paid my bills for years. Hopefully async will come in relatively soon with Andrew Godwin's focus on it.


[flagged]


As questionable as that PR may be, it's hardly enough to justify outright dismissing one of the most successful web frameworks out there.

But at the end of the day, the choice is yours to make and it's simply your loss.


I tend to invest in people / companies rather than a technology. There are an abundance of good web frameworks out there so it's not like you're gonna have a bad time just because you don't use a specific one.


The people behind Django are one of the sharpest set of developers out there. Just hang out the django-developers mailing list for a bit and you'll likely conclude the same. Don't let this one PR color your entire judgement of an otherwise incredibly successful and polished piece of software.

https://groups.google.com/forum/#!forum/django-developers


> The people behind Django are one of the sharpest set of developers out there.

That may be, but it doesn't really matter to me if they put their political views into their code. It can literally be the best framework out there, built by the sharpest minds in the world and I would still use another framework even if it would hurt me economically.


Deciding to accept the status quo is also a political decision reflective of one’s political views. The issue here is that you don’t agree with this particular view, not that it is a political view.


Yes of course. I do not want others political views forced upon me. Just as I wouldn't want others religion force upon me. I would be as opposed to this change if it was 'god'/'disciples' or something similar.

I also think there would be more people like me if that were the case. But just because it's a popular opinion everyone lashes on my 'irrational' behavior. I don't think it's that irrational though.


Living in society today involves having others' political views forced on me every day, in the form of "you should accept the status quo and not speak up about it". Many people just don't understand this because the status quo is fine for them.


> Living in society today involves having others' political views forced on me every day

Yes to some extent. Most secular and democratic societies has agreed to a standard that I defend. Call it status quo if you want. I think decisions like Djangos goes against that standard and is probably why I feel so strongly about this. They want to police speech and force everyone to use specific words.

I don't think we should police speech but there is a lot of people that are pushing for censorship and making some speech illegal today and I simply defend the usage of the words master and slave. I don't think there is anything political about it and they are not racially charged since masters and slaves has occurred in basically all societies through time. Banning the words because of american politics is absurd. I hate the modern american politics, I am not an american and I do not want it in my life.

By doing this, Django forces everyone to think about this and you have to be extremely sensitive if this is what you go around and think/worry about. What else will they do in the future? Ban people from using Django for certain stuff etc? Surely it would be forked etc, but forks rarely works out great in the long run.


> Most secular and democratic societies has agreed to a standard that I defend.

Cool. But that’s your politics, and not necessarily everybody’s, and to have a different political position from you is not inherently morally wrong. We could argue about whether or not the status quo is fine, but that’s not the point - the point is simply that taking the status quo as acceptable is a political position which you’re subjecting others to, and your defence of it to the point of refusing to use software that does not back the status quo doubly so.

Or, in other words, you’re not for getting politics out of software - you’re for getting politics that you don’t agree with out of software.


> Or, in other words, you’re not for getting politics out of software - you’re for getting politics that you don’t agree with out of software.

Well yes, but I would be okay with the same being applied against me. Of course some basic level of politics is necessary (like licenses) if you want to count that as politics.

I won't go and put taxation politics, immigration politics or any other specific politic matters into my code or EULA. I expect this of other software as well. I don't want any unnecessary politics in the software when there clearly is no reason for it.


It feels to me, that people don't realize that there are probably a lot more people out there who speak English not as their first language, hence they don't have the same connotations of many words as the native speakers.

When I hear Django for example, first thing I think of is the slave from the "Django Unchained" Tarantino movie (or Django Reinhardt, the gypsy musician)...

Maybe this web framework shouldn't name itself after such a famous slave!...

Or from another point of view:

What a dick move was it from Tarantino to name his slave protagonist after such a popular web framework, which tries to be respectful, by avoiding references to slaves.

Also, I'm very much interested in the comment which sparked this thread.

I find it quite freaky, in a 1984-ish way, that it is completely inaccessible now.

What's next, flagging-people? Burning books is just a few steps away... You are a bit too trigger happy, maybe...


> or Django Reinhardt, the gypsy musician

Well, that's precisely who the framework is named after...

https://docs.djangoproject.com/en/2.1/faq/general/#what-does...


I linked to the now infamous Django PR that removes the words "slave" and "master" and said I stopped using django since then (after writing it is a great framework).


Then you're letting yourself be hurt by your political views.

The Django developers try to include the absolutely widest range of people they can. But if that makes people decide to exclude themselves, that's not Django's problem IMO.


Well yes, maybe. Maybe not.

I think this is not about inclusion though, this is about exclusion of people who think like me.


really? which operating system are you on? if you didn't write it yourself then it's not apolitical.

https://en.wikipedia.org/wiki/The_personal_is_political


Do you not use anything from the GNU project because of their politics?


What politics do they enforce on me by using their products?


Free software is a political movement. Calling it “free” was a political choice to convince people that proprietary software is “unfree”. I really don’t know where to begin explaining this...


Well yes, but they are not policing speech as far as I know. I have nothing against people/projects being political, it's when a specific political view that I do not agree with gets enforced upon me that the issue arises.


Companies and institutions have every right to define what is acceptable speech in their own universes

And freedom of speech isn't an absolute right – not even in the U.S., but even less so in pretty much any other advanced Western democracy.


I feel the exact same way about Rust for what it's worth. Turned me off the language completely.


Why do you feel this way about Rust? Glad to hear I'm not alone anyway ;)


You’re right, it is very silly of you. I might even say you’re the one being over sensitive.


[flagged]


It’s probably not helping that the username is “ecmascript” on a python post.

When I first started getting into database I found the terminology a little jarring. I know it’s common and the intention is ok, still not a big fan.

But the python community should be ok with renaming things: frankly Lists are just arrays and dictionary’s are hash tables


Why do you feel the need to attack him? It's not as if he has attacked you personally.


i don't understand the bipolar nature of hn.

"don't be afraid to be intellectually honest and say what needs to be said - we're not afraid of hurting people's feelings for the greater good and we're proud of it"

and at the same time

"be careful you don't say anything that could in the slightest be misinterpreted as impugning someone's character"

i feel like i'm taking crazy pills? this is exactly the kind of thing that Nietzsche talked about in geneaology of morals: people in this "community" claim to be above petty politics and egalitarian but as soon as anyone points out anything that even remotely contradicts that image they get silenced or shouted down (e.g. bringing up race or gender politics and their role in the entrepreneur mythology).

it's completely within the scope of productive discourse to point out to someone that they're being irrational because no discourse can proceed until a rational framework is established. case in point: a rational discussion of the merits of django cannot begin from "i'm prejudiced against them because they made questionable PR choices".

honestly there are so few useful discussions on hn. the tech posts are either PR for yc companies or another js vdom framework and the culture posts are all mostly rehashings of the same neoliberal arguments for capital and culture etc. the few people that try to inject any heterogeneity of thought get vilified.


HN isn't a person, it's a distribution of millions of people. If you think of it as a statistical cloud, it won't seem so paradoxical (e.g. "bipolar").

I don't follow your reference to Nietzsche but if it's relevant here, the same point would surely apply to any group. I try not to lose too much sleep over problems with HN that stem from human nature and social dynamics in general. It's hard enough to change the few things we can.


>HN isn't a person, it's a distribution of millions of people.

is obvious. what is insidious is the ideology that is preached on almost every controversial thread that papers over that fact.


That perception usually seems to be more related to the strength of one's own ideological commitment than to the actual state of the threads. People on each side perceive the community to be biased, and people who are intensely on one side perceive the community to be extremely biased.

https://hn.algolia.com/?query=%22hostile%20media%20effect%22...


i'm not going to do a study of the culture of hn because i am not an anthropologist but i have many times responded to comments that were vile, that broke the rules, that did not get flagged because they toed the party line, that were in effect supported by the community

https://news.ycombinator.com/item?id=17032257

a selectively enforced set of laws becomes defacto discriminatory and ideological: https://scholarship.law.duke.edu/cgi/viewcontent.cgi?article...


Exactly, my comment was mild compared to the highly upvoted and ridiculous top comment you linked.


If you want to point out that something is irrational for a better discussion framework, you better prove it first. Otherwise it's just noise. Saying someone is silly and overly sensitive without giving him further information is like saying you are wrong without proof, with the insult on top.


Thanks, I hadn't seen this it's amazing. It's off topic but interesting enough not to mind. It set me on a train of thought about whether github is accidentally dystopic => permanent, completely public record of everything you say or do (inside the platform), conditions that probably magnify the power of social victimizing. PRs are permanent, I don't know about the discussions/etc, they can be deleted? Whilst being also a public record of your work/skills, so you can't really opt out or anonymize without a significant penalty.


Well yes, I don't mind that they have a different world view than me. What I do mind is when people enforce their world views upon me.

I always opt out if possibly in those scenarios, just as I did with Django. I stopped using it and now I have nothing that runs Django anymore.


I didn’t like the naming changes and thought it was just a feel good platitude, but it was hardly something I dwelled on. What world view was forced on you, though?


Why Django is not good, here are some of my reasons as far as I can remember:

1. mediocre routing (no nesting, all routes have to be declared in one place)

2. mediocre middleware (middleware is global)

3. mediocre ORM (easy only for very easy stuff, more pain in the ass than writing raw SQL itself when it comes to complex aggregations and joins) not to mention some of the famous ORM bugs that have been open for like a decade

4. custom user model? good luck fighting with Django errors to make that happen

5. custom authentication? external authentication? want a custom token format? want your authentication token in a custom http header? good luck

6. Django is built for 2000s websites not REST/gRPC era

7. want to use graph databases? noSQL? good luck

8. external migration for SQL? oh god, prepare yourself for the mental hell

9. Django as far as I can tell still ONLY supports decoding "x-www-form-urlencoded" bodies, yeah no JSON, it's that pathetic


A lot of these are pretty inaccurate, at least for modern Django.

1. I'm pretty sure that's not true if I'm correctly interpreting what you mean...You can do things like `path('myapp/', include(myapp.urls))`

4. Custom User models are now very straightforward (and recommended for non-trivial projects since it's easier to start with a Custom model that defaults to the default model for all options then modify it later)[1]

5. All these things are fairly straightforward and libraries like Django-Auth/Django-Rest-Auth cover a huge set of the normal use cases (OAuth, JWT, tokens, etc.)

6. Django Rest Framework is a best-in-class solution for Rest APIs

9. See 6.

[1] https://wsvincent.com/django-custom-user-model-tutorial/


Also #7, "want to use graph databases? noSQL? good luck" Is incorrect. How do I know? I've built a non-trivial Django app with a Neo4J backend. It included an API using Django REST framework. There are some parts of Django that are tied to the ORM, mainly the admin and some generic views. But you can certainly use Django without those pieces.


>A lot of these are pretty inaccurate, at least for modern Django.

I wish you state exactly which of them are inaccurate and why, I sincerely want to know and understand

>1. I'm pretty sure that's not true...You can do things like `path('myapp/', include(myapp.urls))`

so you suggest I create an "app" for every sub-route? every major and non major web framework except Django has a router where you can mount it to any parent and mount any child to it

>4. Custom User models are now very straightforward (and recommended for non-trivial projects since it's easier to start with a Custom model that defaults to the default model for all options then modify it later)[1]

maybe you're right IFF you start using a custom user model from the very beginning, if you happen to forget that, Django will make your life like a hell and will refuse to even pass startup checkups

>5. All these things are fairly straightforward and libraries like Django-Auth cover a huge set of the normal use cases.

I mean authentication tokens not Django's authentication (e.g. signin, signup)

>6. Django Rest Framework is a best-in-class solution for Rest APIs

so you suggest people throw their codebase and start rewriting for DRF?

>9. See 6.

so you suggest I rewrite my applications to DRF just to have JSON http request decoding?


> maybe you're right IFF you start using a custom user model from the very beginning, if you happen to forget that, Django will make your life like a hell and will refuse to even pass startup checkups

The startup checks are protecting you from more subtle problems because if you switch to a custom model, you need to do a migration for your stored data. That's a one-time process which can be squashed as soon as you migrate the last server running the old code.

> so you suggest I rewrite my applications to DRF just to have JSON http request decoding?

DRF is a helpful tool which solves a number of common cases but it's not doing anything you can't do in standard Django: that could be as simple as json.loads(request.body) in the appropriate view or, more commonly, a decorator or class-based view which provides standardized error handling, etc.

The reason why the stock forms API doesn't do this by default is that it's designed to support the <form> interface in the HTML standard, which defines a simple key-value interface which is much simpler than what can be expressed in JSON:

https://html.spec.whatwg.org/multipage/form-control-infrastr...

Once you're moving out of the realm of standard browser interfaces it's much harder to write a generic validation interface suitable for having in a standard library, especially since there are multiple competing ideas of what this should look like and most of them are easily installable from PyPI without the Django project having to support them.


Most of your notes are accurate, especially about the difficulty in bringing an old app up to speed. A legacy Django app has very different requirements from someone choosing a framework today.

For 1 it doesn't need to be an app, I just gave that example for clarity. You can include any set of urls (and can create nesting within your app if you desire). Of course, the Django folks would probably suggest that if you have so many urls that it becomes cumbersome, perhaps your app should be broken up.

6. You can DRF for individual routes and regular Django for others.


Barely anything worth responding to here, but come on...

Django is probably the easiest ORM to use. It's powerful and extendible, and it is in line with Django's "batteries included" philosophy, so, for example, it requires a single-attribute primary key. That doesn't mean that you can't do composite keys; it's just that you need a surrogate. It also has very good API for custom functions and aggregates, meaning you can quickly add support for vendor-specific features, and also offers very good raw SQL support, where it will handle handle the mapping on your behalf, which is the most tiresome of boilerplate.


1. You can nest routes, see [1].

3. You can do arbitrary SQLs through the ORM. You can also do arbitrary SQLs with whatever joins you like and still get a model back. See [2].

4. This hasn't been an issue for some time. See [3] for how to extend and [4] how to substitute with your custom model.

5. There are libraries supporting relevant oauth providers [5] and libraries for specific protocols like ldap [6]. These are drop-in libraries that needs only basic configuration. It's also quite simple to build a custom authentication system, using whichever http header you fancy.

6. While this is somewhat true, it's not fair. There are libraries for many purposes. django-rest-framework [7] is an exceptionally good framework for creating ReST APIs.

7. There's nothing stopping you from using any other database, neither graph nor nosql.

8. Django's migration support is extremely good. If you dislike the ORM and you also want to use an external migration tool, you can easily enough just omit using models and utilize sqlalchemy instead.

[1] https://docs.djangoproject.com/en/2.2/topics/http/urls/#incl...

[2] https://docs.djangoproject.com/en/2.2/topics/db/sql/

[3] https://docs.djangoproject.com/en/2.2/topics/auth/customizin...

[4] https://docs.djangoproject.com/en/2.2/topics/auth/customizin...

[5] https://python-social-auth-docs.readthedocs.io/en/latest/con...

[6] https://django-auth-ldap.readthedocs.io/en/latest/

[7] https://www.django-rest-framework.org/


> 1. mediocre routing (no nesting, all routes have to be declared in one place)

In reality these can be multiple places, however not really nested. There is the main routing file, which can move resolving a url to another file.

> 2. mediocre middleware (middleware is global)

Isn't it how it should work? The middleware is something your want always run for the request.

> 3. mediocre ORM (easy only for very easy stuff, more pain in the ass than writing raw SQL itself when it comes to complex aggregations and joins) not to mention some of the famous ORM bugs that have been open for like a decade

Not really. On the other hand I always prefer SQL... but using SQL in the Django ORM and pushing the results into Django model classes is simple.

> 4. custom user model? good luck fighting with Django errors to make that happen

Done that a couple of times... https://docs.djangoproject.com/en/2.1/topics/auth/customizin...

> 5. custom authentication? external authentication? good luck

No luck needed: https://docs.djangoproject.com/en/2.1/topics/auth/customizin...

> 6. Django is built for 2000s websites not REST/gRPC era

True, that's why we have e.g. this https://www.django-rest-framework.org/

> 7. want to use graph databases? noSQL? good luck

Yup. I'm using SQL and I'm with it. Graph databases are cool for some specific problems, you can also use the core Django models and store some more stuff in the graph database. As for all the noSQL mess, well, it's usually a mess with thousands if programs running just to clean the data, and almost nobody cares about the correctness of the data model, thank you, I'd rather stay with the good old SQL.

> 8. external migration for SQL? oh god, prepare yourself for the mental hell

I'm not sure I can see a problem here... but I'm half-dba, half-programmer, half-dragon... so maybe that's why.

> 9. Django as far as I can tell still ONLY supports decoding "x-www-form-urlencoded" bodies, yeah no JSON, it's that pathetic

I'm sure I was using json with django without any problems in both directions. But you know, I'm different.

Yep, Python has lots of problems, and I'm not sure I like it (especially after moving to Kotlin for 97.49% of the code). However, if you stay with Python, I'd recommend Django :)


Whenever I see people still praising Django in 2019, I immediately know that their technical understanding of the current backend and ops technologies is years behind. Django is still okay for small and amateur projects but nothing more than that. It is a curse for a fast moving business.

EDIT: even though I stopped writing Django for 3 years now but here are some of my reasons as far as I can remember:

1. mediocre routing (no nesting, all routes have to be declared in one place)

2. mediocre middleware (middleware is global)

3. mediocre ORM (easy only for very easy stuff, more pain in the ass than writing raw SQL itself when it comes to complex aggregations and joins) not to mention some of the famous ORM bugs that have been open for like a decade

4. custom user model? good luck fighting with Django errors to make that happen

5. custom authentication? external authentication? good luck

6. Django is built for 2000s websites not REST/gRPC era

7. want to use graph databases? noSQL? good luck

8. external migration for SQL? oh god, prepare yourself for the mental hell

9. Django as far as I can tell still ONLY supports decoding "x-www-form-urlencoded" bodies, yeah no JSON, it's that pathetic

Django is very intrusive and is pain in the ass in a fast moving environment where you want to use microservices, external authentication/authorization, APIs, gRPC, etc... that's excluding all problems of Python itself. I totally recommend Typescript/Express or Golang for doing any kind of non trivial backend with fast moving environment/requirements currently

acdha 86 days ago [flagged]

No need to troll if you don't like it — move along and don't waste everyone else's time waving your ignorance around so proudly.


[flagged]

acdha 86 days ago [flagged]

Feel free to substantiate your claims. Even after your edit it's just a bunch of big claims with no supporting evidence for the things which aren't simply wrong (e.g. “no nesting, all routes have to be declared in one place” sounds like you haven't ever used a Django app, including the built-in ones. Perhaps there's something else you have in mind but since you didn't explain, who else can tell?).

Lobbing insults won't hide the fact that you aren't even trying to make a technical argument or otherwise contribute in any way to the discussion:

> Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents.

> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

https://news.ycombinator.com/newsguidelines.html


[flagged]


Could you please stop? Flamewars are just what we're trying to avoid on HN. When accounts behave like this we eventually have to ban them.

https://news.ycombinator.com/newsguidelines.html


I am not trying to start any flamewar, I am just stating why Django is not good imo, simple as that


I believe that you started out that way. The problem with that first comment was that you began with an insult ("I immediately know that their technical understanding of the current backend and ops technologies is years behind"), which provokes people rather than informing them. Also, your comment included name-calling, which the site guidelines ask you not to do. Could you please review https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here?

After that, you followed up with personal attacks and incivility. That's definitely flamewar. You weren't the only one doing it, but that doesn't make it ok.


[deleted]


Please stop also. Flamewar is not what we want here, and https://news.ycombinator.com/item?id=19545921 was as much a violation of the site guidelines as the comments you're criticizing.

If someone is wrong, provide correct information and move on. If a comment breaks the guidelines, flag it and move on. In egregious cases, you're welcome to email us at hn@ycombinator.com. But please don't respond in kind or perpetuate spats.


Sorry about that — I deleted my last comment before your reply for the same rationale rather than wasting more time on a thread started in bad faith.


This post is very antagonistic but I can say that point 3 rings very true, even using advanced/data heavy SQL got very annoying for me relative to SQLAlchemy and I don't think you really want to try and pull it out.


It's been a while since I've used SqlAlechmy, but I remember absolutely hating it. Like you said, Django's ORM fails above very simple manipulation and even though SqlAlchemy might be better, it was still awful. I found it better to just write raw sql for my few use cases than to dive into page after page of sqlalchemy documentation.


I second to this, SQLAlchemy was nicer to use when my data model wasn't super simple and used PostgreSQL specific features.


Would you mind sharing some more precise reasoning with regards to this statement?


Don’t bother, the poster doesn’t follow up his/her posts with any information backing up their statements or claims.


As opposed to?


You guys hate, but he is right and you know it. In year heart you feel this call, this.. twinge. You know this is not the True Path.

I've done it both. Our Go + Angular project slaughtered Django and now I was dealing with services running at 25MB RAM with single digit CPU usages instead of the disgusting gluttons that Python and Ruby produces with memory usage measured in GBs. Production servers can have specs rivalling Raspberry PIs instead of IBM Blue Genes. Quite refreshing.

The illusion of power that Django (and all fat frameworks) create works OK if you work with a narrow set of very specific web applications in a static environment with a team of Django specialists. Anything else and the project turns to shit.




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

Search: