Django 2.1 released
docs.djangoproject.com
docs.djangoproject.com
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.
If anything, I would consider someone making that statement miss informed
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.
Others: DigitalOcean, Pinterest (used Django at first, may have moved to Flask by now, not sure), Mozilla, Disqus, Robinhood, The Washington Post.
Update: Just saw that HN user txcwpalpha said the same about Disqus in sibling comment.
A few weeks later they told this story of using MongoDB and how they had layered some rules on top to ensure data consistency...
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've gone with CKEditor (https://github.com/django-ckeditor/django-ckeditor) for all my new stuff, for what it's worth.
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!
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.
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.
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.
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.
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).
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.
I had to look up CADT.
Got this via Google:
CADT stands for Cascade of Attention-Deficit Teenagers
>...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.
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.
* 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
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.
Django is a fantastic boring[1] tool, and seeing boring updates like this is great.
I wrote it for my own convenience but others may find it useful.
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)
What do you think of Vue.js?
State management with React is another story; I've used Reflux and Redux a lot, and am experimenting with Mobx now.
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
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.
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.
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.
If any other site tries to POST to the API on behalf of the current user they'll get a "Authentication credentials required" message.
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 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....
It's very well thought through. We're providing a GraphQL and integrating it was a breeze.
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,
})couldn't agree more
As for the initialization stuff -- yes, that's true; whenever Django models are being imported, you do need to have had `django.setup()` called.
I'm exploring using Django Channels to send data to visualisation SPA's in realtime. https://channels.readthedocs.io/en/latest/
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.
This is why the problem inform the solution, pick the framework (or lack of) that suits your problem best
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.
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 think it’s one of if not the longest running commercial Django websites.
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.
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.
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.
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.
This will make it a lot easier to build internal admin dashboards that are safe to share with non-privileged users like support staff.
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
Bravo Django, and congratulations on another release!
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.
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).
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 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).
Check out:
For example in sqla you will do:
records = db_session.query(Resource).filter(
Resources.data["lastname"].astext == "Doe"
).all()
Will it understand:
Dog.objects.filter(data__animal__breed='collie')
records = Resource.objects.filter(
data__lastname__exact="Doe"
) Resource.query.filter(
Resources.data["lastname"].astext=="Doe"
)