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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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 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,
})
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.
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.
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.
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.
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.
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.
> 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 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.
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 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 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?
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. :)
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.
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.
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.
> 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.
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).
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.
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.
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.
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.
> * 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.
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.
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.
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).
> 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).
128 comments
[ 3.7 ms ] story [ 460 ms ] threadThis will make it a lot easier to build internal admin dashboards that are safe to share with non-privileged users like support staff.
Django is a fantastic boring[1] tool, and seeing boring updates like this is great.
1: http://mcfunley.com/choose-boring-technology
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
[1]: https://github.com/json-editor/json-editor
[2]: https://github.com/DimitarChristoff/slickgrid-es6
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:
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.
https://wiki.python.org/moin/Python2orPython3
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.
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.
For example in sqla you will do:
with data being the json column and lastname a key in the column.[0]: https://stackoverflow.com/a/29975187
Will it understand:
But this is maybe questions I should rather ask on #django or stackoverflow.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.
1 - https://www.django-rest-framework.org/
https://github.com/pycampers/react-pages
* 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.
https://www.djangoproject.com/fundraising/
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.
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
Check out:
https://github.com/TypedDjango/django-stubs#django-stubs
https://gitter.im/mypy-django/Lobby
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).