Hacker News new | comments | ask | show | jobs | submit login
Django 2.1 released (djangoproject.com)
307 points by parvenu74 6 months ago | hide | past | web | favorite | 125 comments



For anyone thinking about picking up Django and is worried about the framework being obsolete I encourage you to take a look.

Django is fantastic. I've worked with it for a number of years now and it can really help in the early stages of prototyping.

Things I especially like about Django:

* The built in admin letting you edit and view objects easily.

* Being able to use it without using the views. Add django rest framework and you can model your domain with good REST practices.

* Migrations and works well with postgres.

* That the team has thought a lot about web security and how to implement it. Things like XSS, CSRF, CORS, session timeouts, authentication are all there in Django. Other frameworks I need to pull in a library for each and pray that they work well together. I found this especially with Flask and large projects it gets ridiculous how much I have to write from scratch.

Things that would make me not choose Django:

* If you have a graph style problem and need a graph database like neo4j. (Even then I'd probably want some part relational)

* If you accept lock in to someone else's platform like firebase and don't want to run your own servers.

* raw speed is an issue and you are okay with development taking much longer. In that case you're looking at some of the golang frameworks and possibly node/express.


A huge reason some people consider frameworks like Django obsolete is because they are focused on an older web paradigm of constructing elaborate html pages on the server side and pushing it out and letting some basic extra js stuff augment it.

That's what lead to things like server side HTML form definition and form handling code.

After the emergence of things like React, Angular, etc those "html templating" facilities get in the way because that stuff is baked into the react app and is focused on the client side, it may get server side rendered with nodejs. A modern fancy web application using React in 2018 doesn't need something like Django forms or Flask-WTF and those types of things conflict and overlap with things like React.

The backend is turning more into a data/API/GraphQL service than "get html" service that was popular when these frameworks emerged.


> an older web paradigm of constructing elaborate html pages on the server side and pushing it out and letting some basic extra js stuff augment it.

Sounds like an awesome idea.

> That's what lead to things like server side HTML form definition and form handling code.

You make these sound like bad things.

> those types of things conflict and overlap with things like React

So why presume the thing to abandon isn't React for many use cases?

> The backend is turning more into a data/API/GraphQL service than "get html" service that was popular when these frameworks emerged.

Which is fine if you're building a complex web app but stop encouraging people to build content sites this way. It's a terrible idea and they usually have deep UX flaws due to incomplete attempts to rebuild functionality that you get for free if you stop reinventing the wheel.

50% of the sites I visit seem to break some subtle aspect of bookmarking, navigation, caching, reloading or something else that they have no business messing with.


Yes! There are an awful lot of web sites out there--including the one we're on right now--which are, well, web sites, not web apps.

I have a strong suspicion this conflation comes from reasoning kind of like this:

(1) My web site would benefit from some kind of API. (2) Hey, if it has an API, wouldn't it be simpler if it just had an API, and all interaction was through clients? (3) So, [insert JavaScript framework] to the rescue! It'll be just like the original web site, but better!

Except that it isn't automatically "better" for either performance or usability. Content-focused sites tend to perform very well using the server-side model.


The world needs more people like you. Thank you.

I have a very varied workload which includes both complex web applications and content driven sites (very basic, accomplishable-by-WordPress marketing sites). I had a client move their very basic portfolio + blog site to a new developer who rewrote it from scratch. The new site has a loading / splash page before the real site displays. It's entirely JS driven and ticks all the boxes for bad implementation (badly implemented fake links, no use of the history API, bad accessibility.etc).

I don't see how this is not a step backwards. Nothing was gained here except for some resume-driven development. Frankly, it strikes me as something that inexperienced developers do because they aren't aware of a world outside of React (or at the very least consider it to be obsolete).


What we have is basically worse than flash. At least nothing serious except video was strictly dependent on Flash.


It seems you are confusing (conflating?) web pages with web app.

>...constructing elaborate html pages on the server side and pushing it out and letting some basic extra js stuff augment it.

I will take server side rendered webpage up against a fancy js spewed template any day of the week. In every metric possible the server side render wins.

Load speed, SEO, accessibility, file size, time to paint, time to render, time to interactivity. Not a single point goes towards the js rendered web page, period.

In fact, it has almost every conceivable downside, including the obvious, it requires javascript.

I develop webapps for a living, and I hate using them for browsing content, they suck for that. Vue.js/React/Angular for web apps all the way, for web pages/content, server side hands React its behind.


Not true. django-rest-framework is so well adopted and widespread and it lets you very quickly put together a REST service. If you just want to talk json/xml/whatever with your client, it is easy. But the really cool thing about DRF is how it simply generalizes some of the concepts that already existed in in Django. If you started in Django and learned about Form and ModelForm, you can easily pick up DRF Serializers and ModelSerializers to get input validation.

With django channels, you can also very easily break away from wsgi and have real time services, web sockets, all talking with your Django code.

There is no "focus on older web paradigms". Django may have been slower to get things that other shiny JS frameworks already have, but this is only because Django had already successfully been used in projects of different sizes and it could not succumb to CADT.


>it could not succumb to CADT.

I had to look up CADT.

Got this via Google:

CADT stands for Cascade of Attention-Deficit Teenagers


I love it.


You are not required to use Django's templating engine. It works great with React, Vue, Angular, etc. if you use Django Rest Framework as the intermediary.


Yeah this seems to be the key point that is confused.


> because they are focused on an older web paradigm

Which usually is faster and easier to use.

> A modern fancy web application using React in 2018

Takes ages to load and melts your CPU.


One wonders if the web would be a better place if developers used machines and networks slower than their users'.


Definitely. Often adding more hardware is justified because developer time is more valuable, but if you're wasting the time or resources of thousands of users, it shouldn't be acceptable.


Heh well I'm trying to explain my customers that the load times I'm experiencing could be similar to their users and might be a problem. One of the advantages of being a remote developer with a pedestrian SDSL connection.


Django REST framework (1) gives you the best of django + a RESTful API really, and is just another `pip install` and a few lines added to settings file.

You still have some of the same performance issues as with any ORM - but it makes setting up a Django based RESTful API fairly trivial.

Some things I like about DRF:

- viewsets which allow RESTful read + CRUD ops on an existing django model.

- easy to set up different serializers for a model view: flat, nested with child relations etc.

- auto generated API docs in the browsable format of your choosing.

1 - https://www.django-rest-framework.org/


Check out my library for using react in Django easily.

https://github.com/pycampers/react-pages


I haven't used Django to render HTML in at least 3 years.


Why would anyone consider it obsolete to begin with ?

If anything, I would consider someone making that statement miss informed


In the current web dev world, "not the hip new paradigm of the past 3 years" == obsolete in some people's eyes, sadly.


I would consider that person to be obsolete :D


There are not currently many well-known products that use it. (Bitbucket cloud being the exception.)

That's not the best of reasons; just because Django is not used by Google doesn't mean it isn't the perfect tool for you.


Instagram uses it. I'd say they're pretty well-known.

Others: DigitalOcean, Pinterest (used Django at first, may have moved to Flask by now, not sure), Mozilla, Disqus, Robinhood, The Washington Post.


IIRC, I had read that Disqus uses Django, and that they were one of the biggest Django sites on the net, but that was a while earlier. Not sure about now.

Update: Just saw that HN user txcwpalpha said the same about Disqus in sibling comment.


Pinterest uses Django.


Doesn't Instagram count as a well-known product? :)


Last time I checked, last.fm uses Django.


Also very notable benefits:

* Ease of upgrading between versions. This is especially critical and important if you have long lived projects.

* Excellent documentation

* Healthy community, contributors and project is run really smoothly by the team

* Project is a foundation vs single point of failure ,aka main dev loses interest, comparative to other frameworks


> * Ease of upgrading between versions. This is especially critical and important if you have long lived projects.

This is such a big deal and I can't work out how the JavaScript community has been operating under its 'break everything in a week' model for so long with such high traction.

Django has a sane, predictable release schedule. Django has LTS releases with years of support. I work in an agency environment where applications can sit running for years without being touched, and when new work needs to be done - I can't have my entire dependency tree falling from under my feet (or arguably worse, abandoned) because people have decided that backwards compatibility doesn't mean anything.

It's so so hard to not be cynical about this. The entire development world feels like it's more-so every day geared toward time-rich development teams pumping out software in a startup environment frothing over the next big thing. I have to account for every hour of my time, switching between / training other developers on new-hotness JavaScript frameworks is unjustifiable.


Are there people going around saying that Django is obsolete? I've seen a lot of people argue against using Django in favor of RoR or Flask, but that's usually based on personal preference. I've never seen anyone say that it's "obsolete".


I’ve had a few frontend engineering candidates quiz me as to why our backend is written in Python and not JavaScript, and implying that Python is “legacy”. This is not true, but there are developers who think that.


I'm not a fan of Python but the language is still in the top 5 with C#, Java, PHP and Ruby. It's very easy to get a job as a Python dev. People saying that Python is “legacy” have obviously no idea what they're talking about. They probably think C#, Java, PHP and Ruby are “legacy” too. :)


Would be interested to know how many backend engineers would say something so silly.


They're juniors who also think SQL is obsolete because you can't POST a json into it. They'll understand that in order to solve problems efficiently you need a toolbox of a reasonable size.


Yep I’ve had this recently too. Three devs joined the team who had no experience in relational databases, didn’t even know what SQL was for.

A few weeks later they told this story of using MongoDB and how they had layered some rules on top to ensure data consistency...


At work because I have lately needed to roll web server/api/admin/client apps (embellished CRUD situations with some other serverside processing to generate user output) and for those my go to for dev speed, platform speed, familiarity, and a few other concerns I generally go with Node/Express/TypeScript and it's great to work with.

However for my personal site I used Django to give it a shot. Once I wrapped my head around a couple of different paradigms it was quite nice to work with, though I probably haven't laid it out as well as I would a real product or tool. It was very easy to get a pretty basic blog set up.

My only gripe might be on the blog end— it was kind of a pain to find a halfway-current compatible text editor for that purpose. But that isn't the end of the world for my own site. And of course, that's not an issue with Django itself.


I develop many content-driven solutions using Django and the conclusion I've come to is that everything is trash and if it's something for your use, stick to MD.

I've gone with CKEditor (https://github.com/django-ckeditor/django-ckeditor) for all my new stuff, for what it's worth.


Yeah that's what I ended up going with, too.

I might yet switch it out for a plain text editor and just draft all my HTML by hand like scardine has done.

But I don't exactly write a lot these days, so maybe it doesn't matter too much!


I just use plain text-areas and markdown - it avoids a lot of footguns from text-editor-like widgets.


Another point: websockets. Golang is pretty good and (they say) Django kinda sucks. Have you used Django channels?


I have and it works but they completely revamped the implementation in 2.0. I'm procrastinating the upgrade because it is a royal pain.


I've been working with Django for almost my whole career, since 1.1. It's a joy to use, and blows any other web framework I've used out of the water when it comes to actually just building stuff.

Django is a fantastic boring[1] tool, and seeing boring updates like this is great.

1: http://mcfunley.com/choose-boring-technology


It is worth noting that Pyramid Web Framework is also awesome to use. I see it as a middle ground between Django and Flask. The scaffolds make some design decisions for project and you can pick from what you like the most. Pyramid allows for extensible applications and never gets in your way.

The most critical Python infrastructure (PyPi) is now built with it, if you haven't tried it give it a shot. It is one of most well thought out frameworks for python in my opinion.

I've made a tutorial for it: https://docs.pylonsproject.org/projects/pyramid-blogr/en/lat....


I'm a very happy ist of Pyramid. Using it professionally for various larger applications as well as for pet projects.

It's very well thought through. We're providing a GraphQL and integrating it was a breeze.


I would be interested to hear about how you did pyramid and graphql, ive been following graphene but are there specific tie ins for pyramid? books? articles?


The integration is actually straight forward if you use the "graphene" library which you already looked in to. If you use SQLAlchemy, there's even a graphene-sqlalchemy binding which makes it really really easy.

Simply add a /graphql view to your Pyramid app such as:

  from cornice import Service
  from pyramid.exceptions import HTTPBadRequest

  from ..schemas import schema


  graphql = Service(
      name='graphql',
      path='/graphql',
      description="GraphQL",
      accept='application/json',
      renderer='json',
  )


  @graphql.post(permission='readwrite')
  def post_graphql(request):
      query = request.json_body.get('query')
      variables = request.json_body.get('variables', None)
      if not query:
          raise HTTPBadRequest
      return schema.execute(query, variable_values=variables, context_value={
          'dbsession': request.dbsession,
          'user_id': request.authenticated_userid,
      })


Django is a fantastic boring[1] tool, and seeing boring updates like this is great.

couldn't agree more


My roommate in College built a site with 0.96 of Django. It’s still running.

I think it’s one of if not the longest running commercial Django websites.


I have some personal websites that still run on Django 0.96. I also keep the source-code for them in svn and use Trac 0.12 (I think) for pretty-viewing the code in the repository. It’s nice seeing commits you made 11 or 12 years ago.


I maintain a Django ecommerce site that's been running constantly since July 12, 2007 (at launch it was running against r4984, basically 0.96). Just upgraded it to 2.1 today.


Any struggle with the upgrade?


No struggle. I regularly develop and test it against Django master with loud warnings so I fix compatibility issues one at a time as they appear in Django master. I also don't use any 3rd party libraries which means I can upgrade right away.

In this cycle all I needed to tweak was something related to `use_required_attribute` on a form, and I did that back in March. I needed to add `renderer=None` to to my form field render() method, but I did that back when it was a warning in March 2017.


I have been using symfony since the 2-3 years because the product is build on symfony. Now i like symfony, because i’m not a big fan of PHP. Anybody knows how Django compares to Symfony. I have glanced through Django documentation few times and it look a little similiar. If somebody has used both frameworks, what are the main advantages of Django over Symfony?


I use both, but we choose Django for all new projects. For advantages of Django vs Symfony, there's first advantages of Python over PHP...

In a web design context probably the biggest advantage is having things like asynchronous code where it makes sense and websockets without having to use another technology stack such as node.js.

Otherwise I simply find we are more productive using Django, it allows less boilerplate code for similar functionality, there is less complexity involved overall.

Disadvantage is maybe for really large projects with many developers, Symfony might be easier to have someone pick up the code since it's more standardized.


While "it's in Python and not PHP" immediately comes to mind, a less snarky answer is that Django feels optimized for building bespoke content management systems. Take some time to play around with the automatic admin generation.


I understand that it's played out (both as a general discussion, and as replies to your post) but PHP's shortcomings as a language are so blatant when working with any other okay general purpose language.

Community also goes a long way. Back when I dealt in PHP (+whatever framework) and switched to Django, the average competence of people I interacted with in conversations regarding the language / frameworks jumped up considerably. I like standing on the shoulders of giants.


As a counter point, I tried to use Django for a data-visualisation project and ran into some problems. Everything is built on models, which are kind of activerecord pattern. Django has an inbuilt (and inferior) version of sqlalchemy, so that when you want to push sql past a certain point (define queries more complex than the api) you're pretty much stuck. Now you have codebase with two different database libraries in it. You're probably using an spa so all the view stuff isn't helping, and Django kind of infects your code because it won't run without an initializarltion step so if you have a module importing something that imports Django, any time you use that it needs to initialize Django itself. I don't think that these are mistakes, just choices that they made that make it very good for websites up to a certain (sql/data) complexity and very annoying afterwards.


Pyramid is often forgotten. It's genuinely designed to be extended (vs. Flask's approach of "here you have a magic-global variable (that's magically working like a stack of dicts), go put some stuff into it"); a good example would be renderers. In Django it's still kinda awkward to use other/multiple templating engines; Flask doesn't really help. Pyramid on the other hand has a simple and extensible interface to support multiple templates and other renderers ( https://docs.pylonsproject.org/projects/pyramid/en/latest/na.... ). This is a common theme with Pyramid. Another is avoiding global state; they're quite successful at that (vs. "I declare my entire app/blueprint within a function"-Flask and "I don't know how this works, it's just like magic. I go to my model class and, BAM, suddenly I'm connected to some database"-Django). Django ORM is awkward and not that good, but awkward to replace.


The Django ORM has raw SQL escape hatches (either fully raw SQL database connections or model instance selections with SQL), and if you do need the SQLAlchemy query builder, slap in something like https://github.com/Deepwalker/aldjemy .

As for the initialization stuff -- yes, that's true; whenever Django models are being imported, you do need to have had `django.setup()` called.


yea good point, I should have mentioned the raw SQL escape hatch, that also isn't an ideal solution. I went for aldjemy/instead them and in retrospect starting with something sqlalchemy native would have been cleaner.


We went the other way around and came up with https://github.com/shosca/django-rest-witchcraft and https://github.com/shosca/django-sorcery to integrate sqlalchemy with django as the project was already using sqlalchemy.


> Django kind of infects your code because it won't run without an initializarltion step

Most people using Django have built their apps as Django apps so this is a "non issue".

The worst way to use Django is to try and fight against the way it was built. For your case specifically, it's probably not a good option.


You might have seen aldjemy already but I thought I might mention it https://github.com/Deepwalker/aldjemy - let's us use SQLAlchemy queries in our django code without requiring redefining the models in an SQLAlchemy manner. It's easy to put a wrapper around it to convert SQLAlchemy results back into Django model instances.

I'm exploring using Django Channels to send data to visualisation SPA's in realtime. https://channels.readthedocs.io/en/latest/


Yep I'm using Aldjemy as a bridge for now and it works great. I still really don't like having two completely different db layers in the same codebase. Whilst we're plugging the ecosystem/extensions, I also use Alembic which is amazing.


> Django has an inbuilt (and inferior) version of sqlalchemy

Django has it's own ORM with a different design philosophy that is optimised for a different use-case to sqlalchemy.

Django's ORM is generally cleaner and more readable for the common case and requires less code to set up. It might be slightly less elegant for more complex cases but it's a trade off that's made me pretty happy on balance.


I mean that's a general problem with ALL ORMs. I've been on Django projects where we had to drop down and pass raw SQL statements.

On my current project we don't use an ORM; just SQL statements and we create classes to match the result set and map into them.


Disagree. It's mostly a question of whether the ORM was designed as a "least-common denominator of common operations supported by some RDBMSs" (which is clearly the case for the Django ORM) or as an abstraction of SQL concepts (i.e. a form of relational algebra). The former category generally fares poorly with complex queries or structures; the latter exceeds at them.


What are some good examples of the latter type of ORM? Thanks


sqlalchemy


I don't disagree with your assessments of django limitations. It does however, seems like a poor choice for your specific problem.

This is why the problem inform the solution, pick the framework (or lack of) that suits your problem best


Totally agree. I've been using Django since 0.96 and it's is so mature now. Earlier they introduced so many new features... but it's now a very mature framework that doesn't really need any new features.


What do you use to write your front end Javascript?


Not OP, but I've also been using Django for (more than) my whole career and I use React on the frontend.

If you're curious about the frontend path I took, it was roughly:

* jQuery with no framework

* Backbone (for a couple years)

* Backbone + Marionette (for a couple more years)

* Angular (for about a week)

* React (for the past few years)


When you moved to Angular and later to React did you have any jQuery heavy libraries?

I'm using stuff like slickgrid[0], jquery-ui datepicker, json-editor[1] and wonder how I will drive these components from something like Angular or React?

doh, quickly googled for the github links below and saw there now a slickgrid-es6[2] fork which I have not tried. But my question still stand: how do you drive jquery libs from newer frameworks?

[0]: https://github.com/6pac/SlickGrid/wiki

[1]: https://github.com/json-editor/json-editor

[2]: https://github.com/DimitarChristoff/slickgrid-es6


I have encapsulated jQuery (including Bootstrap) plugins in AngularJS, React and Vue in the past. They all allow you to access a DOM node somehow.

Maybe it's frowned upon but I don't really like to use those (usually partial) Bootstrap re-implementation, especially in non-SPAs where you already have jQuery and/or Bootstrap.

Of course it's becoming less and less necessary.


Other users have already commented, but basically you can wrap jQuery libraries in React components and do a bit of extra work in the lifecycle methods (componentDidMount, componentWillUnmount, etc.) to manage the jQuery bits.

Once you've wrapped it in a component, you can more or less drop that component anywhere in your view hierarchy and not have to think about the fact that it's using jQuery under the hood.

This highlights one of my favorite things about React and similar frameworks, which is that it's the closest thing to actual, useful encapsulation of components I've seen in a frontend framework. It's not perfect, but it's much better than everything I used before it.


You can access the raw DOM node from a React component.

On component mount/unmount, you can apply a jQuery library to the DOM node and optionally clean it up.

It's the same way you can wrap a <canvas> node with a React component and otherwise do all your draws outside of React (like for a game). This way the node is still integrated into your React app but React does nothing more than create/remove it.


Thanks for the input. Comments like these are insightful.

What do you think of Vue.js?


I have spent some time using Vue.js and Django as a backend and I have been pretty satisfied with the results! I will probably try React next just to make sure I am not missing anything. I tried using node as a backend but I couldn't find any framework on the level of Django so I went back to it. There are some pretty decent boilerplates already to setup a Django/Vue website if you look for them.


I've heard great things about Vue.js (mostly on HN) but I haven't tried it myself. I'm pretty invested in React (I use it at work and for personal projects), and I find it to be a pleasure to use so I'm not actively seeking out alternatives.

State management with React is another story; I've used Reflux and Redux a lot, and am experimenting with Mobx now.


Vue is a pleasure to build stuff in. It just seems to work well, especially with nice things like two-way binding out of the box.


Vue looks nice, but nowdays I'd pick something like lit-element(lit-html) or stencil.


I’m curious what makes react your top pick?


Compared with Backbone, I was able to compose and re-compose component structures much more easily. Compared to Angular (which I admittedly don't really know) the API learning curve felt very short and I was able to wrap my head around it very quickly and be productive without constantly looking things up.


Django fan here, if you're trying to use Django with react you may be interested in this: https://github.com/anchpop/cookiecutter-django

I wrote it for my own convenience but others may find it useful.


Not OP either, but I've been using Django REST framework with React.js, and I'm really enjoying it.


Any tips for how to use JWT authentication and get around CSRF tokens being in forms when combining DRF with a JS SPA UI?


If you want JWT, you can use https://github.com/GetBlimp/django-rest-framework-jwt -- that provides another authentication class, and you can then auth with `Accept: Bearer <jwt>`.

If you don't need JWT (I'd probably leave it out next time round) then Django Rest Framework comes with a simpler bearer token auth class (among others): http://www.django-rest-framework.org/api-guide/authenticatio....

edit to add - if you're asking specifically about sharing sessions between the JS app and the Django server-side form, I believe this is what you're looking for:http://www.django-rest-framework.org/api-guide/authenticatio..., i.e. you'll still need to pass the csrf token into the JS app.


The way I've always done it is to not log the user in to a Django session. That way the SPA is the thing which holds the authentication, be it JWT or any other kind of token.

If any other site tries to POST to the API on behalf of the current user they'll get a "Authentication credentials required" message.


Yes! It is just like Rails. Almost as good! Is it Python 2 or Python 3?

https://wiki.python.org/moin/Python2orPython3


A reminder to support these guys! 24% funded and they’re only asking for $200K. :(

https://www.djangoproject.com/fundraising/


Thanks for mentioning. I was going to post that I see you did it already.

Such a heavy mega framework that small to big companies and individual relies on, we should support it.

Whoever sees this, please support Django to reach its goal.


Thank you for bringing this up!


Congrats Django team! This iteration doesn't add too much for my current workings with the framework but it matures it none-the-less. My usual project compositions utilize Django, GraphQL, and React. I'm earnestly watching https://www.aeracode.org/2018/06/04/django-async-roadmap/ to hopefully work it's way into the near future releases.


Read-only model views are a great addition to the Django admin -- I've been watching that PR for a long time, glad to see it land.

This will make it a lot easier to build internal admin dashboards that are safe to share with non-privileged users like support staff.


I have seen a bastardized version of Django admin used as a quite sophisticated dashboard. This new addition will make it even easier to hack together things like that in a very short time.


One of my first Django projects was to “bastardize” its admin into a Lead/Opportunity management system for a mortgage broker, back in the version 0.96 days. I know that monkey-patching is now frowned upon and reguarded as “the work of the devil” but it really helped me get the job done for that project in a pretty reasonable amount of time. I hope dynamic programming makes a come-back.


This is a surprisingly pretty common practice. I know people, even at Google, who want the ease of CMS but additional control.


There were always ways to get read only in the admin. Just not nicely. It shouldn’t have been holding you back though.


I've been looking forward to this as well. A lot of developers underestimate the time it takes to build CMS and resource dashboards (even small ones).


I work with a lot of clients and for every project, it's Django. I love how readable the code is. I've even had non-technical clients peer into the code and make correct observations.

And it's been said already, but Django Admin is a crown jewel. I can't tell you how many clients have jumped with delight when they realize they get that functionality out of the box. It ends up turning into a great admin dashboard and pseudo analytics tool---atleast for the short term.

If you're jumping on the GraphQL train, I'd encourage you to check out Graphene. It's a Django library that serves as a GraphQL provider. Reasonably well documented and production ready, IMO. If you're looking a Django + GraphQL + React starter project, mbrochh's project [0] is a good place to start. It is slightly outdated but the core patterns are still reusable.

[0] - https://github.com/mbrochh/django-graphql-apollo-react-demo


Django is the only web framework where I see consistently positive discussions about it on HN.

Bravo Django, and congratulations on another release!


This aspect has me looking at getting into Django; what have the discussions on HN regarding ASP.NET Core (the new open-source stuff) been like? I'm mainly in pre-Core MVC and looking to move up to something I can deploy to any Docker-hosting environment.


I can't help you with ASP.NET Core, as I have no experience building and/or deploying it.

What I can chime in with though is: In my days as a web dev I started off and learned the ropes with ASP.NET (MVC was recently coming up), and after moving to django for another project I felt right at home.

It's very impressive how the django project was able to rival a behemot like Microsoft in terms of usability, reasonable defaults and developer convenience, overall design, documentation, upgradability.

The REST stuff (django rest framework) and some aspects of managing models were actually quite ahead of ASP.NET at the time for getting you up to speed with things.

Of course the tech stack around them is completely different and something you'll want to think about, but in terms of features and how things are laid out you don't need to worry, django has you covered.



Are there any good reads on Django for former Rails devs? I'm learning Django now and interested for the "translation".


I am the same. Not because I want to stop using Rails (I <3 Rails), but rather just to increase my repertoire. Let me know if you find something!


Tango with Django is my favourite read but it’s tutorial style.


Open question re: django:

https://docs.djangoproject.com/en/2.1/ref/models/fields/#nul...

I've got a colleague who has been using django for a couple of years (and has 15+ years experience with python outside of web, as well as java, php, arduino hacking, 3d printing, etc).

He pointed me to the link above re: nulls - I can't figure out why the default would be to convert a null to an empty string. All major databases can understand nulls just fine.

"... If a string-based field has null=True, that means it has two possible values for “no data”: NULL, and the empty string. In most cases, it’s redundant to have two possible values for “no data;”..."

An empty string is "no user supplied data" and a null is "no value has been given at all". It seems rather ... odd(?) to try to conflate the two.

Am I missing something?

I've got perhaps a slight bias against django, in that the only people I've known who've used it were either junior devs who had no experience in anything else (and raved about it), or senior folks who've inherited a relative django mess (usually the result of the aforementioned junior devs).


> An empty string is "no user supplied data" and a null is "no value has been given at all"

I assume you meant "an empty string is user supplied an empty string as data".

That aside, you wouldn't normally switch that option on for a field (notice the default is false).

However, Oracle DB stores empty strings as indistinguishable from NULLs[0], so an ORM supporting Oracle DB may want to have some support for converting "empty or null" to an empty string at read time (notice the Oracle specific caveat in the docs in your link).

Once you have that, I'd guess the thinking is that you may as well let devs opt into that behavior (bear in mind that sometimes you're in the position of developing a new app against an existing db, that may or may not have another legacy app reading/writing from it at the same time).

0: https://stackoverflow.com/questions/203493/why-does-oracle-9...


> I assume you meant "an empty string is user supplied an empty string as data".

I think so - it was a bit late. But it's the diff between intentional empty value and unknown/initial value.

I still don't grok why django seems to want, by default, to ignore the concept of storing "null" in the database, and makes you jump to non-default configuration to do something which has value (seeing nulls vs empty strings means different things).


Can anyone recommend a framework like Django except for a static language? I tried Django and really liked what I saw, but I can't see myself using Python for a large project.


There's been some work to add type-hinting to Django if that helps.

Check out:

https://github.com/TypedDjango/django-stubs#django-stubs

https://gitter.im/mypy-django/Lobby


Gobuffallo.io the guy who wrote gave a talk which you can find on youtube.


To django model users. Can you query keys inside a JSON datatype(pgsql)[0] from the ORM?

For example in sqla you will do:

    records = db_session.query(Resource).filter(
               Resources.data["lastname"].astext == "Doe"
           ).all()
with data being the json column and lastname a key in the column.

[0]: https://stackoverflow.com/a/29975187


Django's version of that query (to me) looks a little neater too.

    records = Resource.objects.filter(
               data__lastname__exact="Doe"
           )


One can also write the sqla query as:

    Resource.query.filter(
        Resources.data["lastname"].astext=="Doe"
    )
Personally I find the "__" convension strange and not sure that it would be obvious to new comers that you are accessing a key in the data column.



Thank for the quick reply. Now I need to understand how the "__" magic work; And I wonder what would django do if my key is "animal__breed".

Will it understand:

    Dog.objects.filter(data__animal__breed='collie')
But this is maybe questions I should rather ask on #django or stackoverflow.


You probably simply can't do a `data['animal__breed']` query (not with that syntax anyway; you can implement custom lookups though) if your key happens to contain a double underscore.


Django won't let you name a model field with a double underscore, I believe. Not sure how this would work with a Postgres JSON type column though, but it would probably throw an error.


Fantastic work! After the last few feature-packed releases, I'm happy to see a bugfix one. Upgrading should be a breeze.


After running my test suite, I'm seeing zero deprecation warnings (let alone failures) in 2.1. I'll still wait a couple months before upgrading in production, but this should be one of the easiest upgrades in a long time.


Agreed, or you end up with something that resembles the unfortunate path of iOS. I'm in the Apple ecosystem so this isn't an attack from an opposite camp, but a matter-of-fact cautionary tale about the kludge which has appeared when components have become untenable and not-so-great performance related.




Applications are open for YC Summer 2019

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

Search: